DIDComm

Identity Protocol

Specification for secure, asynchronous, end-to-end encrypted messaging between parties identified by Decentralized Identifiers (DIDs). Defines envelope formats, encryption, signing, threading, transport-independence, and protocol-on-protocol patterns — anything party-to-party that needs DID-rooted authentication and confidentiality can be expressed as a DIDComm protocol. Higher-order protocols (issue-credential, present-proof, etc.) inherit DIDComms security, privacy, decentralization, and transport independence. Works over any transport: HTTP, BlueTooth, SMTP, raw sockets, etc.

Comunidade
Links
Visitar Comunidade

Detalhes

Licença Spec: Apache 2.0; multiple independent implementations (didcomm-rs, didcomm-jvm, didcomm-python, walt.id, SpruceID, Aries family)
Status de Dev 🟢 Ativo
Detalhe do Status de Dev Released — DIDComm v2 reached DIF Approved Spec status July 2022; v2.1 in production
Proprietário Decentralized Identity Foundation (DIF) — non-profit standards body; spec maintained by the DIDComm Messaging Working Group
País International (DIF: USA-incorporated, global membership)
Ano de Início 2019
Stack Specification only (no canonical implementation stack); reference implementations in Rust (didcomm-rs by DIF), Python, TypeScript/JavaScript, Java, Go, Swift
Financiamento DIF (member-funded standards body)
Última Investigação 1 de jul. de 2026

Domínios de Caso de Uso

Identity & Trust

Identity Protocol Atributos

Origins Hyperledger Aries community (DIDComm v1); DIF migration and v2 redesign 2020-2022
Database N/A — specification is a transport-layer messaging protocol; persistence is implementation concern (typically wallet-side encrypted message stores)
Query Language N/A — DIDComm is asynchronous message passing; query patterns are implemented as application-layer protocols (e.g., discover-features, basic-message) running over DIDComm
Data Formats JWE (JSON Web Encryption) + JWS (JSON Web Signature) wrappers; JSON message bodies
Mobile Support Yes (transport-agnostic; multiple mobile SDKs and wallet implementations)
Web Support Yes (HTTPS transport)
Native Apps Yes (Bluetooth, raw sockets, push-notification mediator patterns)
Terms Open standard, free to implement; DIF IPR protections require working group membership for normative contributions
Funds Unknown — DIF working group funded by member dues and member-organization staff time; reference implementations developed by member organizations on their own funding (Indicio, Anonyome, Mattr, walt.id) without a published per-spec budget
Based On W3C Decentralized Identifiers (DIDs); JOSE (JWE/JWS); IETF cryptographic primitives
Permissions Implementation-defined at the DIDComm layer — DIDComm itself does not specify authorization model; subprotocols (issue-credential, present-proof, etc.) define their own permission semantics, and trust is rooted in DIDs of communicating parties
Authentication & Identity DID-rooted — sender and recipient identified by DIDs whose keys are used for signing and encryption
Storage Model Stateless protocol — no message persistence at the protocol layer; mediators may queue messages for offline recipients
Interoperability Multiple independent implementations (Aries, walt.id, SpruceID, didcomm-rs); transport-independent
Data Portability High — messages are self-contained signed/encrypted artifacts portable across transports; mediator handoff supported; relationships portable across device changes via key rotation (from_prior JWT)
Governance & Decision Making DIF DIDComm Working Group governance — open meetings (Mondays 12pm PST), IPR-protected contributions under DIF membership, consensus-driven specification process; chartered January 2020 building on Hyperledger Aries community work; aligns with W3C, IETF, and Aries communities
Protocol Maturity / Standardization DIF Approved Spec (v2 since July 2022); v2.1 current; production deployments in government, travel, and enterprise
Identity Standards W3C DIDs; W3C VCs (commonly carried as DIDComm payloads); DIF DIDComm v2.1
DID Methods Supported Any DID method — DIDComm is method-agnostic (did:key, did:web, did:peer, did:ion, did:indy, etc.)
Key Management Per DID method; DIDComm uses keys from DID documents for signing/encryption
Credential Types Transport for any credential format (W3C VC, AnonCreds, mDoc, etc.); not credential-format-specific
Verification Method JWS signatures verifiable against DID document keys
Privacy Features Anoncrypt (anonymous encryption hides sender identity); routing through mediators for metadata privacy; per-message ephemeral keys
Authentication Methods Authcrypt (signed + encrypted) and Anoncrypt (anonymous encryption); DID rotation support for relationship lifecycle
Revocation Mechanism Per credential format (DIDComm carries revocation messages but does not define revocation semantics); DID rotation for key compromise
Agent Types Supported Edge agents (people, IoT), cloud agents, mediators, routing agents — full agent topology supported
Wallet/Client Types Mobile wallets, cloud agents, web wallets; reference implementations in Rust, JavaScript, Python, JVM, .NET
Recovery Mechanisms Relationship-level rotation via from_prior JWT mechanism (rotate sender DID and re-establish thread continuity); credential-level recovery handled by carried credential protocols rather than DIDComm itself
Compliance / Regulations Used in eIDAS, GDPR, and similar regulatory contexts as the secure communication layer underneath verifiable credential exchange; deployed in EUDI Wallet implementations and Indy/Aries deployments in government identity programs
Credential Exchange Protocols Issue Credential v2, Present Proof v2, Out-of-Band, DID Exchange — all DIDComm sub-protocols
Trust Framework Transport-agnostic — works under any trust framework (eIDAS 2.0, TOIP, etc.); used in BC Government, US DHS SVIP, IATA travel, IDUnion
Cost Model Free — open standard, royalty-free under DIF IPR policy; implementation cost limited to chosen libraries and infrastructure
Censorship Resistance High — works over any transport including SMTP, Bluetooth, sneakernet; no required server