did:key

Identity Protocol

A ledger-independent DID method in which the identifier is the public key itself: a did:key DID is a multibase-encoded, multicodec-prefixed public key, and the entire DID document is derived deterministically from it by the resolver. There is no registry, no network, no ledger and no lookup — resolution is a pure local function with no I/O. The trade-off is total: because nothing is stored anywhere, keys cannot be rotated and the DID cannot be updated or deactivated. It is the baseline method supported by essentially every SSI toolchain, and the structural floor for capture risk in the entire decentralized-identity space.

Comunidade

Detalhes

Licença Open specification (W3C CCG document licence); numerous permissively licensed independent implementations across JavaScript, Rust, Python, Java, Go and Swift
Status de Dev 🟢 Ativo
Proprietário W3C Credentials Community Group — specification authors Manu Sporny, Dmitri Zagidulin and Dave Longley (as listed in the W3C DID Extensions methods registry)
Órgão de Governança W3C Community Group (Credentials Community Group)
País International (W3C Community Group process; contributors principally USA-based)
Ano de Início 2019
Stack Language-agnostic specification; resolution is a pure function over multicodec/multibase encoding with no network dependency
Financiamento N/A — no ongoing funding required; specification work carried out by W3C CCG participants
Última Investigação 1 de jul. de 2026

Domínios de Caso de Uso

Identity Protocol Atributos

Origins Self-sovereign identity — created to provide the simplest possible conformant DID method, usable for ephemeral and pairwise identifiers, testing, and any case where no persistent infrastructure should be required
Database N/A — no storage of any kind. The DID document is computed from the identifier itself
Query Language N/A — resolution is a local deterministic transformation requiring no query or network request
Data Formats W3C DID Document generated deterministically; identifier is multibase-encoded multicodec public key material. Supported key types include Ed25519, X25519, secp256k1, P-256/P-384/P-521 and RSA
Mobile Support Library-level — implemented inside resolver libraries and wallets; no standalone application
Web Support N/A as infrastructure — resolution requires no web request at all; resolver libraries run in browsers, but the method depends on no web service
Native Apps Library-level — embedded in resolver libraries; no standalone application
Terms Free — no fees, no registration, no infrastructure
Funds N/A
Based On W3C DID Core 1.0; multicodec and multibase (Multiformats) for key encoding; the underlying signature algorithms themselves
Permissions Cryptographic — key control is the whole of the authorization model
Authentication & Identity Self-certifying in the strongest sense — the identifier is the public key, so binding between identifier and key material is definitional and requires no verification step, no registry and no third party
Storage Model None — nothing is stored. The DID document exists only as a derivation performed at resolution time
Interoperability Universal within the W3C DID ecosystem — supported by essentially every DID resolver, wallet and VC library; commonly used as the default method in test suites and as the fallback where no infrastructure is available
Data Portability Complete but immutable — the DID is portable everywhere because it depends on nothing, but it can never be updated, so portability and rigidity are the same property
Governance & Decision Making W3C Credentials Community Group — open participation, consensus process, public repository
Protocol Maturity / Standardization Registered W3C DID method with universal implementation support, but the specification remains a W3C CCG draft rather than a Recommendation. Maturity in practice comes from ubiquity of implementation rather than formal status
Identity Standards W3C DID Core 1.0; Multiformats (multicodec, multibase); registered in the W3C DID Extensions methods registry
DID Methods Supported did:key (defines this method)
Key Management None — no rotation, no update, no deactivation. A compromised or lost key means the identifier is permanently unusable; the only remedy is to issue a new DID. This is the method's defining limitation
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 Deterministic derivation — the verification method is computed directly from the identifier, so verification requires no external lookup and cannot be tampered with in transit
Privacy Features Well suited to pairwise and ephemeral identifiers — since creation costs nothing and touches no registry, a fresh did:key can be generated per relationship or per interaction, avoiding correlation. Nothing is ever published
Authentication Methods Cryptographic signature by the private key corresponding to the identifier
Revocation Mechanism None — a did:key cannot be revoked or deactivated. Revocation must be handled at the credential or relationship layer instead
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 — no recovery is possible by design; loss of the private key is terminal for that identifier
Compliance / Regulations Not addressed by the specification. Its lack of rotation and revocation makes it unsuitable on its own for regimes requiring key lifecycle management
Credential Exchange Protocols Compatible with any protocol that resolves W3C DIDs, including DIDComm and OpenID4VC; frequently used for ephemeral holder-binding keys in credential presentation
Trust Framework Pure cryptography — no trust anchor exists or is needed; the identifier and the key are the same object
Cost Model Free — zero marginal cost per identifier; creation is a local key generation
Censorship Resistance Maximal — there is no registry to block, no host to seize, no operator to compel and no network request to intercept. Resolution works offline and indefinitely