# Aries RFCs for the OpenMined Identity and Security Roadmad This aims to be a collection of resources, mainly aries rfcs, that will help provide a technical understanding of the OpenMined identity and security roadmap. Hyperledger Aries is an open source project, that forms part of a technology stack for implementing what is often termed Self-Sovereign Identity. The Trust over IP stack rfc is a great place to start - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0289-toip-stack](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0289-toip-stack). ## Establishing a DID Comm communication channel **DIDComm** is a protocol for sending communication between **agents** across a channel established first by exchanging decentralised identifiers (DIDs) through a **DIDexchange** protocol. These identifiers are called **peer DIDs**, due to the fact that they are created and managed within the context of the peer-to-peer relationship. No one else needs to be involved. DID based communication is designed to be transport agnostic - while currently most implementations use http - the idea is that you can communicate using DIDs across any transport protocol. DIDComm involved - Agents - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents) - Protocols - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols) - DID Exchange - [https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange](https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange) - DIDComm - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm) - Peer DIDs - [https://openssi.github.io/peer-did-method-spec/index.html](https://openssi.github.io/peer-did-method-spec/index.html) - DIDComm transports - [https://github.com/hyperledger/aries-rfcs/tree/master/features/0025-didcomm-transports](https://github.com/hyperledger/aries-rfcs/tree/master/features/0025-didcomm-transports) ## DID Comm Messages Messages are sent across DIDComm channels wrapped inside an Encryption Envelope, these messages can be of a specific message type which defines the structure of the message. For example the Basic Message type defines a stateless user message. In the future it will be possible to verify certain trust aspects about these messages using an object called a Message Trust Context. Mediators and Relays are defined with the agent to agent communication system to enable complex topologies and flows that can further preserve end user privacy. From the rfc - "By modeling the roles of mediators and relays in routing, we can support routes that use multiple transports, routes that are not fully known (or knowable) to the sender, routes that pass through mix networks, and other advanced and powerful concepts." Through each hop between Mediators a new encryption envelope is wrapped around the agent message, this forms the basis of what is called Cross Domain messaging. We want the sender to know just enough about the message recipient's identity domain to send the message and no more. **Mediators and relays and Cross Domain Messaging seem to be a core concept in terms of meeting the initial design laid out in roadmap document.** - Message ID and Threading - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0008-message-id-and-threading](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0008-message-id-and-threading) - Encryption Envelope - [https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope](https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope) - Message Types - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0020-message-types](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0020-message-types) - Basic Message - [https://github.com/hyperledger/aries-rfcs/tree/master/features/0095-basic-message](https://github.com/hyperledger/aries-rfcs/tree/master/features/0095-basic-message) - Message Trust Context - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0029-message-trust-contexts](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0029-message-trust-contexts) - Mediators and Relays - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0046-mediators-and-relays](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0046-mediators-and-relays) - Cross Domain Messaging - [https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0094-cross-domain-messaging](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0094-cross-domain-messaging) ## Other Concepts - The idea of the **Introduce** protocol sounds interesting/useful - [https://github.com/hyperledger/aries-rfcs/tree/master/features/0028-introduce](https://github.com/hyperledger/aries-rfcs/tree/master/features/0028-introduce) - Help me discover protocol - https://github.com/hyperledger/aries-rfcs/tree/master/features/0214-help-me-discover The full collection of RFCs can be found here - [https://github.com/hyperledger/aries-rfcs](https://github.com/hyperledger/aries-rfcs)
Last changed by  
 
Will Abramson
629

Read more

The did:btc Method

The format for the did:btc method conforms to the DID CORE spec. It consists of a did:btc prefix, followed by a base58-btc encoded value representing a secp256k1 public key.

3/4/2024
Atala DID Method

