Document listing the Aries RFCs supported by ACA-Py and reference to …

README.md

@@ -13,7 +13,7 @@
 
 ## Introduction
 
-Hyperledger Aries Cloud Agent Python (ACA-Py) is a foundation for building decentralized identity applications and services running in non-mobile environments using DIDcomm messaging, the did:peer method, and verifiable credentials. With ACA-Py, Hyperledger Indy and Aries developers can focus on building applications using familiar web development technologies instead of trying to learn the nuts and bolts of low-level SDKs.
+Hyperledger Aries Cloud Agent Python (ACA-Py) is a foundation for building decentralized identity applications and services running in non-mobile environments using DIDcomm messaging, the did:peer method, and verifiable credentials. With ACA-Py, Hyperledger Indy and Aries developers can focus on building applications using familiar web development technologies instead of trying to learn the nuts and bolts of low-level SDKs. ACA-Py is built on the Aries concepts and features defined in the [Aries RFC](https://github.com/hyperledger/aries-rfcs) repository. [This document](SupportedRFCs.md) contains a (reasonably up to date) list of supported Aries RFCs by the current ACA-Py implementation.
 
 The ACA-Py development model is pretty straight forward for those familiar with web development. An ACA-Py instance is always deployed with a paired "controller" application that provides the business logic for that Aries agent. The controller receives webhook event notifications from its instance of ACA-Py and uses an HTTP API exposed by the ACA-Py instance to provide direction on how to respond to those events. The source of the business logic is left to your imagination. An interface to a legacy system? A user interface for a person? Custom code to implement a new service? You can build your controller in any language that supports making and receiving HTTP requests. Wait...that's every language!
 

SupportedRFCs.md

@@ -0,0 +1,49 @@
+# Aries RFCs Supported in aries-cloudagent-python
+
+`aries-cloudagent-python` implements the specifications and protocols that are documented primarily in the [aries-rfcs](https://github.com/hyperledger/aries-rfcs). The following is a curated and generally up to date list of the RFCs that are supported by `aries-cloudagent-python`. We try to keep this list up to date, but if you have any questions, please contact us on the #aries channel on [Hyperledger Rocketchat](https://chat.hyperledger.org) or through an issue in this repo. The list is divided into the same two sections as the Aries RFCs-concepts and features. A third section describes some features of the agent that are not yet captured by RFCs, or that are described by [Indy HIPEs](https://github.com/hyperledger/indy-hipe).
+
+## Aries RFC Concepts
+
+- [0003-protocols](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols)
+- [0004-agents](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents)
+- [0005-didcomm](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm)
+- [0008-message-id-and-threading](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0008-message-id-and-threading)
+- [0011-decorators](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0011-decorators)
+- [0017-attachments](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0017-attachments)
+- [0020-message-types](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0020-message-types)
+- [0046-mediators-and-relays](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0046-mediators-and-relays)
+- [0047-json-LD-compatibility](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0047-json-ld-compatibility)
+- [0050-wallets](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0050-wallets)
+- [0094-cross-domain messaging](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0094-cross-domain-messaging)
+
+## Aries RFC Features
+
+- [0019-encryption-envelope](https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope)
+- **In Progress**: [0023-did-exchange](https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange)
+  - The agent currently supports the Indy-HIPE [0031-connection-protocol](https://github.com/hyperledger/indy-hipe/tree/master/text/0031-connection-protocol) protocol. We will be deprecating that (but continuing to use it for existing implementations) and support DID Exchange as well. Note that the only difference between the protocols at this time is the protocol name and the message type names.
+  - The agent supports DID exchange initiated from both plaintext invitations and public DIDs that enable bypassing the invitation message.
+  - Note that the [did:peer DID Method](https://github.com/openssi/peer-did-method-spec) is not yet supported. We are currently exploring the specification and considering the impact of how the agent will support the specification.
+  - The 0030-sync-connection protocol is not yet supported, meaning that a pairwise DID, once exchanged, cannot be updated.
+- [0035-didcomm-transports](https://github.com/hyperledger/aries-rfcs/tree/master/features/0025-didcomm-transports)
+  - The agent currently supports HTTP and WebSockets for both inbound and outbound messaging. Transports are pluggable and an agent instance can use multiple inbound and outbound transports.
+- [0031-discover-features](https://github.com/hyperledger/aries-rfcs/tree/master/features/0031-discover-features)
+- [0032-message-timing](https://github.com/hyperledger/aries-rfcs/tree/master/features/0032-message-timing)
+- [0035-report-problem](https://github.com/hyperledger/aries-rfcs/tree/master/features/0035-report-problem)
+  - Claiming support for this protocol is tricky. The intention of this protocol is that it define a standard mechanism for handling errors in executing a protocol. However, the error handling is in the context of each protocol. Thus, while this protocol is technically supported in the agent, it is adopted by each protocol and thus it's handling is specific to each protocol.
+- **In Progress** [0036-issue-credential](https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential) - see [PR #60](https://github.com/hyperledger/aries-cloudagent-python/pull/60)
+  - The agent (along with a number of other agents in the community) currently supports [Version 0.1](https://hackmd.io/s/HkklVzww4) of this protocol. This protocol will be deprecated when support for RFC 0036 is added.
+- **To Be Implemented** [0037-present-proof](https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof)
+  - The agent (along with a number of other agents in the community) currently supports [Version 0.1](https://hackmd.io/s/HkklVzww4) of this protocol. This protocol will be deprecated when support for RFC 0037 is added.
+  - Work is just starting (as of the time of this update) on implementing RFC 0037 and should be completed before any other agent supports it. Should anyone need support for this now, we'll up the priority of this work.
+- [0048-trust-ping](https://github.com/hyperledger/aries-rfcs/tree/master/features/0048-trust-ping)
+- [0067-didcomm-diddoc-conventions](https://github.com/hyperledger/aries-rfcs/tree/master/features/0067-didcomm-diddoc-conventions)
+- [0092-transport-return-route](https://github.com/hyperledger/aries-rfcs/tree/master/features/0092-transport-return-route)
+  - Support for this RFC makes ACA-Py a great candidate to be the persistent endpoint cloud agent for a mobile agent.
+- [0095-basic-message](https://github.com/hyperledger/aries-rfcs/tree/master/features/0095-basic-message)
+
+## Other Capabilities
+
+- An Adminstrative API is core to the functionality of the ACA-Py implementation. The Administrative API is extended by each protocol deployed in an instance of ACA-Py. Each protocol provides a set of HTTP JSON requests to control the use of the protocol. With the Adminstrative API, a controller application can initiate instances of protocols (for example, issuing a credential) and can respond to events triggered by protocols started by other agents and protocols that are in flight.
+- Protocol events are triggered as messages are received from other agents. The events are sent using a webhook mechanism to a controller for the ACA-Py agent instance. The controller is expected to handle the event, potentially responding by sending a request to the Administrative API.
+- [Action Menu](https://hackmd.io/s/HkpyhdGtV) is a protocol to enable a simple request/response mechanism between agents. We anticipate using the mechanism to enable (for example) an enterprise agent to send a list of actions to a connected agent used by a person. From the menu, the person can select an action (possibly with a text parameter), triggering the enterprise agent to take some action. Think of it like an Interactive Voice Response (IVR) system used in automated call handling system. Just not as annoying.
+  - An Aries RFC for Action Menu will be introduced Real Soon Now.

demo/README.md

@@ -153,17 +153,17 @@ You don't need to do anything with Alice's agent - her agent is implemented to a
 
 ## Learning about the Alice/Faber code
 
-These Alice and Faber scripts implement the controller and run the agent as a sub-process (see the documentation for `aca-py`). The controller publishes a REST service to receive web hook callbacks from their agent.
+These Alice and Faber scripts (in the `demo/runners` folder) implement the controller and run the agent as a sub-process (see the documentation for `aca-py`). The controller publishes a REST service to receive web hook callbacks from their agent.
 
-The controllers for this demo can be found in the [alice.py](alice.py) and [faber.py](faber.py) files. You can watch [this video](https://zoom.us/recording/share/hfGCVMRsYWQcObOUjTQBd1vRxSH3sldO4QbEjWYjiS6wIumekTziMw) to get a start in understanding what is going on (and where) in the controllers.
+The controllers for this demo can be found in the [alice.py](runners/alice.py) and [faber.py](runners/faber.py) files. You can watch [this video](https://zoom.us/recording/share/hfGCVMRsYWQcObOUjTQBd1vRxSH3sldO4QbEjWYjiS6wIumekTziMw) to get a start in understanding what is going on (and where) in the controllers.
 
 ## OpenAPI (Swagger) Demo
 
 Developing an ACA-Py controller is much like developing a web app that uses a REST API. As you develop, you will want an easy way to test out the behaviour of the API. That's where the industry-standard OpenAPI (aka Swagger) UI comes in. ACA-Py (optionally) exposes an OpenAPI UI in ACA-Py that you can use to learn the ins and outs of the API. This [Aries OpenAPI demo](AriesOpenAPIDemo.md) shows how you can use the OpenAPI UI with an ACA-Py agent by walking through the connectiing, issuing a credential, and presenting a proof sequence.
 
 ## Performance Demo
 
-Another demo in this folder is [performance.py](performance.py), that is used to test out the performance of a couple of interacting agents. The script starts up two agents, initializes them and then runs through an interaction some number of times. In this demo, the test is issuing a credential and it is repeated 100 times.
+Another demo in the `demo/runners` folder is [performance.py](runners/performance.py), that is used to test out the performance of a couple of interacting agents. The script starts up two agents, initializes them and then runs through an interaction some number of times. In this demo, the test is issuing a credential and it is repeated 100 times.
 
 To run the demo, make sure that you shut down both the Alice and Faber agents. Follow the steps to start the Alice/Faber demo running either in your browser or in docker, but:
 
@@ -172,6 +172,10 @@ To run the demo, make sure that you shut down both the Alice and Faber agents. F
 
 The script will start up both Alice and Faber agents, run the performance test, and spit out the performance results for you to review. Note that this is just an example of performance metrics tracking that can be done with ACA-Py.
 
+A parameter to the performance.py script runs the demo with Alice having a routing agent for herself, and all messages passing through the routing agent between Alice and Faber.
+
+> To Do: Add command line option to run the three agent version of the script.
+
 ## Coding Challenge: Adding ACME
 
 Now that you have a solid foundation in using ACA-Py, time for a coding challenge. In this challenge, we extend the Alice-Faber command line demo by adding in ACME Corp, a place where Alice wants to work. The demo adds:
@@ -180,9 +184,9 @@ Now that you have a solid foundation in using ACA-Py, time for a coding challeng
 * ACME requesting a proof of her College degree
 * ACME issuing Alice a credential after she is hired.
 
-The framework for the code is in the [acme.py](acme.py) file, but the code is incomplete. Using the knowledge you gained from running demo and viewing the alice.py and faber.py code, fill in the blanks for the code.  When you are ready to test your work:
+The framework for the code is in the [acme.py](runners/acme.py) file, but the code is incomplete. Using the knowledge you gained from running demo and viewing the alice.py and faber.py code, fill in the blanks for the code.  When you are ready to test your work:
 
 * Use the instructions above to start the Alice/Faber demo (above).
 * Start another terminal session and run the same commands as for "Alice", but replace "alice" with "acme".
 
-We'll post a way to get to a completed challenge here soon, and you can see how you did.
+All done? Checkout how we added the missing code segments [here](AcmeDemoWorkshop.md).