Skip to main content

With Identity Rust 0.6.3 and Wasm 0.6.1 a breaking change was introduced that requires a migration of existing Stronghold Snapshot files. You can find migration instructions here.

Version: 0.6

IOTA DIDComm Specification


The IOTA DIDComm Specification is in the RFC phase and may undergo changes. Suggestions are welcome at GitHub #464.

  • Version: 0.1
  • Status: IN-PROGRESS
  • Last Updated: 2021-10-29


The IOTA DIDComm Specification standardizes how Self-Sovereign Identities (SSIs) can interact with each other and exchange information. Any applications that implement this standard will naturally be interoperable with each other. This reduces fragmentation in the ecosystem and therefore it is highly recommended to use this for any application built on top of the IOTA Identity framework. The specification defines several protocols, that can be used for common interactions like issuing and presenting verifiable credentials as well as supporting functions, such as connection establishment and authentication. Cross-cutting concerns like error handling and credential negotiation are discussed in the resources section.

The IOTA DIDComm Specification builds on the DIDComm Messaging Specification developed by the Decentralized Identity Foundation (DIF) and utilises external protocols from the messaging specification for well-established interactions like feature discovery.

This specification is meant to be a complete solution for common use cases and therefore contains protocols for common SSI interactions. It is possible to extend the specification with custom protocols and custom methods in existing protocols to support application-specific requirements.

The specification itself is technology agnostic. Much like the DIDComm Messaging Specification there are no restrictions on transport layers and a concrete implementation can be done with many different technologies.


The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in BCP 14[RFC 2119].


Protocols follow Semantic Versioning 2.0 conventions.


The specification defines several DIDComm protocols that can be used for common SSI interactions:

Connection0.1Establishes a DIDComm connection between two parties.
Authentication0.1Allows two parties to mutually authenticate, verifying the DID of each other.
Presentation0.1Allows presentation of verifiable credentials that are issued to a holder and uniquely presented to a third-party verifier.
Issuance0.1Allows the exchange of a verifiable credential between an issuer and a holder.
Signing0.1Allows a trusted-party to request the signing of an unsigned verifiable credential by an issuer.
Revocation0.1Allows to request revocation of an issued credential, either by the holder or a trusted-party.
Revocation Options0.1Allows discovery of available RevocationInfo types for use with the revocation protocol.
Post0.1Allows the sending of a single message with arbitrary data.
Termination0.1Indicates the graceful termination of a connection.

External Protocols

In addition to the protocols defined in this specification, we RECOMMEND implementors use the following well-known protocols:

Discover Features2.0Describes how agents can query one another to discover which features they support, and to what extent.
Trust Ping1.0A standard way for agents to test connectivity, responsiveness, and security of a DIDComm channel.


Additionally, general guidelines on concerns across protocols are provided:

Problem ReportsDefinitions of expected problem reports and guidance on global handling.
Credential InfoDefinition of methods to negotiate a specific kind of verifiable credential.


The diagrams in this specification follow the BPMN 2.0 notation. The diagrams are created with, the source is embedded in the .svg files.



Future Work

◈ If necessary, discuss ways for some agent to request the start of an interaction. This has narrow use cases, but might be interesting in the long run. ◈ Add section or article on anonymous encryption, sender authenticated encryption, signed messages. Include a table of comparisons with guarantees? E.g. authentication, eavesdropping protection, integrity etc.