diff --git a/demo/AriesOpenAPIDemo-DMV.md b/demo/AriesOpenAPIDemo-DMV.md
deleted file mode 100644
index 01e8a50d88..0000000000
--- a/demo/AriesOpenAPIDemo-DMV.md
+++ /dev/null
@@ -1,269 +0,0 @@
-
-
-# Aries OpenAPI Demo
-
-This demo is for developers comfortable with playing around with APIs using the OpenAPI (Swagger) user interface and JSON. The controller for each of the two agent instances in the demo is you. You drive the API exposed by the agent instances to respond to events received by each agent. The demo covers two agents, Alice and one representing the Government Driver’s Licence program. The two agents connect, and then the Government’s Department of Motor Vehicles (DMV) agent issues a Driver Licence credential to Alice, and then asks Alice to prove she possesses the credential. Who knows why the DMV Agent needs to get the proof, but it lets us show off more protocols.
-
-# Table of Contents
-
-- [Prerequisites](#Prerequisites)
-- [Starting Up](#Starting-Up)
- - [Start the VON Network](#Start-the-VON-Network)
- - [Running the DMV Agent](#Running-the-DMV-Agent)
- - [Running Alice’s Agent](#Running-Alices-Agent)
- - [Restarting the Demo](#Restarting-the-Demo)
- - [Running the Demo Steps](#Running-the-Demo-Steps)
-- [Establishing a Connection](#Establishing-a-Connection)
- - [Notes](#Notes)
-- [Preparing to Issue a Credential](#Preparing-to-Issue-a-Credential)
- - [Register the DMV DID](#Register-the-DMV-DID)
- - [Publish the Schema](#Publish-the-Schema)
- - [Publishing a Credential Definition](#Publishing-a-Credential-Definition)
- - [Notes](#Notes-1)
-- [Issuing a Credential](#Issuing-a-Credential)
- - [Notes](#Notes-2)
- - [Bonus Points](#Bonus-Points)
-- [Requesting/Presenting a Proof](#RequestingPresenting-a-Proof)
- - [Notes](#Notes-3)
-- [Conclusion](#Conclusion)
-
-## Prerequisites
-
-To run the demo, you must have a system capable of running docker to run containers, and terminal windows running bash. On Windows systems, we highly recommend using git-bash, the Windows Subsystem for Linux (WSL) or a comparable facility. The demo will not work using PowerShell.
-
-You can also run the agents using Python on your native system, but docker development is sooo much nicer.
-
-Before beginning, clone, or fork and clone this repo and the [von-network](https://github.com/bcgov/von-network) repo.
-
-## Starting Up
-
-To begin the demo, open up three terminal windows, one for each agent - one to run a local Indy network (using the VON network) and one each for the DMV’s Agent and Alice’s Agent. You’ll also open up three browser tabs, one to allow browsing the Indy network ledger, and one for the OpenAPI user interface for each of the agents.
-
-### Start the VON Network
-
-In one of the terminal windows, follow the [Running the Network Locally](https://github.com/bcgov/von-network#running-the-network-locally) instructions to start (but don’t stop) a local four-node Indy network. In one of the browser tabs, navigate to [http://localhost:9000](http://localhost:9000) to see the ledger browser user interface and to verify the Indy network is running.
-
-> NOTE: The use of localhost for the Web interfaces is assumed in this tutorial. If your docker setup is atypical, you may use a different address for your docker host.
-
-### Running the DMV Agent
-
-To start the DMV agent, open up a second terminal window and in it change directory to the root of your clone of this repo and execute the following command:
-
-```bash
-PORTS="5000:5000 10000:10000" ./scripts/run_docker start -it http 0.0.0.0 10000 -ot http --admin 0.0.0.0 5000 -e http://`docker run --net=host eclipse/che-ip`:10000 --genesis-url http://`docker run --net=host eclipse/che-ip`:9000/genesis --seed 00000000000000000000000000000000 --admin-insecure-mode --auto-ping-connection --auto-accept-invites --auto-accept-requests --auto-respond-credential-request --auto-verify-presentation --wallet-type indy --label "DMV Agent"
-```
-
-If all goes well, the agent will show a message indicating it is running. Use the second of the browser tabs to navigate to [http://localhost:5000](http://localhost:5000). You should see an OpenAPI user interface with a (long-ish) list of API endpoints. These are the endpoints exposed by the DMV Agent.
-
-The `run_docker` script provides a lot of options for configuring your agent. We’ll cover the meaning of some of those options as we go. One thing you may find odd right off is this - `docker run --net=host eclipse/che-ip`. It is an inline command that invokes docker to run a container that returns the IP of the Docker Host. It’s the most portable way we know to get that information for docker running on MacOS, Windows or Linux.
-
-### Running Alice’s Agent
-
-To start Alice’s agent, open up a third terminal window and in it change directory to the root of your clone of this repo and execute the following command:
-
-``` bash
-PORTS="5001:5001 10001:10001" ./scripts/run_docker start -it http 0.0.0.0 10001 -ot http --admin 0.0.0.0 5001 -e http://`docker run --net=host eclipse/che-ip`:10001 --genesis-url http://`docker run --net=host eclipse/che-ip`:9000/genesis --seed 00000000000000000000000000000001 --admin-insecure-mode --auto-ping-connection --auto-accept-invites --auto-accept-requests --auto-respond-credential-offer --auto-respond-presentation-request --auto-store-credential --wallet-type indy --label "Alice Agent"
-```
-
-If all goes well, the agent will show a message indicating it is running. Use the third tab to navigate to [http://localhost:5001](http://localhost:5001). Again, you should see an OpenAPI user interface with a list of API endpoints, this time the endpoints for Alice’s agent.
-
-### Restarting the Demo
-
-When you are done, or to stop the demo so you can restart it, carry out the following steps:
-
-1. in the DMV and Alice agent terminal windows, hit Ctrl-C to terminate the agents;
-2. in the `von-network` terminal window, hit Ctrl-C to stop the logging, and then run the command `./manage down` to both stop the network and remove the data on the ledger.
-
-### Running the Demo Steps
-
-The demo is run entirely in the Browser tabs - DMV ([http://localhost:5000](http://localhost:5000)), Alice ([http://localhost:5001](http://localhost:5001)) and the Indy public ledger ([http://localhost:9000](http://localhost:9000)). The agent terminal windows will only show messages if an error occurs in using the REST API. The Indy public ledger window will display a log of messages from the four nodes of the Indy network. In the instructions that follow, we’ll let you know if you need to be in the DMV, Alice or Indy browser tab. We’ll leave it to you to track which is which.
-
-Using the OpenAPI user interface is pretty simple. In the steps below, we’ll indicate what API endpoint you need use, such as **`POST /connections/create-invitation`**. That means you must:
-
-1. scroll to and find that endpoint;
-2. click on the endpoint name to expand its section of the UI;
-3. click on the `Try it out` button.
-4. fill in any data necessary to run the command.
-5. click `Execute`
-6. check the response to see if the request worked.
-
-So, the mechanical steps are easy. It’s fourth step from the list above that can be tricky. Supplying the right data and, where JSON is involved, getting the syntax correct - braces and quotes. When steps don’t work, start your debugging by looking at your JSON.
-
-Enough with the preliminaries, let’s get started!
-
-## Establishing a Connection
-
-We’ll start the demo by establishing a connection between Alice’s and the DMV’s agents. We’re starting there to demonstrate that you can use agents without having a ledger. We won’t be using the Indy public ledger at all for this step. Since the agents communicate using DIDcomm messaging and connect by exchanging pairwise DIDs and DIDDocs based on the `did:peer` DID method, a public ledger is not needed.
-
-In the DMV browser tab, execute the **`POST /connections/create-invitation`**. No data is needed to be added for this call. If successful, you should see a connection ID, an invitation, and the invitation URL. The IDs will be different on each run.
-
-Copy the entire block of the `invitation` object, from the curly brackets `{}`, excluding the trailing comma.
-
-Switch to the Alice browser tab and get ready to execute the **`POST /connections/receive-invitation`** section. Erase the pre-populated text and paste the invitation object from the DMV tab. When you click `Execute` a you should get back a connection ID, an invitation key, and the state of the connection, which should be `requested`.
-
-Scroll to and execute **`GET /connections`** to see a list of the connections, and the information tracked about each connection. You should see the one connection Alice’s agent has, that it is with the DMV agent, and that its status is `active`.
-
-You are connected! Switch to the DMV agent browser tab and run the same **`GET /connections`** endpoint to see the DMV view. Hint - note the `connection_id`. You’ll need it later in the tutorial.
-
-### Notes
-
-For those familiar with the `Establish Connection` DIDcomm protocol, you might wonder why there was not an `accept-request` sent by the DMV agent. That is because in the start up parameters for the DMV agent, we used the options `--accept-invites --accept-requests`. With those set, the DMV agent accepts invites and requests automatically, without notifying the controller or waiting on an API call from the controller before proceeding. Had those not been set, the DMV controller (in this case - you), would have had to dig through the protocol state, requested a new connection be created (generating a new pairwise DID in the process) and constructed a response to the request to accept the invitation. Easily done with a controller program, but a bit of a pain when the controller is a person. Alice’s agent used similar settings to simplify the process on her side.
-
-## Preparing to Issue a Credential
-
-The next thing we want to do in the demo is have the DMV agent issue a credential to Alice’s agent. To this point, we have not used the Indy ledger at all. The connection and all the messaging is done with pairwise DIDs based on the `did:peer` method. Verifiable credentials must be rooted in a public DID ledger to enable the presentation of proofs.
-
-Before the DMV agent can issue a credential, it must register a DID on the Indy public ledger, publish a schema, and create a credential definition. In the “real world”, the DMV agent would do this before connecting with any other agents, but we’ll do those steps now, Of course in the “real world”, we don’t have controllers that are people running agents using an OpenAPI user interface.
-
-### Register the DMV DID
-
-To write transactions to the Indy ledger, we have to first register a DID for the DMV agent.
-
-In the startup parameters for the DMV agent, we specified a seed for the DMV agent, so we need to use that exact string to register the DID on the ledger. We’ll use the Indy ledger browser user interface to do that:
-
-1. On the ledger browser tab, go to the section “Authenticate a New DID”.
-2. Choose the “Register from seed” option. Paste a seed of 32 zeros (00000000000000000000000000000000) into the “Wallet seed” text area. That matches the seed parameter we used in starting the DMV agent.
- 1. Note: If you chose the Register from DID option, would need both DID and Verkey which is annoying, so just use the seed option.
-3. Click `Register DID`. If successful, should see the following:
-
-**Identity successfully registered:**
-```
-Seed: 00000000000000000000000000000000
-DID: 4QxzWk3ajdnEA37NdNU5Kt
-Verkey: 2ru5PcgeQzxF7QZYwQgDkG2K13PRqyigVw99zMYg8eML
-```
-
-### Publish the Schema
-
-To publish that schema, go to the DMV browser and get ready to execute the **`POST /schemas`** endpoint. Fill in the text box with the following JSON that defines the schema we’ll use:
-
-``` JSONC
-{
- "schema_name": "drivers-licence",
- "attributes": [
- "age",
- "hair_colour"
- ],
- "schema_version": "1.0"
-}
-```
-
-Click `Execute`. If successful, you should see a `schema_id` in the response, most likely: `4QxzWk3ajdnEA37NdNU5Kt:2:drivers-licence:1.0`. This ID will be used for later steps in the tutorial.
-
-To confirm the schema was published, let’s check the Indy network transactions. Go to the Indy ledger browser tab and click the **`Domain`** button, bottom left. Scroll to the bottom of the page. The last entry (#7) should be the published schema.
-
-Schema published!
-
-### Publishing a Credential Definition
-
-Next up, we’ll publish the Credential Definition on the ledger. On the DMV browser tab get ready to execute the `POST credential-definition` endpoint. Fill in the text box with the schema ID from early (or just copy the text below) in the following JSON:
-
-``` JSONC
-{
- "schema_id": "4QxzWk3ajdnEA37NdNU5Kt:2:drivers-licence:1.0"
-}
-```
-
-Click `Execute`. This step will take a bit of time as there is a lot going on in the indy-sdk to create and publish a credential definition - lots of keys being generated. Fortunately, this is not a step that happens very often, and not with real-time response requirements. You might want to open the `von-network` terminal window to see the Indy ledger nodes messaging one another. Once execution completes you should see the resulting credential definition ID, specifically: `4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default`.
-
-You can confirm the credential definition was published by going back to the Indy ledger browser tab, where you should still be on the `Domain` page. Refresh, scroll to the bottom and you should see transaction #8 - the new credential definition.
-
-### Notes
-
-OK, we have the one time setup work for issuing a credential complete. We can now issue 1 or a million credentials without having to do those steps again. Astute readers might note that we did not setup a revocation registry, so we cannot revoke the credentials we issue with that credential definition. You can’t have everything (and we’re still working on enabling that).
-
-## Issuing a Credential
-
-Issuing a credential from the DMV agent to Alice’s agent is easy. In the DMV browser tab, scroll down to the **`POST /issue-credential/send`** and get ready to (but don’t yet) execute the request. Before execution, you need to find some other data to complete the JSON.
-
-First, scroll back up to the **`GET /connections`** API endpoint and execute it. From the result, find the the `connection_id` and copy the value. Go back to the **`POST /issue-credential/send`** section and paste it as the value for the `connection_id`.
-
-Next, scroll down to the **`POST /credential-definitions`** section that you executed in the previous step. Expand it (if necessary) and find and copy the value of the `credential_definition_id`. You could also get it from the Indy Ledger browser tab, or from earlier in this tutorial. Go back to the **`POST /issue-credential/send`** section and paste it as the value for the `cred_def_id`.
-
-Finally, for the credential values, put the following between the `attributes` square brackets:
-
-```
- {
- "name": "age",
- "value": "19"
- },
- {
- "name": "hair_colour",
- "value": "brown"
- }
-```
-
-Ok, finally, you are ready to click `Execute`. The request should work, but if it doesn’t - check your JSON! Did you get all the quotes and commas right?
-
-To confirm the issuance worked, scroll up to the top of the `v1.0 issue-credential exchange` section and execute the **`GET /issue-credential/records`** endpoint. You should see a lot of information about the exchange, including the state - `credential_acked`.
-
-Let’s look at it from Alice’s side. Switch to the Alice’s agent browser tab, find the `credentials` section and within that, execute the **`GET /credentials`** endpoint. There should be a list of credentials held by Alice, with just a single entry, the credential issued from the DMV agent.
-
-You’ve done it, issued a credential! W00t!
-
-### Notes
-
-Those that know something about the Indy process for issuing a credential and the DIDcomm `Issue Credential` protocol know that there a multiple steps to issuing credentials, a back and forth between the Issuer and the Holder to (at least) offer, request and issue the credential. All of those messages happened, but the two agents took care of those details rather than bothering the controller (you, in this case) with managing the back and forth.
-
-* On the DMV agent side, this is because we used the **`POST /issue-credential/send`** administrative message, which handles the back and forth for the issuer automatically. We could have used the other `/issue-credential/` endpoints to allow the controller to handle each step of the protocol.
-* On Alice's agent side, this is because in the startup options for the agent, we used the `--auto-respond-credential-offer` and `--auto-store-credential` parameters.
-
-### Bonus Points
-
-If you would like to perform all of the issuance steps manually on the DMV agent side, use a sequence of the other `/issue-credential/` messages. Use the **`GET /issue-credential/records`** to both check the credential exchange state as you progress through the protocol and to find some of the data you’ll need in executing the sequence of requests. If you want to run both the DMV and Alice sides in sequence, you’ll have to rerun the tutorial with Alice’s agent started without the `--auto-respond-credential-offer` and `--auto-store-credential` parameters set.
-
-## Requesting/Presenting a Proof
-
-Alice now has her DMV credential. Let’s have the DMV agent send a request for a presentation (a proof) using that credential. This should be pretty easy for you at this point.
-
-From the DMV browser tab, get ready to execute the **`POST /present-proof/send_request`** endpoint. Select the entire pre-populated text and replace it with the following. In doing so, use the techniques we used in issuing the credential to replace the sample values for each instance of `cred_def_id` (there are four) and `connection_id`.
-
-``` JSONC
-{
- "connection_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
- "proof_request": {
- "name": "bar-checks",
- "version": "1.0",
- "requested_attributes": {
- "0_hair_colour_uuid": {
- "name": "hair_colour",
- "restrictions": [
- {
- "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default"
- }
- ]
- }
- },
- "requested_predicates": {
- "0_age_GE_uuid": {
- "name": "age",
- "p_type": ">=",
- "p_value": 18,
- "restrictions": [
- {
- "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default"
- }
- ]
- }
- }
- }
-}
-```
-
-Notice that the proof request is using a predicate to check if Alice is older than 18 without asking for her age. Click `Execute` and cross your fingers. If the request fails check your JSON!
-
-Note that in the response, the state is `request_sent`. That is because when the HTTP response was generated (immediately after sending the request), Alice’s agent had not yet responded to the request. We’ll have to do another request to verify the presentation worked. Copy the value of the `presentation_exchange_id` field from the response and use it in executing the **`GET /present-proof/records/{pres_ex_id}`** endpoint. That should return a result showing the state as `verified` and `verified` as `true`. Proof positive!
-
-### Notes
-
-As with the issue credential process, the agents handled some of the presentation steps without bothering the controller. In this case, Alice’s agent processed the presentation request automatically because it was started with the `--auto-respond-presentation-request` parameter set, and her wallet contained exactly one credential that satisfied the presentation-request from the DMV agent. Similarly, the DMV agent was started with the `--auto-verify-presentation` parameter and so on receipt of the presentation, it verified the presentation and updated the status accordingly.
-
-## Conclusion
-
-That’s the OpenAPI-based tutorial. Feel free to play with the API and learn how it works. More importantly, as you implement a controller, use the OpenAPI user interface to test out the calls you will be using as you go.
-
-
diff --git a/demo/AriesOpenAPIDemo.md b/demo/AriesOpenAPIDemo.md
index 09f42e09ea..4693eb49c4 100644
--- a/demo/AriesOpenAPIDemo.md
+++ b/demo/AriesOpenAPIDemo.md
@@ -1,9 +1,3 @@
-
-
# Aries OpenAPI Demo
What better way to learn about controllers than by actually being one yourself! In this demo, that’s just what happens—you are the controller. You have access to the full set of API endpoints exposed by an ACA-Py instance, and you will see the events coming from ACA-Py as they happen. Using that information, you'll help Alice's and Faber's agents connect, Faber's agent issue an education credential to Alice, and then ask Alice to prove she possesses the credential. Who knows why Faber needs to get the proof, but it lets us show off more protocols.
@@ -43,6 +37,8 @@ For the rest of the set up, you can choose to run the terminal sessions in your
To run the necessary terminal sessions in your browser, go to the Docker playground service [Play with Docker](https://labs.play-with-docker.com/). Don't know about Play with Docker? Check [this out](https://github.com/cloudcompass/ToIPLabs/blob/master/docs/LFS173x/RunningLabs.md#running-on-play-with-docker) to learn more.
+### Start the Faber Agent
+
In a browser, go to the [Play with Docker](https://labs.play-with-docker.com/) home page, Login (if necessary) and click "Start." On the next screen, click (in the left menu) "+Add a new instance." That will start up a terminal in your browser. Run the following commands to start the Faber agent.
```bash
@@ -55,6 +51,13 @@ Once the Faber agent has started up (with the invite displayed), click the link
**Remember that the OpenAPI/Swagger browser tab with an address containing 8021 is the Faber agent.**
+
+ Show me a screenshot!
+ 
+
+
+### Start the Alice Agent
+
Now to start Alice's agent. Click the "+Add a new instance" button again to open another terminal session. Run the following commands to start Alice's agent:
```bash
@@ -67,12 +70,19 @@ Once the Alice agent has started up (with the `invite:` prompt displayed), click
**Remember that the OpenAPI/Swagger browser tab with an address containing 8031 is Alice's agent.**
+
+ Show me a screenshot!
+ 
+
+
You are ready to go. Skip down to the [Using the OpenAPI/Swagger User Interface](#using-the-openapiswagger-user-interface) section.
## Running in Docker
To run the demo on your local system, you must have git, a running Docker installation, and terminal windows running bash. Need more information about getting set up? Click [here](https://github.com/cloudcompass/ToIPLabs/blob/master/docs/LFS173x/RunningLabs.md#running-on-docker-locally) to learn more.
+### Start the Faber Agent
+
To begin running the demo in Docker, open up two terminal windows, one each for the Faber’s and Alice’s agent.
In the first terminal window, clone the ACA-Py repo, change into the demo folder and start the Faber agent:
@@ -87,6 +97,13 @@ If all goes well, the agent will show a message indicating it is running. Use th
**Remember that the OpenAPI/Swagger browser tab with an address containing 8021 is the Faber agent.**
+
+ Show me a screenshot!
+ 
+
+
+### Start the Alice Agent
+
To start Alice's agent, open up a second terminal window and in it, change to the same `demo` directory as where Faber's agent was started above. Once there, start Alice's agent:
``` bash
@@ -97,6 +114,11 @@ If all goes well, the agent will show a message indicating it is running. Open a
**Remember that the OpenAPI/Swagger browser tab with an address containing 8031 is Alice's agent.**
+
+ Show me a screenshot!
+ 
+
+
### Restarting the Docker Containers
When you are done, or to stop the demo so you can restart it, hit Ctrl-C in the Faber and Alice agent terminal windows to terminate the agents.
@@ -126,30 +148,171 @@ Enough with the preliminaries, let’s get started!
We’ll start the demo by establishing a connection between the Alice and Faber agents. We’re starting there to demonstrate that you can use agents without having a ledger. We won’t be using the Indy public ledger at all for this step. Since the agents communicate using DIDcomm messaging and connect by exchanging pairwise DIDs and DIDDocs based on (an early version of) the `did:peer` DID method, a public ledger is not needed.
+### Use the Faber Agent to Create an Invitation
+
In the Faber browser tab, execute the **`POST /connections/create-invitation`** endpoint. No input data is needed to be added for this call. If successful, you should see a connection ID, an invitation, and the invitation URL. The IDs will be different on each run.
+**Hint: set an Alias on the Invitation, this makes it easier to find the Connection later on**
+
+
+ Show me a screenshot - Create Invitation Request
+ 
+
+
+
+ Show me a screenshot - Create Invitation Response
+ 
+
+
+### Copy the Invitation created by the Faber Agent
+
Copy the entire block of the `invitation` object, from the curly brackets `{}`, excluding the trailing comma.
+
+ Show me a screenshot - Create Invitation Response
+ 
+
+
Before switching over to the Alice browser tab, scroll to and execute the **`GET /connections`** endpoint to see the list of Faber's connections. You should see a connection with a `connection_id` that is identical to the invitation you just created, and that its state is `invitation`.
+
+ Show me a screenshot - Faber Connection Status
+ 
+
+
+### Use the Alice Agent to Receive Faber's Invitation
+
Switch to the Alice browser tab and get ready to execute the **`POST /connections/receive-invitation`** endpoint. Select all of the pre-populated text and replace it with the invitation object from the Faber tab. When you click `Execute` you should get back a connection response with a connection ID, an invitation key, and the state of the connection, which should be `request`.
+**Hint: set an Alias on the Invitation, this makes it easier to find the Connection later on**
+
+
+ Show me a screenshot - Receive Invitation Request
+ 
+
+
+
+ Show me a screenshot - Receive Invitation Response
+ 
+
+
> A key observation to make here. The "copy and paste" we are doing here from Faber's agent to Alice's agent is what is called an "out of band" message. Because we don't yet have a DIDComm connection between the two agents, we have to convey the invitation in plaintext (we can't encrypt it - no channel) using some other mechanism than DIDComm. With mobile agents, that's where QR codes often come in. Once we have the invitation in the receivers agent, we can get back to using DIDComm.
The connection response returned from the previous **`POST /connections/receive-invitation`** endpoint call will currently show a connection state of `invitation` rather than `request`.
-At this point Alice has simply stored the invitation in her wallet. To complete a connection with Faber, she must accept the invitation and send a corresponding connection request to Faber. Find the `connection_id` in the connection response from the previous **`POST /connections/receive-invitation`** endpoint call. Scroll to the **`POST /connections/{id}/accept-invitation`** endpoint and paste the `connection_id` in the `id` parameter field (you will have to click the `Try it out` button to see the available URL parameters). The response from clicking `Execute` should show that the connection has a state of `request`.
+### Tell Alice's Agent to *Accept* the Invitation
+
+At this point Alice has simply stored the invitation in her wallet. You can see the status using the **`GET /connections`** endpoing.
+
+
+ Show me a screenshot
+ 
+
+
+To complete a connection with Faber, she must accept the invitation and send a corresponding connection request to Faber. Find the `connection_id` in the connection response from the previous **`POST /connections/receive-invitation`** endpoint call. Scroll to the **`POST /connections/{id}/accept-invitation`** endpoint and paste the `connection_id` in the `id` parameter field (you will have to click the `Try it out` button to see the available URL parameters). The response from clicking `Execute` should show that the connection has a state of `request`.
+
+
+ Show me a screenshot - Accept Invitation Request
+ 
+
+
+
+ Show me a screenshot - Accept Invitation Response
+ 
+
+
+### Review Faber's Connection Status
Switch over to the Faber broswer tab, scroll to and execute the **`GET /connections`** endpoint. Note the connection that was previously created. It's state is now `request`, which indicates that Alice has accepted the invitation and has sent a corresponding connection request to Faber. Copy the `connection_id` for the next step.
+
+ Show me a screenshot - Accept Connection Request
+ 
+
+
+We were notified that Alice received our invition and requested a connection through an EVENT, a web service callback from the agent to our controller:
+
+
+ Show me the event
+ 
+
+
+### Tell the Faber Agent to Accept the Connection Request from Alice
+
To complete the connection process, Faber will respond to the connection request from Alice. Scroll to the **`POST /connections/{id}/accept-request`** endpint and paste the `connection_id` you previously copied into the `id` parameter field (you will have to click the `Try it out` button to see the available URL parameters). The response from clicking the `Execute` button should show that the connection has a state of `response`, which indicates that Faber has accepted Alice's connection request.
+
+ Show me a screenshot - Accept Connection Request
+ 
+
+
+
+ Show me a screenshot - Accept Connection Request
+ 
+
+
+### Review the Connection Status in Alice's Agent
+
Switch over the the Alice browser tab.
Scroll to and execute **`GET /connections`** to see a list of Alice's connections, and the information tracked about each connection. You should see the one connection Alice’s agent has, that it is with the Faber agent, and that its state is `active`.
+
+ Show me a screenshot - Alice Connection Status
+ 
+
+
+As with Faber's side of the connection, Alice received a notification that Faber had accepted her connection request.
+
+
+ Show me a the event
+ 
+
+
+### Review the Connection Status in Faber's Agent
+
You are connected! Switch to the Faber browser tab and run the same **`GET /connections`** endpoint to see Faber's view of the connection. Its state is also `active`. Note the `connection_id`, you’ll need it later in the tutorial.
+
+ Show me a screenshot - Faber Connection Status
+ 
+
+
+## Basic Messaging Between Agents
+
+Once you have a connection between two agents, you have a channel to exchange secure, encrypted messsages. In fact these basic messages are the foundation of all other protocols, such as issuing Credentials and providing Proofs. So, let's send a couple of messages.
+
+### Sending a message from Alice to Faber
+
+In Alice's swagger page, scroll to the **`POST /connections/{id}/send-message`** endpoint. Click on `Try it Out` and enter a message in the body provided (for example `{"content": "Hello Faber"}`). Enter the connection id of Alice's connection in the field provided. Then click on `Execute`.
+
+
+ Show me a screenshot
+ 
+
+
+### Receiving a Basic Message (Faber)
+
+How does Faber know that a message was sent? If you take a look at Faber's console window, you can see that Faber's agent has raised an Event that the message was received:
+
+
+ Show me a screenshot
+ 
+
+
+Faber's controller application can take whatever action is necessary to process this message. It could trigger some applicaiton code, or it might just be something the Faber application needs to display to its user (for example a reminder about some action the user needs to take).
+
+### Alice Agent Verifies that Faber has Received the Message
+
+How does Alice get feedback that Faber has received the message? The same way - when Faber's agent acknowledges receipt of the message, Alice's agent raises an Event to let the Alice controller know:
+
+
+ Show me a screenshot
+ 
+
+
+Again, Alice's agent can take whatever action is necessary, possibly just flagging the message as having been `received`.
+
## Preparing to Issue a Credential
The next thing we want to do in the demo is have the Faber agent issue a credential to Alice’s agent. To this point, we have not used the Indy ledger at all. Establishing the connection and all the messaging has been done with pairwise DIDs based on the `did:peer` method. Verifiable credentials must be rooted in a public DID ledger to enable the presentation of proofs.
@@ -162,24 +325,79 @@ Before the Faber agent can issue a credential, it must register a DID on the Ind
The schema and credential definition could also be created through this swagger interface.
-You can confirm the schema and credential definition were published by going back to the Indy ledger browser tab. You can view the `Domain` page, refresh, scroll to the bottom and you should see transactions for the new schema and credential definition.
+### Confirming your Schema and Credential Definition
+
+You can confirm the schema and credential definition were published by going back to the Indy ledger browser tab.
+
+First confirm the DID you used to write to the ledger. Open Faber's swagger page and scroll to the **`GET /wallet/did/public`** endpoint. Click on `Try it Out` and `Execute` and you will see your public DID.
+
+
+ Show me a screenshot
+ 
+
+
+On the BCovrin ledger browser, view the `Domain` page, refresh, and paste your DID into the `Filter:` field:
+
+
+ Show me a screenshot
+ 
+
+
+The ledger browser should refresh and display the four (4) transactions on the ledger related to this DID:
+
+- the initial DID registration
+- registration of the DID endpoint (Faber is an issuer so it has a public endpoint)
+- the registered schema
+- the registered credential definition
+
+
+ Show me the ledger transactions
+ 
+ 
+ 
+ 
+
+
+You can also look up the Schema and Credential Definition information using Faber's swagger page.
+
+You can use the **`GET /schemas/created`** endpoint to get a list of schema id's created by this agent, and then **`GET /schemas/{id}`** to get details on a specific schema.
+
+
+ Show me a screenshot
+ 
+ 
+
+
+Likewise you can use the **`GET /credential-definitions/created`** endpoint ot get a list of credential definition id's, and then use the **`GET /credential-definitions/{id}`** endpoint to get informaiton on a specific credential definition.
+
+
+ Show me a screenshot
+ 
+ 
+
+
+Either way, you will need information on the schema and credential definition in order to issue a Credential, which is what we will do next!
+
+(You can use the **`POST`** endpoints to create a new schema and credential definition if you like.)
### Notes
-OK, the one time setup work for issuing a credential complete. We can now issue 1 or a million credentials without having to do those steps again. Astute readers might note that we did not setup a revocation registry, so we cannot revoke the credentials we issue with that credential definition. You can’t have everything in an easy demo (and we’re still working on enabling that).
+The one time setup work for issuing a credential complete. We can now issue 1 or a million credentials without having to do those steps again. Astute readers might note that we did not setup a revocation registry, so we cannot revoke the credentials we issue with that credential definition. You can’t have everything in an easy demo (and we’re still working on enabling that).
## Issuing a Credential
Issuing a credential from the Faber agent to Alice’s agent is done with another API call. In the Faber browser tab, scroll down to the **`POST /issue-credential/send`** and get ready to (but don’t yet) execute the request. Before execution, you need to find some other data to complete the JSON. Keep a notepad ready to copy the data you find.
+### Faber - Preparing to Issue a Credential
+
First, scroll back up to the **`GET /connections`** API endpoint and execute it. From the result, find the the `connection_id` and copy the value.
Click here to see a screenshot
- 
+ 
-A little trickier to find is the `cred_def_id`. Go back to the terminal where you started the Faber agent, and scroll back until you see the text `#3/4 Create a new schema/cred def on the ledger` and then just below that `Cred def ID:`. Copy the text following that label. While you are at it, copy the text following the label `Schema ID:` as well.
+A little trickier to find is the `cred_def_id`. (We'll look up the schema and credential definition information in our Faber terminal window.) Go back to the terminal where you started the Faber agent, and scroll back until you see the text `#3/4 Create a new schema/cred def on the ledger` and then just below that `Cred def ID:`. Copy the text following that label. While you are at it, copy the text following the label `Schema ID:` as well.
Show me a screenshot!
@@ -206,6 +424,8 @@ We now have (almost) all the information we need to fill in the JSON. The good n
Use the data that you gathered in the steps above to fill in the vales for `schema_issuer_did:` (the public DID of Faber Agent), `schema_id:` (the text following `Schema ID:` that you scraped off the Faber Agent terminal), `cred_def_id:` (the text following `Cred def ID:` scraped off the Faber Agent terminal), `issuer_did:` (the public DID of Faber Agent), `schema_name` and `schema_version` (values copied from the schema entry of the `Domain` ledger).
+### Faber - Issuing the Credential
+
Now we need put into the JSON the data values for the credential. Copy and paste the following between the `attributes` square brackets. Feel free to change the attribute values (but neither the labels nor the names) as you see fit:
```
@@ -229,9 +449,61 @@ Now we need put into the JSON the data values for the credential. Copy and paste
Ok, finally, you are ready to click `Execute`. The request should work, but if it doesn’t - check your JSON! Did you get all the quotes and commas right?
+
+ Show me a screenshot
+ 
+ 
+
+
To confirm the issuance worked, scroll up to the top of the `v1.0 issue-credential exchange` section and execute the **`GET /issue-credential/records`** endpoint. You should see a lot of information about the exchange, including the state - `credential_acked`.
-Let’s look at it from Alice’s side. Switch to the Alice’s agent browser tab, find the `credentials` section and within that, execute the **`GET /credentials`** endpoint. There should be a list of credentials held by Alice, with just a single entry, the credential issued from the Faber agent. Note that the element `referent` is the value of the `credential_id` element used in other calls. `referent` is the name returned in the `indy-sdk` call to get the set of credentials for the wallet and ACA-Py code is not changing it in the response.
+### Alice Receives Credential
+
+Let’s look at it from Alice’s side. We have started up our agents in "auto" mode, so a lot of the messages have been automatically handled and responded.
+
+Alice's agent first received a notification of a Credetial Offer, to which it responded with a Credential Request. Faber received the Credential Request and responded in turn with an Issue Credential message.
+
+
+ Show me a screenshot
+ 
+ 
+
+
+### Alice Stores Credential in her Wallet
+
+Because we are not fully "auto", we need to explicitely tell the agent to store the credential in the wallet.
+
+
+ Show me a screenshot
+ 
+ 
+
+
+
+ Show me a screenshot
+ 
+ 
+
+
+Now, in Alice’s agent browser tab, find the `credentials` section and within that, execute the **`GET /credentials`** endpoint. There should be a list of credentials held by Alice, with just a single entry, the credential issued from the Faber agent. Note that the element `referent` is the value of the `credential_id` element used in other calls. `referent` is the name returned in the `indy-sdk` call to get the set of credentials for the wallet and ACA-Py code is not changing it in the response.
+
+### Faber Receives Acknowledgment that the Credential was Received
+
+Faber has also received some events ...
+
+
+ Show me a screenshot
+ 
+
+
+Faber has received some events:
+
+
+ Show me a screenshot
+ 
+ 
+ 
+
You’ve done it, issued a credential! w00t!
@@ -246,10 +518,14 @@ Those that know something about the Indy process for issuing a credential and th
If you would like to perform all of the issuance steps manually on the Faber agent side, use a sequence of the other `/issue-credential/` messages. Use the **`GET /issue-credential/records`** to both check the credential exchange state as you progress through the protocol and to find some of the data you’ll need in executing the sequence of requests.
+<< TODO list the events, and the corresponding API calls to move to the next step >>
+
## Requesting/Presenting a Proof
Alice now has her Faber credential. Let’s have the Faber agent send a request for a presentation (a proof) using that credential. This should be pretty easy for you at this point.
+### Faber sends a Proof Request
+
From the Faber browser tab, get ready to execute the **`POST /present-proof/send-request`** endpoint. Select the entire pre-populated text and replace it with the following. In doing so, use the techniques we used in issuing the credential to replace the sample values for each instance of `cred_def_id` (there are four) and `connection_id`.
``` JSONC
@@ -305,12 +581,230 @@ From the Faber browser tab, get ready to execute the **`POST /present-proof/send
Notice that the proof request is using a predicate to check if Alice is older than 18 without asking for her age. (Not sure what this has to do with her education level!) Click `Execute` and cross your fingers. If the request fails check your JSON!
+
+ Show me a screenshot
+ 
+ 
+
+
+### Alice - Responding to the Proof Request
+
+As before, Alice receives a notification event from her agent telling her she ahs received a Proof Request. In our scenario, the agent automatically selects a matching credential and responds with a Proof.
+
+
+ Show me a screenshot
+ 
+ 
+
+
+(In real life, for example if Alice had a mogile agent on her smartphone, the agent would prompt Alice whether she wanted to respond or not. We'll see this scenario in a bit ...)
+
+### Faber - Verifying the Proof
+
Note that in the response, the state is `request_sent`. That is because when the HTTP response was generated (immediately after sending the request), Alice’s agent had not yet responded to the request. We’ll have to do another request to verify the presentation worked. Copy the value of the `presentation_exchange_id` field from the response and use it in executing the **`GET /present-proof/records/{pres_ex_id}`** endpoint. That should return a result showing the state as `verified` and `verified` as `true`. Proof positive!
+You can see some of Faber's activity below:
+
+
+ Show me a screenshot
+ 
+ 
+ 
+ 
+
+
### Notes
As with the issue credential process, the agents handled some of the presentation steps without bothering the controller. In this case, Alice’s agent processed the presentation request automatically because it was started with the `--auto-respond-presentation-request` parameter set, and her wallet contained exactly one credential that satisfied the presentation-request from the Faber agent. Similarly, the Faber agent was started with the `--auto-verify-presentation` parameter and so on receipt of the presentation, it verified the presentation and updated the status accordingly.
+### Bonus Points
+
+If you would like to perform all of the proof request/response steps manually ... >
+
+<>
+
+## Issuing Credentials to a Mobile Agent
+
+You can use the Faber aca-py agent to issue credentials to a mobile wallet. To do this you need to run the Faber agent on a publicly accessible port (for example you can run the agent on Play With Docker), and you need a compatible wallet. One available wallet is the Streetcred Identity Agent, which is available on both iOS and Android, and you can read about it [here](https://github.com/bcgov/identity-kit-poc/blob/master/docs/GettingApp.md).
+
+### Introduction to the Streetcred Agent
+
+Search for "Streetcred Identity Wallet" on the App Store or Google Play.
+
+
+ Click here to view screenshot (iOS)
+ 
+
+
+Start the app and accept the terms of service to create an Agent.
+
+
+ Click here to view screenshot (iOS)
+ 
+
+
+Enble Face ID (or Android equivalent) to secure the Agent.
+
+
+ Click here to view screenshot (iOS)
+ 
+
+
+Enable notifications (or else you will have to continually refresh the Agent to get updates).
+
+
+ Click here to view screenshot (iOS)
+ 
+
+
+Before connecting with the BC Government applications, you must do some additional setup, as follows:
+
+- Go to settings by clicking the menu icon in the top right (the "hamburger" icon—three stacked horizontal lines)
+- Click on the "Network" item and from the subsequent list select "BCovrin Test" network.
+- Click the back arrow to return to the settings and again to return to the main menu.Streetcred app screen.
+
+
+ Click here to view screenshot (iOS)
+ 
+
+
+### Setting up your Issuing Agent on a Public Port
+
+Run Play With Docker and start your agent using the BCovrin Test network:
+
+```bash
+git clone https://github.com/hyperledger/aries-cloudagent-python
+cd aries-cloudagent-python/demo
+LEDGER_URL=http://test.bcovrin.vonx.io ./run_demo faber --events
+```
+
+This is similar to the instructions in the prior "Play with Docker" section, except not that:
+
+- We are using the BCovrin Test network (it has to use the same network as the mobile app)
+- We are running in "auto" mode, so we will have to do fewer manual acknowledgements
+- Play with Docker exposes the Agent's' port (in this case port 8021 of the container) on a public URL that the mobile app can access
+
+(An alternative for running locally - left as an excercise for the user - is to use ngrok and then set your agent's endpoint to the ngrok url.)
+
+### Creating an Invitation
+
+When the Faber agent starts up it automatically creates an invitation, we will copy the "url" format of the invitation for the next step. Copy all the text between the quotes (do not include the quotes) - the copied text should be a properly formatted URL.
+
+
+ Click here to view screenshot
+ 
+
+
+### Converting the Invitation to a QR Code
+
+To send the invitation to the agent, we need to convert the URl into a QR code. Your application can do this, but for this demo we will use https://www.the-qrcode-generator.com/
+
+Open up https://www.the-qrcode-generator.com/ in a new browser window, and:
+
+- Select the "URL" option
+- Paste your invitation url into the provided input field
+
+
+ Click here to view screenshot
+ 
+
+
+### Accepting the Invitation with Streetcred
+
+On the Streetcred mobile app, select "SCAN CODE" and point your camera at the generated QR code. Streetcred should automatically capture the code and ask you to confirm the connection. GO ahead and confirm.
+
+
+ Click here to view screenshot
+ 
+
+
+Streetcred will then give you a message that "A connection was added to your wallet".
+
+
+ Click here to view screenshot
+ 
+ 
+
+
+### Accepting Streetcred's connection request
+
+At this point Faber has issued an invitation, and you have accpted the invitation and asked Faber to establish a connection to your agent. Faber must now accept this request. You can see the Event in the Faber console window. Find this event, and select and copy the "connection id".
+
+
+ Click here to view screenshot
+ 
+
+
+Now, in Faber's swagger page (at the top of the console window, click on port `8021` to open the swagger page in a new window) scroll down to the **`POST /connections/{id}/accept-request`** endpoint, paste the connection id and click on "Execute".
+
+
+ Click here to view screenshot
+ 
+ 
+
+
+Scroll to the **`GET /connections`** endpoint to check the status of the connection.
+
+
+ Click here to view screenshot
+ 
+
+
+Note - if the connection status does not update to `active`, try sending a `trust-ping` or `basic-message` on the connection. This will force a handshake between the agents that whould upate the connection status.
+
+### Issuing a Credential
+
+We will use the Faber console to issue a credential. (This could be done using the REST API as we have done above, this will be left as an exercise to the user.)
+
+In the Faber console, select option `1` to send a credential to streetcred.
+
+
+ Click here to view screenshot
+ 
+
+
+### Accepting the Credential with Streetcred
+
+The credential should automatically show up in streetcred - accept the offered credential.
+
+
+ Click here to view screenshot
+ 
+ 
+ 
+
+
+### Issuing a Proof Request
+
+We will use the Faber console to ask Streetcred for a proof. (This could be done using the REST API as we have done above, this will be left as an exercise to the user.)
+
+In the Faber console, select option `2` to send a proof request to streetcred.
+
+
+ Click here to view screenshot
+ 
+
+
+### Responding to the Proof Request with Streetcred
+
+In streetcred, respond to the proof
+
+
+ Click here to view screenshot
+ 
+ 
+ 
+
+
+### Review the Received Proof
+
+In the Faber console window, the proof should be received as validated.
+
+
+ Click here to view screenshot
+ 
+
+
## Conclusion
That’s the OpenAPI-based tutorial. Feel free to play with the API and learn how it works. More importantly, as you implement a controller, use the OpenAPI user interface to test out the calls you will be using as you go. The list of API calls is grouped by protocol and if you are familiar with the protocols (Aries RFCs) the API call names should be pretty obvious.
diff --git a/demo/collateral/1-Faber-Invitation-1.png b/demo/collateral/1-Faber-Invitation-1.png
new file mode 100644
index 0000000000..09e7729378
Binary files /dev/null and b/demo/collateral/1-Faber-Invitation-1.png differ
diff --git a/demo/collateral/1-Faber-Invitation-2.png b/demo/collateral/1-Faber-Invitation-2.png
new file mode 100644
index 0000000000..5f16941a23
Binary files /dev/null and b/demo/collateral/1-Faber-Invitation-2.png differ
diff --git a/demo/collateral/1-Faber-Invitation-3.png b/demo/collateral/1-Faber-Invitation-3.png
new file mode 100644
index 0000000000..182732ca35
Binary files /dev/null and b/demo/collateral/1-Faber-Invitation-3.png differ
diff --git a/demo/collateral/1-Faber-Invitation-4.png b/demo/collateral/1-Faber-Invitation-4.png
new file mode 100644
index 0000000000..a5ae4afa51
Binary files /dev/null and b/demo/collateral/1-Faber-Invitation-4.png differ
diff --git a/demo/collateral/2-Alice-Invitation-1.png b/demo/collateral/2-Alice-Invitation-1.png
new file mode 100644
index 0000000000..a4020f0696
Binary files /dev/null and b/demo/collateral/2-Alice-Invitation-1.png differ
diff --git a/demo/collateral/2-Alice-Invitation-2.png b/demo/collateral/2-Alice-Invitation-2.png
new file mode 100644
index 0000000000..4dc7bda9dd
Binary files /dev/null and b/demo/collateral/2-Alice-Invitation-2.png differ
diff --git a/demo/collateral/2-Alice-Invitation-3.png b/demo/collateral/2-Alice-Invitation-3.png
new file mode 100644
index 0000000000..6326d15b59
Binary files /dev/null and b/demo/collateral/2-Alice-Invitation-3.png differ
diff --git a/demo/collateral/2-Alice-Invitation-4.png b/demo/collateral/2-Alice-Invitation-4.png
new file mode 100644
index 0000000000..54337ce7ad
Binary files /dev/null and b/demo/collateral/2-Alice-Invitation-4.png differ
diff --git a/demo/collateral/2-Alice-Invitation-5.png b/demo/collateral/2-Alice-Invitation-5.png
new file mode 100644
index 0000000000..94a6d3e7bb
Binary files /dev/null and b/demo/collateral/2-Alice-Invitation-5.png differ
diff --git a/demo/collateral/3-Faber-Connection-1.png b/demo/collateral/3-Faber-Connection-1.png
new file mode 100644
index 0000000000..4510b98495
Binary files /dev/null and b/demo/collateral/3-Faber-Connection-1.png differ
diff --git a/demo/collateral/3-Faber-Connection-2.png b/demo/collateral/3-Faber-Connection-2.png
new file mode 100644
index 0000000000..5ecd1afc2a
Binary files /dev/null and b/demo/collateral/3-Faber-Connection-2.png differ
diff --git a/demo/collateral/3-Faber-Connection-3.png b/demo/collateral/3-Faber-Connection-3.png
new file mode 100644
index 0000000000..51a117c1f8
Binary files /dev/null and b/demo/collateral/3-Faber-Connection-3.png differ
diff --git a/demo/collateral/3-Faber-Connection-4.png b/demo/collateral/3-Faber-Connection-4.png
new file mode 100644
index 0000000000..917e4e1aaa
Binary files /dev/null and b/demo/collateral/3-Faber-Connection-4.png differ
diff --git a/demo/collateral/4-Alice-Connection-1.png b/demo/collateral/4-Alice-Connection-1.png
new file mode 100644
index 0000000000..4658fe3c64
Binary files /dev/null and b/demo/collateral/4-Alice-Connection-1.png differ
diff --git a/demo/collateral/4-Alice-Connection-2.png b/demo/collateral/4-Alice-Connection-2.png
new file mode 100644
index 0000000000..fdf95c9462
Binary files /dev/null and b/demo/collateral/4-Alice-Connection-2.png differ
diff --git a/demo/collateral/5-Faber-Connection-1.png b/demo/collateral/5-Faber-Connection-1.png
new file mode 100644
index 0000000000..f79b70c0d8
Binary files /dev/null and b/demo/collateral/5-Faber-Connection-1.png differ
diff --git a/demo/collateral/6-Alice-Basic-Msg.png b/demo/collateral/6-Alice-Basic-Msg.png
new file mode 100644
index 0000000000..3a7491c3ac
Binary files /dev/null and b/demo/collateral/6-Alice-Basic-Msg.png differ
diff --git a/demo/collateral/7-Faber-Basic-Msg.png b/demo/collateral/7-Faber-Basic-Msg.png
new file mode 100644
index 0000000000..f9c1aa6507
Binary files /dev/null and b/demo/collateral/7-Faber-Basic-Msg.png differ
diff --git a/demo/collateral/8-Alice-Basic-Msg.png b/demo/collateral/8-Alice-Basic-Msg.png
new file mode 100644
index 0000000000..5bee95a292
Binary files /dev/null and b/demo/collateral/8-Alice-Basic-Msg.png differ
diff --git a/demo/collateral/Alice-Agent-Local.png b/demo/collateral/Alice-Agent-Local.png
new file mode 100644
index 0000000000..e5ca4b1792
Binary files /dev/null and b/demo/collateral/Alice-Agent-Local.png differ
diff --git a/demo/collateral/Alice-Agent.png b/demo/collateral/Alice-Agent.png
new file mode 100644
index 0000000000..45b39006da
Binary files /dev/null and b/demo/collateral/Alice-Agent.png differ
diff --git a/demo/collateral/C-1-Faber-DID-Public.png b/demo/collateral/C-1-Faber-DID-Public.png
new file mode 100644
index 0000000000..e26dc58493
Binary files /dev/null and b/demo/collateral/C-1-Faber-DID-Public.png differ
diff --git a/demo/collateral/C-2-Faber-Ledger-Search-0.png b/demo/collateral/C-2-Faber-Ledger-Search-0.png
new file mode 100644
index 0000000000..76ead13e9c
Binary files /dev/null and b/demo/collateral/C-2-Faber-Ledger-Search-0.png differ
diff --git a/demo/collateral/C-2-Faber-Ledger-Search-1.png b/demo/collateral/C-2-Faber-Ledger-Search-1.png
new file mode 100644
index 0000000000..19ff964071
Binary files /dev/null and b/demo/collateral/C-2-Faber-Ledger-Search-1.png differ
diff --git a/demo/collateral/C-2-Faber-Ledger-Search-2.png b/demo/collateral/C-2-Faber-Ledger-Search-2.png
new file mode 100644
index 0000000000..589172c6c1
Binary files /dev/null and b/demo/collateral/C-2-Faber-Ledger-Search-2.png differ
diff --git a/demo/collateral/C-2-Faber-Ledger-Search-3.png b/demo/collateral/C-2-Faber-Ledger-Search-3.png
new file mode 100644
index 0000000000..c7af2d6f8a
Binary files /dev/null and b/demo/collateral/C-2-Faber-Ledger-Search-3.png differ
diff --git a/demo/collateral/C-2-Faber-Ledger-Search-4.png b/demo/collateral/C-2-Faber-Ledger-Search-4.png
new file mode 100644
index 0000000000..de994f9645
Binary files /dev/null and b/demo/collateral/C-2-Faber-Ledger-Search-4.png differ
diff --git a/demo/collateral/C-3-Faber-Info-1.png b/demo/collateral/C-3-Faber-Info-1.png
new file mode 100644
index 0000000000..5889efd93e
Binary files /dev/null and b/demo/collateral/C-3-Faber-Info-1.png differ
diff --git a/demo/collateral/C-3-Faber-Info-2.png b/demo/collateral/C-3-Faber-Info-2.png
new file mode 100644
index 0000000000..b128f1a8a3
Binary files /dev/null and b/demo/collateral/C-3-Faber-Info-2.png differ
diff --git a/demo/collateral/C-3-Faber-Info-3.png b/demo/collateral/C-3-Faber-Info-3.png
new file mode 100644
index 0000000000..7134e785b0
Binary files /dev/null and b/demo/collateral/C-3-Faber-Info-3.png differ
diff --git a/demo/collateral/C-3-Faber-Info-4.png b/demo/collateral/C-3-Faber-Info-4.png
new file mode 100644
index 0000000000..7dded1571e
Binary files /dev/null and b/demo/collateral/C-3-Faber-Info-4.png differ
diff --git a/demo/collateral/C-3-Faber-Info-5.png b/demo/collateral/C-3-Faber-Info-5.png
new file mode 100644
index 0000000000..05b580d61d
Binary files /dev/null and b/demo/collateral/C-3-Faber-Info-5.png differ
diff --git a/demo/collateral/C-4-Faber-Credential-Offer-1.png b/demo/collateral/C-4-Faber-Credential-Offer-1.png
new file mode 100644
index 0000000000..87cea9f388
Binary files /dev/null and b/demo/collateral/C-4-Faber-Credential-Offer-1.png differ
diff --git a/demo/collateral/C-4-Faber-Credential-Offer-2.png b/demo/collateral/C-4-Faber-Credential-Offer-2.png
new file mode 100644
index 0000000000..a9c5d675be
Binary files /dev/null and b/demo/collateral/C-4-Faber-Credential-Offer-2.png differ
diff --git a/demo/collateral/C-5-Alice-Credential-Offer-1.png b/demo/collateral/C-5-Alice-Credential-Offer-1.png
new file mode 100644
index 0000000000..58134277e6
Binary files /dev/null and b/demo/collateral/C-5-Alice-Credential-Offer-1.png differ
diff --git a/demo/collateral/C-5-Alice-Credential-Offer-2.png b/demo/collateral/C-5-Alice-Credential-Offer-2.png
new file mode 100644
index 0000000000..4de1206d9f
Binary files /dev/null and b/demo/collateral/C-5-Alice-Credential-Offer-2.png differ
diff --git a/demo/collateral/C-6-Faber-Credential-Request.png b/demo/collateral/C-6-Faber-Credential-Request.png
new file mode 100644
index 0000000000..cdcbe6c90b
Binary files /dev/null and b/demo/collateral/C-6-Faber-Credential-Request.png differ
diff --git a/demo/collateral/C-7-Alice-Store-Credential-1.png b/demo/collateral/C-7-Alice-Store-Credential-1.png
new file mode 100644
index 0000000000..6994e4eca7
Binary files /dev/null and b/demo/collateral/C-7-Alice-Store-Credential-1.png differ
diff --git a/demo/collateral/C-7-Alice-Store-Credential-2.png b/demo/collateral/C-7-Alice-Store-Credential-2.png
new file mode 100644
index 0000000000..e1a2931df5
Binary files /dev/null and b/demo/collateral/C-7-Alice-Store-Credential-2.png differ
diff --git a/demo/collateral/C-7-Alice-Store-Credential-3.png b/demo/collateral/C-7-Alice-Store-Credential-3.png
new file mode 100644
index 0000000000..e499cb9d6c
Binary files /dev/null and b/demo/collateral/C-7-Alice-Store-Credential-3.png differ
diff --git a/demo/collateral/C-7-Alice-Store-Credential-4.png b/demo/collateral/C-7-Alice-Store-Credential-4.png
new file mode 100644
index 0000000000..b34d593835
Binary files /dev/null and b/demo/collateral/C-7-Alice-Store-Credential-4.png differ
diff --git a/demo/collateral/C-8-Faber-Credential-Ack-0.png b/demo/collateral/C-8-Faber-Credential-Ack-0.png
new file mode 100644
index 0000000000..455927a69f
Binary files /dev/null and b/demo/collateral/C-8-Faber-Credential-Ack-0.png differ
diff --git a/demo/collateral/C-8-Faber-Credential-Ack-1.png b/demo/collateral/C-8-Faber-Credential-Ack-1.png
new file mode 100644
index 0000000000..a8dd4de0fe
Binary files /dev/null and b/demo/collateral/C-8-Faber-Credential-Ack-1.png differ
diff --git a/demo/collateral/C-8-Faber-Credential-Ack-2.png b/demo/collateral/C-8-Faber-Credential-Ack-2.png
new file mode 100644
index 0000000000..a6147ecb6d
Binary files /dev/null and b/demo/collateral/C-8-Faber-Credential-Ack-2.png differ
diff --git a/demo/collateral/Faber-Agent-Local.png b/demo/collateral/Faber-Agent-Local.png
new file mode 100644
index 0000000000..fb686c9506
Binary files /dev/null and b/demo/collateral/Faber-Agent-Local.png differ
diff --git a/demo/collateral/Faber-Agent.png b/demo/collateral/Faber-Agent.png
new file mode 100644
index 0000000000..78fb2749d0
Binary files /dev/null and b/demo/collateral/Faber-Agent.png differ
diff --git a/demo/collateral/P-1-Faber-Proof-Request-1.png b/demo/collateral/P-1-Faber-Proof-Request-1.png
new file mode 100644
index 0000000000..fd7da18440
Binary files /dev/null and b/demo/collateral/P-1-Faber-Proof-Request-1.png differ
diff --git a/demo/collateral/P-1-Faber-Proof-Request-2.png b/demo/collateral/P-1-Faber-Proof-Request-2.png
new file mode 100644
index 0000000000..f1b55b38b9
Binary files /dev/null and b/demo/collateral/P-1-Faber-Proof-Request-2.png differ
diff --git a/demo/collateral/P-2-Alice-Proof-Request-1.png b/demo/collateral/P-2-Alice-Proof-Request-1.png
new file mode 100644
index 0000000000..f0436bc4cb
Binary files /dev/null and b/demo/collateral/P-2-Alice-Proof-Request-1.png differ
diff --git a/demo/collateral/P-2-Alice-Proof-Request-2.png b/demo/collateral/P-2-Alice-Proof-Request-2.png
new file mode 100644
index 0000000000..54ed5e17e4
Binary files /dev/null and b/demo/collateral/P-2-Alice-Proof-Request-2.png differ
diff --git a/demo/collateral/P-3-Faber-Proof-1.png b/demo/collateral/P-3-Faber-Proof-1.png
new file mode 100644
index 0000000000..94058074ab
Binary files /dev/null and b/demo/collateral/P-3-Faber-Proof-1.png differ
diff --git a/demo/collateral/P-3-Faber-Proof-2.png b/demo/collateral/P-3-Faber-Proof-2.png
new file mode 100644
index 0000000000..fc19d8805f
Binary files /dev/null and b/demo/collateral/P-3-Faber-Proof-2.png differ
diff --git a/demo/collateral/P-3-Faber-Proof-3.png b/demo/collateral/P-3-Faber-Proof-3.png
new file mode 100644
index 0000000000..0398ec6002
Binary files /dev/null and b/demo/collateral/P-3-Faber-Proof-3.png differ
diff --git a/demo/collateral/P-3-Faber-Proof-4.png b/demo/collateral/P-3-Faber-Proof-4.png
new file mode 100644
index 0000000000..ad68aef56c
Binary files /dev/null and b/demo/collateral/P-3-Faber-Proof-4.png differ
diff --git a/demo/collateral/S-0-invitation-1.png b/demo/collateral/S-0-invitation-1.png
new file mode 100644
index 0000000000..cdee1c9bf7
Binary files /dev/null and b/demo/collateral/S-0-invitation-1.png differ
diff --git a/demo/collateral/S-0-invitation-2.png b/demo/collateral/S-0-invitation-2.png
new file mode 100644
index 0000000000..6a547d92c0
Binary files /dev/null and b/demo/collateral/S-0-invitation-2.png differ
diff --git a/demo/collateral/S-1-connect-1.jpg b/demo/collateral/S-1-connect-1.jpg
new file mode 100644
index 0000000000..289e98a372
Binary files /dev/null and b/demo/collateral/S-1-connect-1.jpg differ
diff --git a/demo/collateral/S-1-connect-2.jpg b/demo/collateral/S-1-connect-2.jpg
new file mode 100644
index 0000000000..e5b98c5f1a
Binary files /dev/null and b/demo/collateral/S-1-connect-2.jpg differ
diff --git a/demo/collateral/S-1-connect-3.jpg b/demo/collateral/S-1-connect-3.jpg
new file mode 100644
index 0000000000..c1c74e712e
Binary files /dev/null and b/demo/collateral/S-1-connect-3.jpg differ
diff --git a/demo/collateral/S-2-connect-1.png b/demo/collateral/S-2-connect-1.png
new file mode 100644
index 0000000000..58839403a8
Binary files /dev/null and b/demo/collateral/S-2-connect-1.png differ
diff --git a/demo/collateral/S-2-connect-2.png b/demo/collateral/S-2-connect-2.png
new file mode 100644
index 0000000000..3c9d1b54d6
Binary files /dev/null and b/demo/collateral/S-2-connect-2.png differ
diff --git a/demo/collateral/S-2-connect-3.png b/demo/collateral/S-2-connect-3.png
new file mode 100644
index 0000000000..e0e6c6e673
Binary files /dev/null and b/demo/collateral/S-2-connect-3.png differ
diff --git a/demo/collateral/S-2-connect-4.png b/demo/collateral/S-2-connect-4.png
new file mode 100644
index 0000000000..56221e6b10
Binary files /dev/null and b/demo/collateral/S-2-connect-4.png differ
diff --git a/demo/collateral/S-3-credential-0.png b/demo/collateral/S-3-credential-0.png
new file mode 100644
index 0000000000..1846f052d2
Binary files /dev/null and b/demo/collateral/S-3-credential-0.png differ
diff --git a/demo/collateral/S-3-credential-1.jpg b/demo/collateral/S-3-credential-1.jpg
new file mode 100644
index 0000000000..d1424e15e5
Binary files /dev/null and b/demo/collateral/S-3-credential-1.jpg differ
diff --git a/demo/collateral/S-3-credential-2.jpg b/demo/collateral/S-3-credential-2.jpg
new file mode 100644
index 0000000000..f7931bdb73
Binary files /dev/null and b/demo/collateral/S-3-credential-2.jpg differ
diff --git a/demo/collateral/S-3-credential-3.jpg b/demo/collateral/S-3-credential-3.jpg
new file mode 100644
index 0000000000..6f3dab940f
Binary files /dev/null and b/demo/collateral/S-3-credential-3.jpg differ
diff --git a/demo/collateral/S-4-proof-0.png b/demo/collateral/S-4-proof-0.png
new file mode 100644
index 0000000000..76f78f3902
Binary files /dev/null and b/demo/collateral/S-4-proof-0.png differ
diff --git a/demo/collateral/S-4-proof-1.jpg b/demo/collateral/S-4-proof-1.jpg
new file mode 100644
index 0000000000..c8d2d8ef43
Binary files /dev/null and b/demo/collateral/S-4-proof-1.jpg differ
diff --git a/demo/collateral/S-4-proof-2.jpg b/demo/collateral/S-4-proof-2.jpg
new file mode 100644
index 0000000000..a8e76c5b26
Binary files /dev/null and b/demo/collateral/S-4-proof-2.jpg differ
diff --git a/demo/collateral/S-4-proof-3.jpg b/demo/collateral/S-4-proof-3.jpg
new file mode 100644
index 0000000000..935fdd2cca
Binary files /dev/null and b/demo/collateral/S-4-proof-3.jpg differ
diff --git a/demo/collateral/S-4-proof-4.png b/demo/collateral/S-4-proof-4.png
new file mode 100644
index 0000000000..82dae402c0
Binary files /dev/null and b/demo/collateral/S-4-proof-4.png differ
diff --git a/demo/collateral/ios1-install-app.jpg b/demo/collateral/ios1-install-app.jpg
new file mode 100644
index 0000000000..ef0d585ccf
Binary files /dev/null and b/demo/collateral/ios1-install-app.jpg differ
diff --git a/demo/collateral/ios2-create-agent.jpg b/demo/collateral/ios2-create-agent.jpg
new file mode 100644
index 0000000000..300fc230cf
Binary files /dev/null and b/demo/collateral/ios2-create-agent.jpg differ
diff --git a/demo/collateral/ios3-enable-security.jpg b/demo/collateral/ios3-enable-security.jpg
new file mode 100644
index 0000000000..ddbf510117
Binary files /dev/null and b/demo/collateral/ios3-enable-security.jpg differ
diff --git a/demo/collateral/ios4-enable-notifications.jpg b/demo/collateral/ios4-enable-notifications.jpg
new file mode 100644
index 0000000000..777def295c
Binary files /dev/null and b/demo/collateral/ios4-enable-notifications.jpg differ
diff --git a/demo/collateral/ios5-select-network.jpg b/demo/collateral/ios5-select-network.jpg
new file mode 100644
index 0000000000..c443f753d4
Binary files /dev/null and b/demo/collateral/ios5-select-network.jpg differ
diff --git a/demo/runners/faber.py b/demo/runners/faber.py
index a68de3db27..0cdc6ce492 100644
--- a/demo/runners/faber.py
+++ b/demo/runners/faber.py
@@ -221,15 +221,17 @@ async def main(start_port: int, no_auto: bool = False, show_timing: bool = False
{"name": "name", "restrictions": [{"issuer_did": agent.did}]},
{"name": "date", "restrictions": [{"issuer_did": agent.did}]},
{"name": "degree", "restrictions": [{"issuer_did": agent.did}]},
- {"name": "self_attested_thing"},
+ # include the following to test self-attested attributes
+ #{"name": "self_attested_thing"},
]
req_preds = [
- {
- "name": "age",
- "p_type": ">=",
- "p_value": 18,
- "restrictions": [{"issuer_did": agent.did}],
- }
+ # include the following to test zero-knowledge proofs
+ #{
+ # "name": "age",
+ # "p_type": ">=",
+ # "p_value": 18,
+ # "restrictions": [{"issuer_did": agent.did}],
+ #}
]
indy_proof_request = {
"name": "Proof of Education",