Atala Questions We have legacy DIDs that only contain a single MASTER_KEY. Should we translate the master key type to an AUTHENTICATION verification relationship? I am not fully clear what is being asked here. Can these legacy DIDs not be updated to contain more than one key? Also, MASTER_KEY is not a verification relationship in the W3C DID spec so the resolver will need to specify rules against which a key with KeyUsage defined as MASTER_KEY is mapped to a W3C verification relationship (or multiple). If MASTER_KEY the only key defined, then should make that key map to ALL verification relationships. Otherwise DID method unusable for significant portion of use cases. We only allow one verification relationship per key id, do we want to make this more flexible? You could, although one thing to consider is the NIST guidelines recommending a key is only used for a single purpose.

11/16/2022
Identity Systems with Hyperledger Aries

TLDR: if you are going to read one thing then read this about the general Trust over IP stack Hyperledger Aries is an open source project and specification for developing software agents that can communicate across secure cryptographic channels. They can communicate any messages using a protocol called DIDComm, however they are specifically designed to issue and present Verifiable Credentials based on anonymous credential cryptography. The specification is being implemented in numerous coding languages; python, ruby, golang and dotnet to name a few. The idea being that you can develop a aries agent in a language of your choice and be able to interact with any other agent that follows the aries rfcs. There is an interoperability profile which defines which rfcs should be implemented to which version. I have the most experience with the python code base which has largely been developed by the government of british columbia who have been doing great things with this tech. This video gives great deep dive of the architecture of aries agents. An easy way to get started with a fully functioning hyperledger aries agent, controller and user interface can be found in this repo. If you check out the demo-finish branch you can spin up a full ecosystem, with 3 agents alice, faber and acme using docker. The UI's for the agent exists at localhost:4200-4202. If you look at the docker-compose.yml file, it should give you a good idea of the setup. The current UI used can be found in this repo and is written in angular. I have been working to replicate something similar in React, this can be found here. It is not feature complete yet! If you simply swap this repo url with the context for any of alice-web, faber-web or acme-web in the docker-compose.yml of the controller repo you will spin up an agent with the react UI. You can actually pull the project down locally, point to the folder rather than the repo url then edits to the UI will be updated while running the whole system.

3/25/2020
Verifiable Image Attributes using IPFS

This is a quick(ish) explainer and how-to guide for including images inside a Verifiable Credential attribute in such a way that a Verifier can load the image and verify it is the same as the image attested to by the issuer. The problem with an image and probably most files is that their size is greater than a credential attribute was designed to store. Meaning the simple solution to base64 encode the image and include the encoding in a credential attribute will not work. There are two alternative approaches that I have come across previously for implementing this. Perhaps the ideal solution, that will be used in the future involves a Hyperledger Aries concept called a decorator. They provide a way to convey metadata associated with certain communication patterns, I am told it is possible to use decorators to send file attachments over DIDComm. Indeed the RFC shows that aries-cloudagent-python codebase has implemented this. I am yet to explore this for myself, so do not know much more than that. I imagine works by attaching a file to a verifiable credential presentation that includes the hash of that file as one of the attributes. This solution is Self-Sovereign and decentralised. Assuming an issuer has seen the file, created a hash of it and issued it as an attribute of a Verifiable credential. The holder simply needs to prove this file hash attribute along with the file, which they can store wherever they choose, to whoever they wish to prove this verifiable file to. However, the reality today is that this solution is immature and infeasible for most projects despite them still requiring images to be included within credentials in their system. After all, an image is a biometric we as humans are all used to verifying against the holders face. We trust it. We have much less understanding, and hence trust, in the underlying cryptography that allows the verification of attribute integrity and it's authenticated origin. Even if we do place trust in the cryptography, an image is a great way to link a physical human with the digital identifier they are using the represent themselves. The viable solution today is similar to the ideal solution but compromises on decentralisation. Rather than images being passed by the holder along with proof the hash of that image was issued to them, the images are hosted in a central location and holders prove both the URL location and hash of the image within a credential presentation. The verifier can then use the URL to pull down the image, hash it and compare the hash with the hash presented. The problem with this solution, other than the compromise, is the complexity involved when implementing it. There are a lot of decisions to be made about the architecture and associated infrastructure. Let's have a look.

3/20/2020
Read more from Will Abramson
Published on HackMD