HIP Identifier: Hyperledger Aries
(Introduced to some as a “Hyperledger shared wallet project,” but that moniker is an incomplete description, read on to find out more.)
Accepted and now tracking setup at Aries New Project Checklist
Nathan George, Sovrin Foundation, nathan@sovrin.org
Stephen Curran, cloudcompass.ca, swcurran@cloudcompass.ca
Daniel Hardman, Evernym, daniel.hardman@evernym.com
Vipin Bharathan, dlt.nyc, vip@dlt.nyc
Jegan Selvaraj, sj@troondx.com, adi@troondx.com
John Jordan, Province of BC, john.jordan@gov.bc.ca
Tobias Looker, Mattr, tobias.looker@mattr.global
Robert Mitwicki, Lab10 Collective, robert.mitwicki@lab10.coop
Steve McCown, Anonyome Labs, smccown@anonyome.com
Troy Ronda, SecureKey Technologies, troy.ronda@securekey.com
Markus Sabadello, Danube Tech, markus@danubetech.com
<Please contact @nage on https://chat.hyperledger.org to be added as a sponsor>
Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet (the secure storage tech, not a UI) for blockchain clients as well as a communications protocol for allowing off-ledger interaction between those clients. This project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality.
Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes:
Hyperledger Aries consumes the cryptographic support provided by Hyperledger Ursa to provide both secure secret management and hardware security modules support.
Hyperledger Aries is a client tool suite and framework code for trusted peer interactions and information exchange, as such it is an excellent toolkit for secrets management and can serve as a blockchain client for many systems. It is related to Hyperledger Indy, which provides a resolver implementation, and Hyperledger Ursa, which it uses for cryptographic functionality.
The project also makes extensive use of the Verifiable Credentials and Decentralized Identifier standards being incubated at the W3C.
The project has grown out of the Indy community, but after the technology from Indy has migrated will not be dependent upon Indy.
Indy has been incubating protocol work for peer interactions between identity owners for some time. As this development community has grown it has become clear that the scope of that work extends beyond the functionality provided by Indy. Aries aims to make the peer interaction code needed for secrets management, verifiable information exchange, and secure messaging accessible across different decentralized systems. This will allow us to foster practical interoperability in support of ongoing standards work and extend the applicability of technologies developed within Indy beyond its current community.
This project will start in incubation.
The Indy community is eager for initial approval to help build support for the project outside of the traditional Hyperledger community. It is expected that the initial code migration may take some time to avoid any disruption to Indy release schedules and active adoption of the protocol being specified.
The following is a list of functionality expected to be in scope. Items in normal text are currently being built/incubated within Indy, items in italic text have been considered as part of the architecture, but are not required until a maintainer commits to build and maintain the functionality.
The initial scope of this project sets out to develop software that enables the facilitation of peer to peer messaging, controlled exchange of data, and the support of interaction with different blockchains and other DLTs.
To enable peer to peer messaging system we will rely on the ongoing work in the Indy HIPE repository to support a transport agnostic messaging layer designed to send messages using end-to-end encryption. The E2E encryption will support the capabilities of both an anonymous messaging system, authenticated messaging system, as well as routing functionality to aid in the exchange of these messages using a methodology that allows metadata correlation to be controlled.
This messaging layer will require a secure storage solution to perform key management as well. We consider it in scope that this project supports the management of keys through the secure wallet which is intended to store keys, credentials, and other secure data. With this comes a standard storage interface, that allows for pluggable backend support. For additional data, we’ll also enable the storage of data.
Additionally, it is the intent of this project to provide a dynamic set of capabilities to store the data that is exchanged. These capabilities will range from the secured, secret storage of data such as private keys, up to the capability of globally accessible data that can be viewed and accessed by anyone. As an example, we’d like for a secure storage solution similar to the wallet available in Hyperledger Indy today that would be capable of storing, verifiable credential data, private keys, relationship state data, and functionality that can perform operations with this data without having to extract this data. For example, encrypting a message should be possible using an authenticated encryption format, which uses a symmetric key generated with an DHKE using a private key stored in the secure wallet and a public key of the recipient which is provided through the API call. There will also a be scalable, searchable storage layer which will be capable of storing other associated data necessary for the maintenance of an identity. Examples of data which may be stored in this layer would be pictures, health records, or other personal data.
Other functionality that would be in scope for a 1.0 project release would be a Decentralized Key Management Solution (DKMS) which would add key recovery, social recovery, and wallet backup and restore functionality. Much of this work would be based on the DKMS documents outlined in the Indy-HIPE dkms design folder.
We also intend for project Aries to support multiple DID methods through a generic resolver interface. This generic interface will initially support the Hyperledger Indy resolver but will be extensible so that if someone wanted to build a pluggable Hyperledger Fabric DID method resolver, Ethereum DID method resolver, or another DID method resolver in they could. These resolvers would support the retrieval of transactions and other immutable data that has a shared state on a ledger. One of the other pieces that will come built into this project will be support for a peer DID method resolver which will rely upon the wallet and p2p messaging protocol to maintain the state of a peer-to-peer relationship. Another interaction that the resolver interface will support is the ability to read data that exists in a verifiable data registry. An example of a VDR is the Indy Catalyst project.
With all of these capabilities, we’ll now be able to build core message families that are necessary to facilitate interactions of an identity. Examples of these core message families would be a verifiable credentials protocol with and without ZKPs, introduction protocol, challenge-response protocol, and others that are deemed necessary by the maintainers of this project over time. An example of another component we would like to see, but do not currently have maintainer support (and therefore consider out of scope for a 1.0 release) for the integration of WebAuthN, OpenID connect, and OAuth 2.0 standards which would allow a developer to integrate verifiable credentials with current standards.
It is also within the scope of this project is the ability to extend the capabilities of the system easily where a business or developer is only required to understand the nature of the interaction which is referred to as “developing an extensible protocol”. This would allow for a developer to extend the use of the core components of Aries, to build higher level abstraction layers on top to facilitate new capabilities. For example, it is within reason for a developer to use the Aries project as a springboard to building a peer to peer ride-sharing protocol.
The above diagram represents the current picture that exists once code and build processes transition out of Indy and into Aries. After this happens, three phases of updates the Indy project are anticipated. In phase one Indy can become the home to additional blockchain resolvers beyond Plenum, provided those chains parallel the extended verifiable credentials data model used for the W3C Verifiable Credentials specification in conjunction with additional elements for cryptographic protocol support. Resolvers that are specialized for other cases are welcome as use cases for the resolver interface in Aries, but are likely better housed inside their respective projects. Phase Two includes the “Indy Ledger Next” initiative, which is an upgrade of their ledger protocol, this means that in the short term Indy may share a BFT ledger component with another project or that Plenum may undergo a significant renovation for a “2.0” release--this phase should not be ignored, as it is important to on-boarding new maintainers and building a common knowledge base for phase three. The third phase can only happen after Aries has achieved 1.0-level stability. Once we have stable extensible message families, it makes sense to add basic consensus framework support to the system (possibly including shared components like Hyperledger Transact) to allow wallet synchronization and decentralized data processing for agents. We anticipate that this tool-kit will be reusable towards constructing BFT ledgers, and can serve as a basis of a new Indy ledger component that builds on top of Aries, instead of Aries depending on Indy.
We propose the creation of the following repositories on GitHub to manage Hyperledger Aries:
As part of this move, we are planning on using git-filter to update history to better account for the DCO process adopted after the Indy project’s inception.
It is important to note that the proposed Hyperledger Aries community has already built a significant contributor base and holds active conversations and regular calls. The indy-agent project space in Jira, and the #indy-agent channel can be rebranded to aries-agent. The new project will require a mailing list and general #aries channel.
As part of efforts to facilitate more open collaboration other communities have invited us to host the Aries project elsewhere. It is the Indy maintainers opinion that continuing the momentum Indy enjoys at Hyperledger makes for an excellent platform for launching the project, and if further collaboration opportunities emerge, we will explore co-branding developer calls as working groups with the other organizations.
Why Aries? The Indy community and the identity working group went through multiple rounds of polls to find a name that seemed memorable, didn’t have obvious name confusion issues and wasn’t disliked in a particular way by those who would serve as maintainers. Consensus was we wanted a short name that fit alongside Indy and Ursa (two components that leveraged extensively in Indy). Aries was the top vote getter in this process. Aries is a constellation in the zodiac, usually represented by a ram. Agent software is about being able to assert yourself as an independent actor and climb to previously inaccessible places in the digital world. The name should be considered provisional pending approval by the marketing committee.
The project success can be measured by ability to use the agent protocol to communicate with code bases. If support of verifiable credentials, DIDs, or other peer to peer communications provided by this code base doesn't materialize outside of Indy it may be appropriate to fold this project back into Hyperledger Indy.