did:peer
Identity Protocol
Community
Links
Details
License Open specification (DIF document licence); permissively licensed implementations across the DIDComm agent ecosystem
Dev Status 🟢 Active
Owner Decentralized Identity Foundation (DIF) — specification contact listed in the W3C registry is Daniel Hardman
Governing Body DIF
Country International (DIF process; contributors principally USA-based)
Start Year 2019
Stack Language-agnostic specification; implementations in TypeScript, Python, Rust, Kotlin and Swift across DIDComm agent frameworks
Funding N/A — no infrastructure to fund
Last Investigated Jul 1, 2026
Identity Protocol Attributes
Origins Peer-to-peer secure messaging — created for DIDComm, where two agents need mutually authenticated identifiers for a private relationship and publishing anything to a public registry would be both unnecessary and a privacy leak
Database N/A — no external storage. Each party stores the counterparty's DID document in its own agent wallet
Query Language N/A — resolution is local, from state received out of band during relationship establishment, or decoded directly from the identifier for numgen method 2
Data Formats W3C DID Document; identifier encodings by numalgo — method 0 (inception key), method 1 (genesis document hash), method 2 (multikey encoding of keys and services inline in the DID), method 4 (hashed long form and short form)
Mobile Support Library-level — implemented inside resolver libraries and wallets; no standalone application
Web Support N/A — nothing is published to the web; libraries run in browser-based agents but no web infrastructure is involved
Native Apps Library-level — embedded in resolver libraries; no standalone application
Terms Free — no fees, registration or infrastructure
Funds N/A
Based On W3C DID Core 1.0; Multiformats (multibase/multicodec) for key encoding; developed as the identifier layer for DIDComm messaging
Permissions Cryptographic, relationship-scoped — key control within the pairwise relationship is the entire authorization model
Authentication & Identity Pairwise and self-certifying — the identifier is derived from key material and exchanged directly, so binding requires no third party. Each relationship typically uses a distinct DID, so there is no shared identifier across counterparties to correlate
Storage Model Local only — both parties retain their own copy of the relationship state; nothing is replicated to any external system. For numgen method 2 the document is decodable from the identifier itself, so no storage is strictly required
Interoperability Deeply embedded in the DIDComm ecosystem — the default method for DIDComm v2 connections and supported across Aries, Credo and OpenWallet Foundation agent frameworks. Less commonly used outside agent-to-agent messaging
Data Portability Relationship-scoped — the identifier is portable in the sense that it depends on no infrastructure, but it is meaningful only to the parties holding the corresponding state, so it does not travel independently
Governance & Decision Making DIF — open specification work item with public repository and participation
Protocol Maturity / Standardization Registered W3C DID method, widely implemented as DIDComm's default, but the specification remains a DIF work item rather than a ratified standard, and the absence of key rotation is a recognised functional gap
Identity Standards W3C DID Core 1.0; DIDComm Messaging v2; registered in the W3C DID Extensions methods registry
DID Methods Supported did:peer (defines this method). Identified by the ToIP did:scid specification as the first SCID-based DID method, though explicitly not adopted as a did:scid format
Key Management Limited — the specification does not provide key rotation. Changing keys generally means establishing a new relationship with a new DID. This is the documented reason the ToIP did:scid specification declines to adopt it as a format
Credential Types N/A — a DID method specification; defines no credential types. Compatible with W3C Verifiable Credentials issued against identifiers of this method
Verification Method Cryptographic, from locally held or inline-encoded key material; for numgen method 2 the verification methods are decoded directly from the identifier with no lookup at all
Privacy Features Strongest on this tab for correlation resistance — identifiers are never published, a distinct DID is normally used per relationship, and there is no registry, log or host that could reveal usage patterns. Designed for pairwise pseudonymity
Authentication Methods Cryptographic signature and DIDComm authenticated encryption between the two parties
Revocation Mechanism Relationship termination — a party discards the relationship state. There is no global revocation record because there is no global record of any kind
Agent Types Supported Any key-controlling entity — individuals, organizations, services and devices
Wallet/Client Types SDK / library integration — resolver implementations across the SSI tooling ecosystem; no method-specific wallet
Recovery Mechanisms None at the method level — recovery depends on the agent's own wallet backup. Loss of relationship state generally means re-establishing the connection
Compliance / Regulations Not addressed by the specification. The absence of key rotation and of any audit log limits suitability where lifecycle management or supervisory access is required
Credential Exchange Protocols DIDComm v2 (its native context, where it remains the default method); usable with any protocol that accepts locally resolved DIDs
Trust Framework Pure cryptography, scoped to the relationship — no external trust anchor, no registry and no third party; trust is whatever the two parties established when they connected
Cost Model Free — zero marginal cost per relationship, which is what makes per-counterparty identifiers practical
Censorship Resistance Maximal in practice — nothing is published, so there is no host to seize, registrar to compel or endpoint to block. Censorship would require compromising the parties themselves