Skip to main content

DIDComm

DIDComm Messaging defines secure, private, message-based communication in which trust can be rooted in decentralized identifiers. Message protection remains independent of the delivery transport, allowing authorized agents to communicate across HTTPS, mobile, asynchronous, or mediated environments.

UbID uses DIDComm for guarded identity-bound exchanges, including selected recovery and institutional coordination flows.

Message protection​

DIDComm supports plaintext, signed, and encrypted message forms. Encrypted messages can use:

  • authcrypt, which encrypts for the recipient and provides direct assurance of the sender;
  • anoncrypt, which encrypts for the recipient without directly identifying the sender through the encryption layer.

The chosen form depends on the protocol and privacy requirements. A protected envelope does not authorize the business action carried inside it; the receiving service still validates the message type, participants, purpose, state, freshness, and policy.

Transport independence​

DIDComm separates message trust from delivery. An HTTPS connection, push service, mediator, or other transport carries the protected envelope but should not need access to its plaintext.

Transport security remains important. It can protect availability, metadata, endpoint authentication, and network confidentiality, while the DIDComm envelope protects the message itself.

Protocols and threads​

A single protected message is not the complete interaction. DIDComm protocols define message types, roles, sequencing, acknowledgements, errors, and state transitions.

Thread identifiers allow related messages to be associated with one interaction. Implementations should reject unexpected messages, invalid state transitions, expired requests, duplicate operations, or messages from unauthorized participants.

Routing and mediation​

A mobile or intermittently connected agent may use a mediator. The mediator can receive encrypted envelopes and make them available for later pickup without becoming an authorized reader of the plaintext.

Coordinate Mediation and Message Pickup profiles can support registration, routing, queue status, and store-and-forward delivery. A production profile must define retention, quotas, expiry, delivery acknowledgement, replay handling, abuse controls, and metadata minimisation.

Mediation is a delivery service, not an identity authority or recovery custodian by default.

DIDComm in recovery​

DIDComm can carry protected recovery requests, authorizations, evidence, and encrypted recovery artifacts between authorized participants. It does not decide whether recovery should proceed and must not receive unrestricted authority to reconstruct or release a complete secret.

The recovery policy remains staged and governed. Message security is one control within that policy.

Privacy considerations​

Even when payloads are encrypted, observers may infer metadata such as timing, message size, routing relationships, and endpoint usage. Implementations should minimise stable routing identifiers, unnecessary headers, long retention, verbose errors, and operational logging of sensitive metadata.

Interoperability requirements​

A DIDComm partner profile should define:

  • DID methods and verification relationships supported;
  • DIDComm version and accepted media types;
  • cryptographic suites and key-agreement rules;
  • protocol and message-type versions;
  • routing and mediation behavior;
  • attachment limits and integrity checks;
  • timeout, retry, acknowledgement, and duplicate handling;
  • audit events and privacy restrictions;
  • conformance and negative tests.

UbID position​

DIDComm v2 authcrypt is part of the implemented UbID interoperability baseline for guarded agent and recovery flows. Coordinate Mediation and Message Pickup are future or profile-dependent capabilities and must not be presented as universally available.

Public documentation boundary​

This page does not expose agent endpoints, mediator topology, routing keys, production DIDs, message queues, recovery participants, encrypted artifacts, protocol credentials, or operational retention values.

Source standards​

See UbID Connect and Recovery and Continuity.