Message Routing and Storage¶
Summary¶
This proposal reuses, modifies, and adapts several proposals from the Hyperledger Aries/Indy, and the DIF communities to in order to enable:
- Advanced use cases for credentials exchange, such as when the Issuer requires the User’s prior consent for issuance
- Guaranteed message delivery - even if the Agent is temporarily unavailable
- User-specified routing of messages from mediators to their Agents
- Unified message routing protocols and APIs
- Safe storage of encrypted identities separated from the encryption keys
- Simpler model for synchronization of wallets
- Simplex and duplex messaging paradigms
Specifically, this proposal builds on the foundation laid down by these proposals:
- DIF Identity Hub
- Aries RFC 0046: Mediators and Relays
- Aries RFC 0019: Encryption Envelope
- Aries RFC 0094: Cross Domain Messaging
- Aries RFC 0050: Wallets
Here is a generic, simplified view:
1 - Hub Storage¶
Corresponds to the DIF Identity Hub’s Collections interface and Replication Protocol.
The Permissions API is disregarded because objects stored here are accessible solely by the Agent.
This storage service is plugged into the Agent’s wallet as an implementation of the Storage Interface as shown here.
2 - Mediator¶
The mediator filters messages (authorization) and routes them to the Agent of the Identity Owner’s choosing based on user-specified rules stored in a user-specified Hub Storage location.
Mediators buffer undelivered messages sent to the Agents until confirmation of delivery.
Mediators can be extended in many different ways to support many interesting use cases. For example, an Issuer’s Agent can request collaboration from other mediators (with prior consent from their respective Agents) in order to fulfill a request.
3 - Relay Network¶
Messages between sovereign domains are transported via a network of relays.
Mediators may communicate through one or several relay networks as per their requirements.
For example, a mediator might leverage the public TOR relay network to protect the Agent’s privacy, or it might simply use the internet.
Trusted Contexts¶
The basic exchange implied in the diagram above solves many real-world use cases, but needs to be extended to support scenarios where the Issuer remains the Holder of the User Data - while keeping the User in the locus of control.
The User may introduce themselves directly to the other parties by sharing Peer DIDs, or they may discover these other peers through an app that displays the public, well-known, blockchain-anchored DIDs of recognized institutions.
Mobile agent displaying parties with well-known DIDs anchored to a blockchain, all of which possess Verifiable Credentials from a trusted Issuer (trusted issuer not shown).
Once introduced to these parties (individually), the User proceeds to create a Trusted Context between all parties by asking them each for a new DID identifier for use in this context, along with any Verifiable Credentials required for membership.
Setup of the Trusted Context ends with the User providing the other parties a consent receipt.
Relays based on Trusted Context¶
The previous diagram shows the logical construction of a trusted context. For greater clarity, there are Mediators and Relay Networks between the participants that route based on the trusted context. In particular, the User Data traverses the mediators and relay network:
Putting it all together¶
Trust contexts are realized by:
- Using DIDs as identifiers within the context
- Using Verifiable Credentials for user data representation * Including the user’s consent receipt, which will follow well known standard schemas
- A credential schema negotiated among the parties
- A relay network negotiated among the parties
- Mediators ensuring message delivery to the Agents
Another scenario has the Issuer mediator delegating to the User mediator, in a manner similar to UMA: