DID Communication (DIDComm)

The DIDComm Envelope is the encrypted and signed container for all messages. It uses a JWM (JSON Web Message) format with a layered encryption model:

• Outer Layer: Encrypted for the recipient's public key.
• Inner Layer (Optional): Encrypted for a forwarder or mediator.
• Signature: Attached to prove the sender's identity. This ensures confidentiality, integrity, and authenticity during transport.

DIDComm Protocols are predefined sequences of messages that enable specific interactions, such as issuing a credential or proving a claim. They are defined by:

• A unique Protocol URI (e.g., https://didcomm.org/issue-credential/2.0).
• A set of message types and their expected flow.
• State machines that each party maintains. This formalizes trust frameworks like credential exchange, introductions, and mediated routing.

DIDComm Transports are the mechanisms for delivering envelopes between agents. The protocol is transport-agnostic, working over:

• HTTP(S): For client-server or agent-to-agent communication.
• WebSockets: For persistent, bidirectional connections.
• Bluetooth or NFC: For proximity-based exchanges.
• Mediators: Cloud-based relay services for agents without a public endpoint. The envelope's encryption ensures security regardless of the underlying transport.

A DIDComm Agent is software that sends, receives, and processes DIDComm messages on behalf of an entity (person, organization, or thing). Key functions include:

• Key Management: Securely storing private keys associated with DIDs.
• Protocol Execution: Following the state machine for supported protocols.
• Message Routing: Handling envelopes, including forwarding through mediators. Agents can be cloud-based, mobile wallets, or embedded IoT modules.

Verifiable Credentials (VCs) are a primary payload for DIDComm messages. The protocol enables the entire VC lifecycle:

• Issuance: A holder requests and receives a VC from an issuer via a protocol flow.
• Presentation: A holder presents a VC (or proof derived from it) to a verifier.
• Revocation Status: Verifiers can request real-time status updates. DIDComm provides the secure, private channel for these trust transactions without exposing data to public ledgers.

AnonCreds (Anonymous Credentials) is a specific credential format optimized for privacy, often used with DIDComm. It enables:

• Selective Disclosure: Proving specific claims without revealing the entire credential.
• Zero-Knowledge Proofs: Mathematical proofs that statements are true without revealing underlying data.
• Blinded Issuance: Issuing credentials without the issuer learning the holder's identifier. When paired with DIDComm, AnonCreds provide a powerful system for private, attribute-based interactions.

Replaces traditional, centralized enterprise chat platforms with a decentralized architecture. Messages are end-to-end encrypted using the recipient's public key, ensuring only the intended party can decrypt them. This eliminates reliance on a central server that could be compromised or surveilled.

• Example: Internal corporate communications, board communications, or secure file sharing between departments.

Enables selective disclosure of personal data during logins or KYC processes. Instead of sending a full passport scan to a website, a user can send a cryptographically signed verifiable credential (e.g., "Over 21") via DIDComm. The user's wallet or agent manages the private keys and consent.

• Example: Logging into a financial service by proving citizenship and age without revealing your exact birthdate or document number.

Allows customers to open a direct, secure, and auditable communication channel with a company's support DID. All messages are signed, providing non-repudiation, and the entire thread can be stored in the user's digital wallet as verifiable proof of the interaction.

• Example: A user reporting a banking issue directly from their wallet app, with all correspondence cryptographically tied to both parties' identities.

Facilitates secure, automated communication between IoT devices, servers, or autonomous agents. Each machine has its own DID and can authenticate, authorize, and encrypt messages to other machines without a central broker. This is foundational for decentralized autonomous organizations (DAOs) and smart agent ecosystems.

• Example: A smart thermostat (with a DID) negotiating energy rates and reporting usage data directly to a utility company's server (with a DID).

The core flow for issuing, holding, and presenting verifiable credentials (VCs). An issuer sends a signed VC to a holder's wallet via DIDComm. The holder later presents proof from that VC to a verifier, all using encrypted DIDComm messages. This creates a trust-over-IP model.

• Example: A university issuing a digital diploma to a graduate, who later presents it to a potential employer for verification.

Enables remote, legally-binding document signing with strong cryptographic assurance. All parties sign the document with keys linked to their DIDs. The signature request, document hash, and countersignatures are exchanged through encrypted DIDComm channels, creating a verifiable audit trail.

• Example: Executing a smart contract or a legal agreement where each signature is a verifiable credential tied to an identity.

DIDComm is built on a layered architecture for maximum flexibility and security.

• Transport Layer: Handles the physical delivery of messages (e.g., HTTP, WebSockets, Bluetooth).
• Message Layer: Defines the encrypted envelope format using JWM (JSON Web Messages) and JWE (JSON Web Encryption).
• Application Layer: Contains the actual business logic and message types (e.g., credential offers, proofs, chat).

All DIDComm messages are wrapped in a secure, double-encrypted envelope to ensure confidentiality, integrity, and authenticity.

• Outer Envelope: Encrypted for the recipient's public key, ensuring only the intended DID holder can open it.
• Inner Envelope: Optionally encrypted for forward secrecy, protecting message content even if long-term keys are compromised.
• Non-Repudiation: Messages are signed, providing cryptographic proof of the sender's identity.

To enable communication when parties are offline or behind firewalls, DIDComm uses intermediaries.

• Mediators: Act as message queues, storing and forwarding encrypted messages on behalf of a DID. The mediator cannot read the message content.
• Relays: Simple routers that pass encrypted messages without storage, often used in mobile or IoT contexts.
• DIDComm Hubs: Cloud-based services that provide mediator and relay functionality at scale.

A primary application of DIDComm is the secure, peer-to-peer exchange of Verifiable Credentials (VCs).

• Credential Offer: An issuer sends an encrypted offer to a holder.
• Credential Request & Issuance: The holder requests and receives the signed VC.
• Presentation Request & Proof: A verifier requests proof, and the holder sends a Verifiable Presentation, all within encrypted DIDComm messages.

Development is accelerated by open-source frameworks that handle DIDComm's complexity.

• Aries Framework (Python, .NET, Go, JavaScript): The most comprehensive suite, providing cloud and mobile agents.
• DIDComm JS / DIDComm TS: Lightweight libraries focused on the core message encryption/decryption logic.
• Veramo: A modular framework for SSI that includes a robust DIDComm v2 module. These SDKs manage key rotation, message threading, and connection protocols.

A Decentralized Identifier (DID) is a globally unique, cryptographically verifiable identifier that is controlled by its subject, not a central registry. It is the foundational address for DIDComm, enabling secure routing of encrypted messages.

• Structure: did:method:method-specific-identifier (e.g., did:key:z6Mk...).
• Control: Proved via cryptographic keys listed in the DID's DID Document.
• Purpose: Provides the endpoint and keys needed to establish a secure communication channel.

A Verifiable Credential is a tamper-evident digital claim, like a passport or diploma, issued by an authority and cryptographically signed. In DIDComm, VCs are often the payload of messages to prove attributes.

• Core Components: Issuer, holder, subject, and cryptographic proof.
• Usage: Enables selective disclosure, where a user can share only specific claims from a credential.
• Standard: Defined by the W3C Verifiable Credentials Data Model.

A DID Document is a JSON-LD document that describes the cryptographic material and service endpoints associated with a DID. It is the "phone book" entry for DIDComm routing.

• Contents: Contains public keys, authentication mechanisms, and service endpoints (like a DIDComm messaging inbox).
• Resolution: Fetched from a verifiable data registry (e.g., a blockchain) using a DID resolver.
• Function: Provides the necessary data to encrypt a message for the DID's controller.

An Agent is a software component that acts on behalf of a DID controller, sending, receiving, and processing DIDComm messages. It manages keys, protocols, and wallet functions.

• Types: Range from cloud-based mediators to edge agents on mobile devices.
• Responsibilities: Handles message packing (encryption), protocol execution, and credential storage.
• Ecosystem: Agents interoperate using standardized protocols defined in the Aries RFCs or other DIDComm v2 specifications.

DIDComm uses layered JWM (JSON Web Messages) encryption to ensure confidentiality, integrity, and authenticity. Packing refers to the encryption and serialization format.

• Anoncrypt: Encrypts to the recipient's public key, hiding the sender.
• Authcrypt: Encrypts and signs, proving the message came from a specific sender.
• Formats: Messages can be packed as JWE (JSON Web Encryption) or compact, binary serializations for different transport layers.