Trusted P2P Messaging with DIDs, DIDComm and VCs
A Decentralized Identifier (DID) is a stable identifier in form of an URI that introduces a level of indirection for key management and managing other useful information such as service endpoints. It means, you can rotate and add properties related to your DID and validators can find out about those changes. Trust is usually rooted in a Blockchain but some DID methods exist that don’t require any on-chain transactions. Consequently, when we speak about a DID, then we need to be more precise and also speak about the particular DID method of that DID which defines the CRUD operations on a target system such as Ethereum. Depending on the privacy, security, scalability and other guarantees, developers can choose from a variety of different DID methods.
By resolving a DID a validator can typically discover the authoritative keys for different purposes or more generally, a set of verification methods for that DID. An Ethereum account could be a verification method as well. Service endpoints are extensible by design, so you could define your own ones if needed. However, the DID community has agreed on a set of well known service endpoints. Amongst them, the DIDComm service endpoint solves the how-to-reach-me problem and can be used to establish a secure communication channel with the other party. Despite there are only a few limitations of what properties can be associated with a DID, privacy regulations such as GDPR need to be considered very carefully.
If I had a Phone Book with DIDs …
So, what happens if you had a corporate registry (or phone book) where all companies had their own DIDs and please note, the phone book should not expand on individuals for privacy reasons. You would be able to start to interact with them or more specifically with their agents by just knowing their DIDs. An agent is a piece of software that runs on behalf of their controller and manages DIDs, their associated private keys, relationships with other agents and other credentials. The DID Agent Framework (DAF) was developed by the identity team at ConsenSys AG (former uPort) and provides an agent framework for different architectures (frontend, backend, mobile, hybrid deployments using method delegation such as to support remote KMS/HSM). These agent-to-agent interactions will be secured using state-of-the-art cryptography regardless of the chosen transport channel. This approach is called DIDComm Messaging which originated in the Hyperledger foundation and is now being specified as V2 by the Decentralized Identity Foundation (DIF) as a pre-standard. DIDComm Messaging provides a secure communication channel between two agents. After a channel has been established, well defined message-based sub-protocols can be used to make more sense of the interaction, e.g., to increase the trustworthiness of the other party.
How to trust the Phone Book entries?
The Hyperledger Aries project has defined a couple of DIDComm Messaging sub-protocols as Hyperledger Aries RFCs to build a decentralized reputation network based on the global W3C Verifiable Credentials (VC) standard and specifications developed in DIF such as DIF Credential Manifest and DIF Presentation Exchange. Reputation is established by issuing, collecting, revoking, verifying the provenance of attestations and proving control over attestations which use the W3C VC data model. Be it the company’s home address, group membership, relationships with other company departments or with the umbrella company, subscriptions, contracts with other parties, invoices — literally, there is no limitation in what can be attested. Agents can be integrated with existing systems and work flows to enforce policies (e.g. based on attestations), obtain consent and acquire additional input data at certain steps in these sub-protocols.
If none of the existing sub-protocols in HL Aries fit, one could define a new sub-protocol. If the problem to solve is general enough, e.g. because it is used by a larger community such as by Baseline, it will be possible to register these sub-protocols in the didcomm.org registry for more visibility. It is certainly possible to use DIDs and VCs without DIDComm Messaging and add a domain-specific service endpoint to the DID that offers the service.
Other approaches exist that allow bi-directional binding DNS names to DIDs. For example, this can be accomplished by signalling support for the DIF DID Configuration specification in the service endpoint section of the DID. The endpoint would point to a JSON file hosted under a well-known URL of that domain that contains cryptographic binding between the DID and the domain protected by existing TLS certificates (i.e. Internet PKI). This ensures that a specific DID belongs to a web origin, e.g. example.com, in a fully GDPR-compliant manner.
did = agent.discoverDid(‘www.acme.com’)
Nevertheless, this approach can be combined with the aforementioned HL Aries approach to build trust beyond DNS because we all know that the trust layer of the Internet is broken. However, leveraging the existing Internet PKI could be a good starting point to discover DIDs for certain domains until more natural trust anchors such as the European Commission (ESSIF) or GLEIF start to build a trust framework rooted in DIDs and VCs.
Is this Self-Sovereign Identity (SSI)?
You might have noticed that we have not mentioned the term Self-Sovereign Identity (SSI) so far. This is because DIDs, VCs and DIDComm Messaging don’t necessarily require an end-user wallet to have useful applications which are typically associated with SSI. However, people could use the same approach to provide end-user apps (mobile, PWA, browser extensions, web services) that operate as their own agents to manage their SSI wallets.
Relationship with ENS
DIDs and VCs are great for off-chain use cases but they are not great on-chain. This is where Ethereum Name Service (ENS) still can make sense. ENS is a distributed, open, and extensible naming system based on the Ethereum blockchain. On the other hand, if all you need is off-chain verification of an Ethereum account and that the account belongs to a company, then you don’t need ENS. Also note that ENS has a few design flaws which can be mitigated when an agent-based system architecture is used:
- DNSSEC oracle is not always up-to-date (specifically when the domain owner changed) which represents a security vulnerability.
- Stored ENS records are hashes but they are not salted (for practical reasons), so it is questionable if this complies with GDPR.
- Most ENS records are not verified, e.g., everyone could claim anything.
- No L2 solution exists for updates (not yet) and therefore higher transaction costs can be expected.
- No version history of ENS records is kept (without examining the ledger state history itself), e.g., it is not easy to find an older version of a public key which could be useful in order to (re-)verify historical data.
If a system already uses ENS, then it could make sense to use ENS, DIDs, VCs and DIDComm Messaging together by adding a DID TXT record to an ENS entry. So, developers could use the ENS name as a lookup key to find other DIDs. Then, they could find out more about the reputation of that ENS name, or execute other off-chain protocols with their agent. A dedicated DID registrar contract for ENS might not be required because the linkage between the ENS name and the DID could be verified off-chain by other means (e.g., VCs).
The DIDComm-agent Way …
The technologies described in this article can be used with SSI but are not strictly limited to end-user focused use cases. Further, DIDs are not necessarily competing with ENS and in certain cases can be a complementary solution.
Agents (through their DIDs) should be the starting point of every interaction between all types of entities across organizational borders. To make most sense out of an agent-based system architecture usually the following steps are required:
- Make DIDs discoverable.
- Your agent discovers their DID.
- Establish a DIDComm Messaging connection with their agent using their DID.
- Execute higher-level sub-protocols through the DIDComm Messaging connection between your and their agent.
By implementing this approach you will get a modular extendable way of implementing key (and other properties such as Ethereum accounts) rotation, service discovery, securely connecting systems with zero trust and enriching your business workflows with decentralized reputation.
