did:peer

Protocolo de Identidad

A DID method for identifiers that are never published anywhere. A did:peer DID is generated locally and exchanged directly between the parties to a relationship, who each store the other's DID document themselves; no registry, ledger or web host is ever involved. This makes it the natural method for pairwise relationships — a fresh DID per counterparty, with no global correlation surface — and it remains the default method used in DIDComm messaging. Numgen method 2 encodes keys and service endpoints directly into the identifier; method 4 adds a hash-based long/short form. The ToIP did:scid specification identifies did:peer as the first SCID-based DID method, while excluding it from its own format registry because it lacks key rotation.

Comunidad

Detalles

Licencia Open specification (DIF document licence); permissively licensed implementations across the DIDComm agent ecosystem
Estado de Desarrollo 🟢 Activo
Propietario Decentralized Identity Foundation (DIF) — specification contact listed in the W3C registry is Daniel Hardman
Órgano de Gobierno DIF
País International (DIF process; contributors principally USA-based)
Año de Inicio 2019
Stack Language-agnostic specification; implementations in TypeScript, Python, Rust, Kotlin and Swift across DIDComm agent frameworks
Financiamiento N/A — no infrastructure to fund
Última Investigación 1 jul 2026

Protocolo de Identidad Atributos

Orígenes 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
Base de Datos N/A — no external storage. Each party stores the counterparty's DID document in its own agent wallet
Lenguaje de Consulta N/A — resolution is local, from state received out of band during relationship establishment, or decoded directly from the identifier for numgen method 2
Formatos de Datos 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)
Soporte Móvil Library-level — implemented inside resolver libraries and wallets; no standalone application
Soporte Web N/A — nothing is published to the web; libraries run in browser-based agents but no web infrastructure is involved
Aplicaciones Nativas Library-level — embedded in resolver libraries; no standalone application
Términos Free — no fees, registration or infrastructure
Fondos N/A
Basado En W3C DID Core 1.0; Multiformats (multibase/multicodec) for key encoding; developed as the identifier layer for DIDComm messaging
Permisos Cryptographic, relationship-scoped — key control within the pairwise relationship is the entire authorization model
Autenticación e Identidad 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
Modelo de Almacenamiento 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
Interoperabilidad 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
Portabilidad de Datos 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
Gobernanza y Toma de Decisiones DIF — open specification work item with public repository and participation
Madurez del Protocolo / Estandarización 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
Estándares de Identidad W3C DID Core 1.0; DIDComm Messaging v2; registered in the W3C DID Extensions methods registry
Métodos DID Soportados 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
Gestión de Claves 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
Tipos de Credenciales N/A — a DID method specification; defines no credential types. Compatible with W3C Verifiable Credentials issued against identifiers of this method
Método de Verificación 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
Funciones de Privacidad 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
Métodos de Autenticación Cryptographic signature and DIDComm authenticated encryption between the two parties
Mecanismo de Revocación Relationship termination — a party discards the relationship state. There is no global revocation record because there is no global record of any kind
Tipos de Agentes Soportados Any key-controlling entity — individuals, organizations, services and devices
Tipos de Billetera/Cliente SDK / library integration — resolver implementations across the SSI tooling ecosystem; no method-specific wallet
Mecanismos de Recuperación None at the method level — recovery depends on the agent's own wallet backup. Loss of relationship state generally means re-establishing the connection
Cumplimiento / Regulaciones 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
Protocolos de Intercambio de Credenciales DIDComm v2 (its native context, where it remains the default method); usable with any protocol that accepts locally resolved DIDs
Marco de Confianza 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
Modelo de Costos Free — zero marginal cost per relationship, which is what makes per-counterparty identifiers practical
Resistencia a la Censura 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