[This post was written by Kaliya Young, and originally posted on Medium.com]
If you are reading this, you probably know already what Decentralized Identifiers (DID) are: they are “identifiers” or addresses which can be queried to return some information about the subject represented. The addresses take the form of a long, opaque “string” (a long block of letters and numbers, in this case of a fixed length), and the DID “documents” that get returned when they are queried contain some cryptographic key material and, depending on the particularities of the returning system, maybe a few other pieces of information or addresses.
Identity systems have traditionally been largely hierarchical, focusing on asymmetrical or vertical relationships. The most open system that allows horizontal communications between users in different systems is email, and even there, user-to-user communications are mediated by servers, which banlist each other based on a federated reputation system. DIDCommunications (DIDComm), on the other hand, is a set of tools to allow horizontal (or at least, power-neutral) and bidirectional channels of communication between two entities that know each other’s DIDs and nothing else. It resembles today’s end-to-end encryption systems like Signal, Telegram, and Whatsapp more than it resembles traditional email.
How DIDComm works
DIDComm is a cross-community standard that creates libraries and design patterns for two or more DID-controlling entities from diverse DID-based systems to communicate directly with one another. It creates a secure communication channel between software controlled by each of these entities, which can be people, organizations or things. This constitutes an “authenticated channel,” in that control of a given DID’s private keys is, barring a failure of design or operational security, proof of authenticity of the party represented by that DID.
This architecture is powerful because it provides a way to do mutual authentication between any two parties. Right now many systems of messaging and communication on the open web don’t provide for mutual authentication with cryptography; they ask individuals to authenticate to sites or businesses (nowadays mostly with single-sign on integrations, i.e. “log in with your XXX account” buttons), and these businesses vouch for and secure the end-user. In exchange, businesses get valuable insight into the communications or commercial activity they facilitate — insights they often sell to third parties.
Furthermore, while the onus is on individuals to authenticate themselves to these enabling institutions and middlemen, the business themselves do little to authenticate themselves reciprocally. Over time, the “lock icon” next to URLs in modern browsers has come to be a useful norm (and users have been habituated to reacting suspiciously to any website which cannot provide on). However, phishing attacks, where intercepted or falsified communications lead users to malicious websites impersonating ones they trust, continue to be a major attack vector for fraud and identity theft. By supporting mutual authentication, a more uniform and democratic protocol is established for secure communications, which raises the bar for user expectations for security assurances from institutions and websites.
A Quick History of DIDComm & Aries Protocols
DIDComm was first developed within an international and collaborative open source co-development project called Aries (hosted at Hyperledger) and under a IPR regime designed to cover software but not specifications. Aries was spun out of the earlier Hyperledger Indy project, to both iterate, expand, and make more blockchain-agnostic the codebase and tooling created earlier for the identity blockchain Indy. In the same process, Hyperledger Ursa was also created to advance the underlying cryptographic elements independently of the blockchain and the identity systems relying on it. The Indy project continues evolving as well, from a single blockchain to a family of interoperable ones.
The name “DIDComm” and version 1 of its libraries and designs evolved in this context: it adapted the Indy-specific horizontal communications libraries to a more agnostic Aries context and iterated them to be more configurable for new contexts and implementations. At some point, however, it became clear that further interoperability would be best served not by writing specifications based on existing Aries implementations, but by a more “green-field”, specification-first design process with interlocutors from further afield. This work came to be co-sponsored by DIF and Hyperledger partly to engage these outside interlocutors, and partly because the IPR protections of DIF were more appropriate to a specification-first open-standards process. The charter of the DIDComm working group at DIF .
The Future of DIDComm
Since the chartering process began in September of 2019 at the post-IIW DIF Face to Face, the work of designing a new core for DIDComm and thinking through new features and structure has proceeded at a steady clip. The implementations and details are still being hammered out in some places, but the feature set is stable. The benefits of the new protocol will include:
- Mutual authentication
- Robust, email-like threading support for relying messaging systems (including error-handling and other machine-readable messaging systems)
- Support for new security and transport primitives like the JWM envelope
- Asynchronous by default, but with synchronous communication modes also supported
- Offline support so that two agents who are not online can exchange information via bluetooth or QR Code
- Easy to support with a web server (among many other topographies)
- Many of the positive qualities of the earlier SOAP protocol, include message format standards, routing, transport agnostic support, and subprotocols.
This effort has the direct support and participation of many core members of the Aries community. It is within the plans of the Aries community to migrate to DIDComm V2 as it becomes ready for use and tested. In both existing DIDComms (many of which are already in production), protocols relying on a DIDComm-encrypted channel for authentication or communications functions will be moved over. The relationship between DIDComm and these relying “subprotocols” is quite similar to the relationship between HTTP and the APIs created on top of HTTP — an upgrade to the underlying security or feature set will not affect the relying applications that just need a secure channel.
There is some consternation about the use of the term “DIDComm Protocols” to describe the various different types of exchange or transactions that could be built on a DIDComm foundation. Regardless of whether one chooses to call them “protocols” or something else, a cross-community standard will be crucial to co-developing broadly interoperable capabilities and common libraries on the basis of secure, authenticated DIDComm channels. Some examples of what these would include:
- Secure user messaging or even chat-like instant messaging
- Issuing a credential
- Presenting a credential or an identity proof
- Interactions with IOT systems or even directly with specific, authenticated devices
- Payment coordination
Getting involved
A good place to jump in would be this video recorded by DIDComm WG Chair Sam Curren at the June DIF Face-to-face meeting:
With this background, a read through the charter, the mailing list archives, the github repository, or the Slack channel of the DIDComm working group at DIF will make a lot more sense; as will DIDComm sessions at the new IIW and F2F meetings.
