...
(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
Sponsor(s)
Nathan George, Sovrin Foundation, nathan@sovrin.org
...
John Jordan, Province of BC, john.jordan@gov.bc.ca
Tobias Looker, Spark NZMattr, tobias.looker@spark.co.nzlooker@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>
Abstract
Hypeledger 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.
...
Context
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 following is a list of functionality expected to be in scope. Items in normal black text are currently being built/incubated within Indy, items inred italic text have been considered as part of the architecture, but are not required until a maintainer commits to build and maintain the functionality.
- Feature list (see the thing that is in the abstract now and talk about it more like requirements)
- Resolver Layer
- TXN resolver
- Verifiable Data Registry Resolver
- Value Transfer Resolver
- Resolver Layer
- Smart Contract-like resolving (we see this as group issuance to a shared context?)
- Wallet Layer
- Secrets management with Ursa
- Encryption
- Signing
- Attestation
- Secrets management with Ursa
- Advanced–Crypto compute in TEE
- Key Storage
- Backup/Restore
- Credential Data storage
- Searchable Storage Interface
- Storage backend implementations
- sqlite backend
- postgresql backend
- Others as contributed:
- Kademlia backend
- Decentralized Storage (like IPFS, Swarm, etc.)
- Storage backend implementations
- Messaging Layer
- Anoncrypt, Authcrypt and routing needed for supporting multiple transport layers.
- Introduction protocol (To accomplish key exchange for bootstrap message encryption)
- Message Families
- Enumeration of capabilities
- Collections of messages that create protocols or a common set of functionality
- Message Families included in the core
- Issuer, Verifier, Holder
- Anoncreds (ZKP protocol for W3C Verifiable Credentials) Issuer, Verifier, Holder
- JWT Verifiable Credentials
- DKMS
- Introduction protocol
- Key recovery
- Social recovery
- Wallet backup and restore
- Web Authentication compatibility (proxy credentials into legacy protocols)
- WebAuthN
- OIDC
- OAuth
- Language Idiomatic Library wrappers
- Additional platform-specific functionality
- Prototypes of functionality prior to
agreement - agreeent on inclusion in the core
- Languages Supported
- Python
- Rust
- Java
- Go
- Ruby
- PHP
- Objective C
- Others
- Welcome
- Agent Frameworks
- Python reference framework - simple to understand as an example for other frameworks
- High performance Rust framework
- Others welcome
- Reference Agents
- Indy Catalyst Agent (Python)
- Python Reference Framework - simple to understand as an example to other agents
- Python Test Suite - implementation of an agent used for proving wire-level protocol interoperability between other implementations
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.
...
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 resolving 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 resolve read data that exists in a verifiable data registry. An example of a VDR is the Indy Catalyst project.
...
We propose the creation of the following repositories on GitHub to manage Hyperledger Aries:
- https://github.com/hyperledger/aries (migrate some, but not all code from indy-SDK, remaining indy-SDK would become the indy-resolver loaded by an Aries agent)
- https://github.com/hyperledger/aries-rfcs (migrate related indy-hipe docs).
- https://github.com/hyperledger/aries-agent (migrate from indy-agent)
...
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.
Reviewed By
- Arnaud Le Hors
- Baohua Yang
- Binh Nguyen
- Christopher Ferris
- Dan Middleton
- Hart Montgomery
- Kelly Olson
- Mark Wagner
- Mic Bowman
- Nathan George
- Silas Davis