Hyperledger Aries provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. It is infrastructure for blockchain-rooted, peer-to-peer interactions. This project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality. (1)
Hyperledger Aries is related to both Hyperledger Indy, which provides a resolver implementation, and Hyperledger Ursa, which it uses for cryptographic functionality. Aries will consume the cryptographic support provided by Ursa to provide both secure secret management and hardware security modules support. (2)
- A blockchain interface layer (known as a resolver) for creating and signing blockchain transactions.
- A resolver can be seen as part of a larger component known as the VDR:
Aries Verifiable Data Registry Interface: An interface for verifying data against an underlying ledger.
- A cryptographic wallet that can be used for secure storage of cryptographic secrets and other information (the secure storage tech, not a UI) used to build blockchain clients.
- An encrypted messaging system for allowing off-ledger interaction between those clients using multiple transport protocols.
- An implementation of ZKP-capable W3C verifiable credentials using the ZKP primitives found in Ursa.
- An implementation of the Decentralized Key Management System (DKMS) specification currently being incubated in Hyperledger Indy.
- A mechanism to build higher-level protocols and API-like use cases based on the secure messaging functionality described earlier. (3)
The following controllers are supported by Aries-Framework-Go.
This protocol, at the core of Aries, allows agents to establish relationships with each other for the purpose of sharing DIDs and DID documents. (4)
This protocol describes how an intermediary can introduce two parties that it already knows, but that do not know each other. (5)
This protocol enables an issuer to provide a holder with a verifiable credential. This process can be initiated by the issuer or holder. (6)
This controller provides access to the key management service of an agent.
This controller allows an agent to (un)register itself with a mediator, view connection details and statuses.
The project can be used as a DIDComm Router/Mediator.
This controller allows agents to (un)register message services with a message handler, send messages, reply to them and view all registered services.
The controller for this protocol can be used when an agent desires to connect with another but does not have a DIDComm connection. (7)
This protocol enables a verifier to request a presentation of a proof from a holder/prover.
It focuses on the exchange of verifiable presentations and does not concern itself with the structure of the documents which are being exchanged. (8)
This controller provides functionalities for the creation, retrieval and resolution of DID documents from a VDR (Verifiable Data Registry).
This controller allows for the creation, retrieval, validation and signing of verifiable presentations and verifiable credentials.