DIDComm & DIDComm Messaging
Von: Tim Gorgs
As announced in our previous blog post ,today’s post is about DIDComm & DIDComm Messaging.
Relation to DATEV & SAP
Based on the research project we conducted with SAP, we developed a Proof of Concept (PoC for order-to-cash-business processes. As part of this PoC, we integrated DIDComm based communication to seamlessly transfer data within the boundaries of the process. The overall steps are:
1. Hans Schreiner (owner of a small business) logs into a webshop with SSI
2. He places an order
3. The webshop sends an order confirmation to him and also to the tax consultancy
4. The webshop hands the ordered products over to the logistics company
5. Hans Schreiner confirms the order delivery via his DATEV Wallet app
6. An invoice is automatically transferred to him and his tax accountant, who works with DATEV software
During this process, relevant steps are notarized on a distributed ledger and information is sent between the participants via DIDComm messaging, including
- ordered items
- master data, such as delivery and payment addresses
- order confirmation
- delivery confirmation
- invoice
For the time being, even the documents involved in the process are transferred via DIDComm (base64-encoded), so they use the built-in security and verifiability. For larger amounts of data, a linked data approach is advisable, but at the moment outside the scope of our PoC.
The remainder of this blog post describes in more detail the origins, motivation and properties of DIDComm and DIDComm Messaging.
Origins
To understand where DIDComm originates from, a short excerpt about the underlying projects:
Hyperledger
The Hyperledger Project was founded in 2015 by the Linux Foundation. It focuses on a platform to collaboratively develop open standards and tools for various use cases based on distributed ledger technologies (Hyperledger announcements).
Two Hyperledger projects of interest in regards to the use case described in our previous blog post and the mechanisms required to provide secure messaging are Indy and Aries.
Hyperledger Indy
- Used to provide digital, decentralized identities based on blockchain/distributed ledger technology
- Issue, store and verify credentials that are transferable, private and secure
- Trying to address issues such as
- Identity theft
- Lack of privacy
- Centralization of user data
Quoted from Hyperledger.org
Hyperledger Aries
- Provide the infrastructure for blockchain-rooted, peer-to-peer interactions
- Verifiable information exchange
- Secure messaging for different decentralized systems
Quoted from Hyperledger.org
DIDComm
As part of the projects mentioned above, DIDComm comes into play as an open and crosscommunity standard to provide a secure communication channel between involved parties. It is based on decentralized identifiers and cryptographically guarantees the authenticity of any party represented by their prospective DID. For further information check the Understanding DIDComm blog post on medium.com.
At the end of 2019, the Decentralized Identity Foundation (DIF decided to pick up the existing work around DID-based communication and address the requirements of a broader and more heterogeneous community.
DIDComm allows and even encourages other protocols to be built on top of it, so there are many different use cases that can be implemented. One common denominator is that there’s no need for a central server for the exchange of messages, thus removing the imbalance of established client-server scenarios that tend to favor institutions and organizations over clients and users.
Protocols
In general, protocols can be seen as a description or recipe for interactions that follow a certain pattern, such as ordering a book from an online web shop or paying at the supermarket checkout.
Properties of protocols comprise composability, meaning that more complex protocols can be built on top of simpler ones, often moving up in terms of abstraction while hiding technical details from those who use such high level protocols. Protocols can also be nested, i.e. run within each other to perform sub-tasks.
In relation to DIDComm, protocols don’t have an overseer or central instance, but instead rely on mutual consent and shared understanding of how a protocol is meant to be used and all participants (can) act as peers.
Often, existing standards are also incorporated into protocols, e.g. JSE (JSON Web Encryption), JWS (JSON Web Signature) or Media Types.
DIDComm Messaging
According to the DIDComm Messaging project on GitHub, “DIDComm Messaging is the first specification in a family of related specs; … DIDComm is the common adjective for all of them, that all will share DID mechanisms as the basis of security.”
The specification also states that “The casual phrase DIDComm Messaging is ambiguous, but usually refers to DIDComm Messaging encrypted messages…”, so as of now, there isn’t a 100% clear cut definition of what is meant by the term.
Either way, DIDComm messages are a powerful approach to enable two or more parties to communicate with each other in a secure fashion, and this is a key piece for an interoperable decentralized identity stack. It aims to enable anybody (or anything) to use it to exchange machine-readable messages, whether it is between people, instititutions and organisations or things (computers, machines, IoT devices etc.).
DIDComm Messaging Design
Following the specification (https://identity.foundation/didcomm-messaging/spec/#specificrequirements), DIDComm messages should be designed in way that they are:
Secure
Messages should be secure in a way that they use state-of-the-art cryptography (“best of class”). Signing and optionally also encrypting messages means that they are cryptographically verifiable, making them tamper proof.
Private
Privacy is an important aspect not only in terms of the messages themselves but also in terms of the participants. Nobody should be able to know or deduce, who communicates with whom and about what.
Decentralized
Without a central server or instance, participants are seen as equal and base their trust based on the control of DIDs
Transport Agnostic
How messages get from the sender to the recipient(s) shouldn’t matter in terms of DIDComm — whether it is via a simplex or duplex communication pattern, online or even offline, all of this should be possible.
Routable
If no direct route is available between any two participants or the recipient’s devices aren’t available at the time of sending (e.g. because they are offline), DIDComm allows for messages to be routed between them in a secure and tamper-proof way.
Interoperable
Interoperability has several important aspects, for instance when different vendors of decentralized identities or participants in different distributed ledger networks want to communicate with each other.
It also means that different programming languages can be used, as well as different platforms, operating systems, hardware etc. In short, it aims to be a future-proof lingua franca of all selfsovereign interactions.
Extensible
Extensibility means that based on asynchronous, simplex messaging as the common denominator, many other protocols and interaction patterns can be built on top of DIDComm.
Examples include general guidelines for protocols as well as some specific examples, such as the
- Basic message protocol — A stateless and simple protocol with a single message type for sending messages between sender and receiver
- Issue credential protocol — A protocol for issuing verifiable credentials from an issuer to a prospective holder, including proposals, offers and requests
- Present proof features protocol — A protocol to ask for or provide proofs (verifiable claims) for a verifier, based on verifiable credentials
Efficient
No bandwidth, battery, storage space or processing power should be unnecessarily consumed.
DIDComm Message Anatomy
The anatomy of DIDComm messages has two main layers, one of them being the envelope and the other one the content (plus an optional JWS envelope) as depicted below:
Envelope
On the envelope level, two alternatives can be differentiated, depending on the intended audience and use case:
Signed Unencrypted
When the authenticity of a message must be proven but the audience is not known to the sender, then a message can be wrapped in an unencrypted but signed envelope. Recipients can then verify based on cryptography whether the message is authentic.
Encrypted
When the audience is known to the sender, then the message can be wrapped in an encrypted envelope, in turn using one of three options to perform this step:
1. Anonymous encrypted format — No information about the sender is included
2. Authenticated encrypted format — Used when a message is encrypted for the recipient and the sender information is included through the use of authenticated encryption. Only the true recipient(s) can decrypt the message and authenticate that its content is truly from the sender
3. Signed encrypted format — Used when a message is encrypted for the recipient and the sender information is included with a non-repudiable signature. Only the recipient(s) can decrypt the message. Because of the non-repudiability, authentication of the message content can be done by any party who knows the sender
Content
On the content level, certain conventions regarding the message structure apply, such as the
- Message Type — Identification of the message as well as the protocol (see below)
- Message Id — An ID generated by the sender, allowing unique identification of a message
- Decorators — *Re-usable conventions that are present across multiple messages in order to handle the same functionality in a consistent manner
For reference, see the DIDComm Message Anatomy RFC.
Message Types
Even though the term DIDComm Messaging usually refers to encrypted messages, there are three formats that a message can have.
- Plaintext — The plaintext contents are processed when higher protocol levels remove the protective envelopes. It is also a useful message type for debugging purposes
2. Signed — A signed JWM (JSON Web Message) envelope that associates a non-repudiable signature with the plaintext message inside. This message type is expected to be used in a few cases and only when the origin of the plaintext content has to be provable to third parties or when the sender can’t be proven to the recipient by authenticated encryption because the recipient is not known in advance.
3. Encrypted — An encrypted JWM (JSON Web Message) that hides all contents from all but the authorized recipients. Furthermore, the sender itself is only disclosed to exactly and only the authorized recipients, too. This format provides integrity guarantees and is the safest format for storing DIDComm messaging data. An encryption envelope is used for each hop on the journey between sender and recipient.
For reference, see the Encryption Envelope RFC.
Is It Ready To Be Used?
TL;DR
Yes.
A More Elaborate Answer
Even though there is still ongoing development regarding DIDComm, its version 1 became available for production in 2018 and has since been tested and used in various scenarios.
Version 2 is now ready to be used while, at the same time, there are still plans for future developments, obstacles to be conquered and issues to be discussed.
One example, of which the designers are aware of, is the issue of Post Quantum Cryptography, about which a section was included in the specification in November 2020.
Furthermore, some of the protocols and ideas based on DIDComm are not finished and others are still to come. So if you think there are flaws, bugs or any other issues, you’re welcome to contribute and share your knowledge and insights with the community.
Links
DIDComm and the Self Sovereign Internet Blog Post by
DIDComm Mythconceptions by Daniel Hardman
Medium.com: Understandung DIDComm
Outlook
In our next blog post we will shed some light on Verifiable Presentations and explain how data from different verifiable credentials can be composed accordingly.
