DID Communication

A protocol for initiating a DIDComm connection without a prior relationship. It uses a special message format (often encoded as a QR code or deep link) containing:

• The inviter's DID and public key material.
• The endpoint URL for the DIDComm transport.
• Optional service endpoint metadata. This is the standard method for onboarding new users into a verifiable credential ecosystem.

A three-step interactive protocol where an issuer grants a verifiable credential to a holder. The flow consists of:

1. Proposal/Offer: The issuer offers a credential with a specific schema.
2. Request: The holder requests issuance, proving control of their DID.
3. Issue: The issuer signs and transmits the final W3C Verifiable Credential. This protocol ensures the credential is bound to the holder's DID before issuance.

A protocol where a verifier requests and a prover presents proof derived from their verifiable credentials. It supports:

• Selective disclosure using BBS+ signatures.
• Predicate proofs (e.g., proving age > 21 without revealing birthdate).
• Presentation requests specifying required credential types and constraints. The prover constructs a Verifiable Presentation, a cryptographically verifiable package of proofs.

A protocol for peers to dynamically discover each other's supported protocols and features. It enables protocol negotiation and interoperability by querying:

• Supported DIDComm protocol identifiers and versions.
• Available message types and their roles.
• Feature disclosures to avoid sending unsupported messages. This is critical for agents from different vendors to communicate effectively.

A simple liveness and connectivity test protocol. One agent sends a trust ping message, and the other responds with a trust pong. This is used to:

• Verify an active DIDComm connection.
• Measure round-trip latency.
• Confirm the other agent can decrypt messages for a given DID. It's the foundational protocol for basic agent-to-agent communication health checks.

DIDComm messages are encrypted at the application layer using the recipient's public key, ensuring confidentiality even if relay servers are compromised. This is typically achieved via Authenticated Encryption (e.g., using the X25519 key agreement and AES-GCM). The protocol ensures that only the intended recipient, holding the corresponding private key, can decrypt and read the message content.

Every DIDComm message is cryptographically signed by the sender using their private key. This provides non-repudiation and data integrity, allowing the recipient to verify:

• The message originated from the claimed sender's DID.
• The message was not altered in transit.
• The sender cannot later deny sending the message. Signatures are typically implemented using Ed25519 or ES256K algorithms.

While message content is private, metadata privacy is a significant challenge. DIDComm often relies on DID Document Service Endpoints (URLs) for message routing, which can leak relationship graphs and communication patterns. Techniques to mitigate this include:

• Using blinded message envelopes.
• Routing through anonymous message relays.
• Leveraging pairwise DIDs (unique DIDs for each relationship) to prevent correlation.

The protocol must defend against common network attacks. Key mitigations are:

• Nonces and Timestamps: To prevent replay attacks where an old message is resent.
• Key Rotation: Regularly updating DID key material to limit exposure from key compromise.
• Forward Secrecy: While not inherent, it can be achieved by using ephemeral key pairs for each session, ensuring past communications remain secure if a long-term key is later compromised.

Security depends on the ability to authentically resolve a DID to its Document and verify the associated public keys. This introduces a dependency on the chosen Verifiable Data Registry (e.g., a blockchain). Attacks can target the resolution layer through:

• DNS spoofing of HTTP-based DID resolvers.
• Sybil attacks on permissionless ledgers.
• Malicious DID Document updates. Verifiers must trust the resilience of the underlying registry.

When using Verifiable Credentials over DIDComm, selective disclosure is crucial. Best practices to prevent data leakage include:

• Using Zero-Knowledge Proofs (ZKPs) to prove claims without revealing the underlying credential data.
• Bounding Presentation Requests to prevent verifiers from asking for unnecessary personal data.
• Minimizing Correlation by using different DIDs or pseudonyms for different verifiers to avoid creating a unified identity graph.

To enable communication with DIDs that are not always online or are behind firewalls, DIDComm employs mediators (for mobile agents) and relays. These are trusted routing services that hold encrypted messages for later delivery. This architecture is essential for peer-to-peer interactions in mobile and IoT contexts, decoupling message delivery from endpoint availability.

DIDComm defines specific protocol flows for common interactions. Core protocols include:

• Connection Protocol: Establishes a pairwise DID relationship.
• Issue Credential Protocol: For issuing verifiable credentials.
• Present Proof Protocol: For creating and verifying verifiable presentations.
• Discover Features Protocol: For agents to discover each other's capabilities. These protocols enable trusted, automated interactions without centralized servers.

DIDComm enables practical decentralized identity solutions:

• Digital Wallets: Mobile apps for holding credentials (e.g., driver's licenses, diplomas).
• Enterprise SSO: Passwordless, phishing-resistant authentication for employees.
• Supply Chain: Verifiable credentials for product provenance and compliance.
• Healthcare: Secure exchange of patient health records and provider credentials.

A Decentralized Identifier (DID) is a globally unique, persistent identifier that does not require a centralized registry. It is the foundational component for DIDComm, providing the addressable endpoint (the DID subject) to which messages are sent. DIDs are typically resolved to a DID Document containing public keys and service endpoints for communication.

• Example: did:example:123456789abcdefghi
• Key Property: Verifiable and under the control of the identity owner.

A Verifiable Credential (VC) is a tamper-evident digital claim issued by one party to another, which can be cryptographically verified. DIDComm is a primary transport layer for requesting, issuing, and presenting VCs in a privacy-preserving manner. This enables trusted data exchange, such as proving age or membership, without revealing the underlying DID.

• Standard: Defined by the W3C Verifiable Credentials Data Model.
• Use Case: Selective disclosure of attributes during a DIDComm interaction.

A DID Document is a JSON-LD document containing the public keys, authentication mechanisms, and service endpoints required to interact with a DID. For DIDComm, it specifies the location (endpoint) and the encryption keys necessary to establish a secure communication channel. The document is discovered through DID Resolution.

• Contains: verificationMethod, authentication, keyAgreement, and service entries.
• Purpose: Enables discovery and trust for message routing and encryption.

An Agent is a software component that acts on behalf of a DID controller to send, receive, and process DIDComm messages. Agents manage cryptographic keys, maintain connections (peer DIDs), and facilitate protocols like credential exchange. They can be cloud-based, mobile, or embedded.

• Function: Handles the core messaging envelope (JWM) and protocol state machines.
• Examples: Mobile wallets, enterprise backend services, or IoT device controllers.

The Peer DID Method (did:peer) is a DID method specifically designed for private, pairwise relationships between two agents. Unlike public, resolvable DIDs, peer DIDs are created locally and exchanged directly, offering enhanced privacy by preventing correlation across different relationships. They are commonly used as the foundation for DIDComm connections.

• Characteristic: Not recorded on a public ledger.
• Advantage: Eliminates public metadata leakage about relationship graphs.

DIDComm Messaging Protocols are predefined interaction patterns that govern how agents communicate to achieve specific goals. These protocols define the sequence, format, and semantics of messages for use cases like connection establishment, credential issuance, and proof presentation. They ensure interoperability between different agent implementations.

• Examples: DID Exchange Protocol, Issue Credential v2.0, Present Proof v2.0.
• Foundation: Built on top of the secure transport provided by DIDComm envelopes.