did:key is a Decentralized Identifier (DID) method defined by the W3C that creates a fully self-contained identifier directly from a cryptographic public key, without requiring a blockchain, registry, or any other external resolution system. The DID itself is formed by encoding the public key—such as an Ed25519 or secp256k1 key—using a multibase and multicodec prefix, resulting in a string like did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK. This method is prized for its simplicity, portability, and suitability for peer-to-peer interactions where a lightweight, verifiable identifier is needed without the overhead of a distributed ledger.
LABS
Glossary
did:key
A Decentralized Identifier (DID) method where the DID itself is a bare public key, allowing its corresponding DID document to be derived algorithmically without querying a registry or resolver.
Chainscore © 2026
definition
DECENTRALIZED IDENTIFIER METHOD
What is did:key?
A simple, self-contained method for creating Decentralized Identifiers (DIDs) using cryptographic public keys.
The primary technical components of a did:key are the public key material and the DID Document (DIDD). Unlike other DID methods that store the DIDD on a verifiable data registry, the DID Document for a did:key is derived algorithmically from the public key embedded within the identifier itself. This process, known as static resolution, means the document's verification methods, such as the verificationMethod and assertionMethod, are directly inferred from that key. Consequently, the identifier and its verification capabilities are inseparable, making it ideal for static, long-lived cryptographic relationships.
A key advantage of the did:key method is its deterministic nature; the same public key will always generate the same DID and DID Document. This property eliminates the need for network lookups, ensuring resolution works offline and provides strong cryptographic guarantees. However, this also introduces a significant limitation: did:key identifiers are not rotatable or revocable. If a private key is compromised, the entire DID must be abandoned, as there is no mechanism to update the associated public key. This makes it unsuitable for many long-term, production identity systems where key lifecycle management is critical.
Common use cases for did:key include secure communication protocols (like DIDComm), verifiable credentials in closed or ephemeral systems, and as a foundational component in developer tooling and testing. It serves as a convenient way to bootstrap decentralized identity concepts without the complexity of managing a DID registry. For scenarios requiring key rotation, revocation, or service endpoint updates, other DID methods like did:ethr or did:ion that rely on verifiable data registries (e.g., blockchains) are more appropriate.
When working with did:key, developers typically use libraries that implement the DID Core and DID Key specifications. The process involves generating a key pair, constructing the DID string, and then using a resolver to algorithmically generate the corresponding DID Document. This document can then be used to perform cryptographic operations such as creating and verifying JSON Web Tokens (JWTs) or Data Integrity proofs, enabling trust in a purely peer-to-peer manner.
etymology
DECODING THE IDENTIFIER
Etymology and Origin
The `did:key` method's name and structure are a direct reflection of its core technical design principle: a self-contained, cryptographic identifier.
The term did:key is a compound identifier within the Decentralized Identifier (DID) framework standardized by the W3C. It is composed of two parts separated by a colon: the universal did: scheme and the specific key method name. The did: prefix signals that the string conforms to the DID specification, while the key segment specifies the exact method for creating and resolving the identifier. This follows the standard DID syntax pattern of did:<method-name>:<method-specific-identifier>.
The key method name was chosen because the identifier is derived directly from a public cryptographic key, most commonly using the Ed25519 signature system. Unlike other DID methods that rely on external verifiable data registries (VDRs) like blockchains (did:ethr, did:sov), a did:key is entirely self-describing. The 'method-specific identifier' is a base58-encoded multihash of the public key material itself, meaning the DID document can be generated algorithmically from the identifier without querying a network.
The conceptual origin of did:key lies in the need for a simple, portable, and offline-verifiable DID. It was formally described in the W3C DID Core specification as a reference method and is heavily utilized in Verifiable Credentials ecosystems for peer-to-peer interactions. Its design prioritizes cryptographic agility, supporting various key types (e.g., RSA, secp256k1) through the multiformats-based multicodec prefix embedded in its identifier, ensuring the method can evolve with advances in cryptography.
how-it-works
DECENTRALIZED IDENTIFIER METHOD
How did:key Works
The did:key method is a simple, self-contained Decentralized Identifier (DID) specification that enables cryptographic key pairs to be used directly as globally unique, persistent identifiers without requiring a blockchain or centralized registry.
A did:key is generated by encoding a public key directly into the DID itself. The process begins with a cryptographic key pair, such as an Ed25519 or secp256k1 key. The public key is then encoded using a multibase and multicodec prefix (e.g., z for base58btc) to indicate the key type and encoding format. This encoded string is appended to the did:key: prefix, forming a complete DID like did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK. This DID document is not stored on a ledger; it is derived algorithmically from the public key.
The corresponding DID Document is generated dynamically from the DID itself. Anyone can compute the document by decoding the public key from the identifier. The document contains the public key in its verificationMethod section, along with standard properties like authentication and assertionMethod, which reference this key. This design ensures the DID is self-certifying—the proof of ownership is intrinsic to the identifier, and no external resolution or lookup is required to understand its basic cryptographic material.
The primary use case for did:key is in peer-to-peer interactions and offline scenarios where ledger-based resolution is impractical or unnecessary. It is ideal for temporary relationships, static configurations, development testing, and embedding verifiable credentials. However, its simplicity is also a limitation: a did:key cannot be updated or revoked, as there is no underlying registry. If a private key is compromised, the identifier becomes permanently insecure, making it unsuitable for long-term, high-stakes identities where key rotation is required.
In practice, did:key is often contrasted with blockchain-anchored DID methods like did:ethr or did:ion. While ledger-based methods provide a mutable record for key rotation and service endpoints, did:key offers a lightweight, immediate alternative. It is formally specified by the W3C DID Working Group and is widely supported in libraries for Decentralized Identity and Verifiable Credentials, serving as a fundamental building block for cryptographic identity proofs.
key-features
DID:KEY
Key Features and Characteristics
did:key is a simple, self-contained Decentralized Identifier (DID) method that encodes a public key directly into the DID itself, without requiring a blockchain or external resolver.
01
Self-Sovereign & Self-Contained
A did:key is generated and verified entirely from the cryptographic key material itself. It does not rely on a distributed ledger, registry, or ongoing network availability for resolution. This makes it portable and resolvable offline, as the DID document is derived deterministically from the public key.
02
Deterministic DID Document
The corresponding DID Document is not stored but computed on the fly. It contains:
- The public key in multiple formats (JWK, Multibase).
- Verification methods for signing/encryption.
- Standard key agreement and assertion relationships. This deterministic generation ensures the document is always consistent and tamper-proof.
03
Simple Syntax & Encoding
The identifier follows the pattern did:key:<multibase-encoded-public-key>. It uses Multibase and Multicodec prefixes to indicate the key type and encoding. For example, a P-256 key starts with zDn while an Ed25519 key starts with z6Mk. This structure is defined in the W3C DID Core specification.
EXPLORE
04
Limited to Known Key Pairs
A did:key can only represent a single, static key pair. It cannot:
- Be updated or rotated (a new DID must be created).
- Include arbitrary service endpoints or custom attributes in its core document.
- Be revoked through the method itself. This simplicity makes it ideal for ephemeral or static contexts but not for long-term, mutable identity.
05
Primary Use Cases
did:key is optimally used in scenarios requiring lightweight, verifiable identifiers without infrastructure overhead:
- Peer-to-peer communication (e.g., DIDComm).
- Static verifiable credentials issuance and presentation.
- Developer testing and prototyping of DID-based systems.
- Embedded identities in documents or devices with limited connectivity.
06
Cryptographic Agility
The method supports multiple cryptographic suites through the Multicodec prefix. Common supported key types include:
- Ed25519 (EdDSA)
- secp256k1 (used by Bitcoin/Ethereum)
- P-256 (ES256, widely used in WebAuthn)
- X25519 for key agreement. The prefix allows resolvers to identify the algorithm and process the key correctly.
examples
DID:KEY IN PRACTICE
Examples and Use Cases
The did:key method is a lightweight, self-contained Decentralized Identifier (DID) used for cryptographic operations and simple identity proofs. These examples illustrate its practical applications.
01
Secure, Self-Issued Credentials
A user can create a did:key and use it to issue a Verifiable Credential to themselves, such as a proof of age or membership. This credential is signed with the DID's private key and can be presented to verifiers without relying on a central registry. This is foundational for self-sovereign identity models.
- Example:
did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doKissues a credential asserting the holder is over 21.
02
Encrypted Peer-to-Peer Messaging
did:key DIDs contain the public key material, enabling asymmetric encryption. Applications can use the keyAgreement verification method from a did:key document to establish an encrypted channel.
- Process: Alice shares her
did:key. Bob extracts her public encryption key from the DID Document and uses it to encrypt a message that only Alice's private key can decrypt. - Use Case: Secure messaging in decentralized applications (dApps) or wallets.
03
Signing and Verifying Data
The primary use is cryptographic signing. A did:key provides a persistent identifier for a public key, allowing any data signed by the corresponding private key to be verified.
- Example in Code: Signing a JSON Web Token (JWT) or a Verifiable Presentation.
- Workflow:
- Entity signs a payload with its private key.
- Verifier resolves the
did:keyto get the public key. - Verifier checks the signature against the public key.
04
Decentralized Web Node (DWN) Authentication
In the Decentralized Web Platform, did:key is used as a simple, local identity to authenticate with a Decentralized Web Node (DWN). The DID serves as the node's identifier, and requests are signed with its keys, providing secure, permissioned access to personal data stores without a blockchain.
05
Development & Testing
did:key is ideal for prototyping and testing Verifiable Credentials or DID-based systems because it requires no network resolution or ledger writes. Developers can generate DIDs instantly for unit tests, demos, and sandbox environments, avoiding the complexity and cost of blockchain-based DID methods during early development.
06
Contrast with `did:ethr` & `did:web`
Understanding did:key is easier by comparison:
- vs.
did:ethr:did:keyis off-chain and static; its document is derived from the key itself.did:ethris an on-chain, updatable DID anchored to the Ethereum blockchain. - vs.
did:web:did:keyis self-contained.did:webresolves over HTTPS to a document hosted on a web server, introducing a dependency on that server's availability.
COMPARISON
did:key vs. Other DID Methods
A technical comparison of the did:key method's characteristics against common properties of other Decentralized Identifier (DID) methods.
| Feature | did:key | did:ethr / did:ion | did:web |
|---|---|---|---|
Method Specification | W3C DID Specification Registries | Ledger-specific (e.g., Ethereum, Bitcoin) | W3C DID Specification Registries |
Underlying Registry / Ledger | None (self-contained) | Public Blockchain (e.g., Ethereum) | Web Domain (HTTPS) |
DID Document Resolution | Local derivation from public key | On-chain lookup or side-tree (ION) | HTTP(S) fetch from well-known URI |
DID Document Updates | |||
Cryptographic Agility | |||
Verifiable Capability (zCap) Support | |||
Production Readiness for Static Identifiers | |||
Typical Use Case | Static peer-to-peer connections, testing | Blockchain-anchored identities, DApps | Domain-verifiable organizational identities |
security-considerations
DID:KEY
Security Considerations
While the did:key method offers a simple, self-contained Decentralized Identifier (DID), its design imposes specific security trade-offs that developers and architects must evaluate.
01
Key Rotation Limitation
The primary security limitation of did:key is the inability to rotate cryptographic keys without changing the DID itself. The DID is a direct, immutable encoding of the public key. If a private key is compromised, the entire identifier must be retired, breaking all existing references and verifiable credentials. This makes it unsuitable for long-lived identities where key lifecycle management is critical.
02
No Revocation Mechanism
There is no built-in mechanism to revoke a did:key or credentials issued to it. Unlike methods tied to verifiable data registries (e.g., did:ethr), there is no on-chain transaction or registry update to signal that a DID is no longer valid. Verification of a did:key only checks the cryptographic proof, not its current authorization status, which can be a problem for credential lifecycle management.
03
DID Document Integrity
A did:key DID Document is generated algorithmically from the public key, not fetched from a mutable registry. This guarantees integrity and availability, as the document can be derived locally by any verifier. However, it also means the document cannot contain dynamic elements like service endpoints for revocation lists or key updates, limiting its functional scope compared to other DID methods.
04
Cryptographic Agility & Future-Proofing
The chosen cryptographic suite (e.g., Ed25519, secp256k1) is permanently embedded in the DID's multicodec prefix. If the underlying algorithm becomes weak (e.g., due to quantum computing advances), the DID cannot be upgraded to a new algorithm. This lack of cryptographic agility requires careful selection of a future-resistant algorithm at creation time.
05
Appropriate Use Cases
Given its constraints, did:key is secure and ideal for specific scenarios:
- Ephemeral interactions (e.g., single-session authentication).
- Static, self-contained credentials with a short validity period.
- Developer testing and prototyping of Verifiable Credentials.
- Embedded identifiers in devices or documents where no registry is available. It is not recommended for long-term, enterprise-grade digital identity systems.
06
Verification & Trust
Trust in a did:key is purely cryptographic, not institutional. A verifier can cryptographically prove a signature is valid for that specific DID, but they gain no additional context about the holder's real-world identity or reputation. Establishing higher-level trust requires out-of-band processes or linking the did:key to a verifiable credential from a trusted issuer using a more capable DID method.
DID:KEY
Common Misconceptions
Decentralized Identifiers (DIDs) are a core component of Web3 identity, and the did:key method is a foundational format. However, its simplicity often leads to misunderstandings about its capabilities, limitations, and role in the broader identity ecosystem.
No, did:key is not a complete self-sovereign identity (SSI) solution; it is a foundational cryptographic identifier format. A did:key is generated directly from a public key, creating a simple, self-contained DID document. However, true SSI requires a verifiable data registry (like a blockchain or a distributed ledger) for key rotation, service endpoint updates, and revocation. Since a did:key is static and cannot be updated once created, it lacks these essential lifecycle management features required for long-lived, resilient identities.
Key Limitation: If the corresponding private key is compromised, the entire did:key identifier becomes unusable and cannot be recovered or rotated. For production SSI systems, methods like did:ethr (Ethereum) or did:ion (Bitcoin/Sidetree) are used, as they anchor DID Documents to a blockchain, enabling updates and management.
DID:KEY
Technical Details
A deep dive into the `did:key` method, a foundational standard for decentralized identifiers (DIDs) that enables self-sovereign identity without relying on a central registry or blockchain.
A did:key is a decentralized identifier (DID) method that encodes a public cryptographic key directly into the DID itself, creating a self-contained, resolvable identifier without requiring an external registry or blockchain. It works by taking a raw public key (e.g., Ed25519, secp256k1) and performing a multibase and multicodec encoding to produce a compact, URL-safe string. The resulting DID, such as did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK, can be resolved locally by any party to obtain the public key material and associated DID Document, enabling immediate cryptographic verification. This makes did:key ideal for peer-to-peer interactions, static configurations, and testing, as it eliminates network latency and dependency on a live resolver service.
ecosystem-usage
DID:KEY
Ecosystem Usage
did:key is a lightweight, self-contained Decentralized Identifier (DID) method that encodes a public key directly into the DID itself, enabling simple cryptographic operations without a blockchain or external resolver.
01
Verifiable Credentials & Presentations
did:key is a foundational component for Verifiable Credentials (VCs) and Verifiable Presentations (VPs). It provides the cryptographic anchor for signing and verifying claims.
- Issuance: An issuer signs a credential with the private key corresponding to their
did:key. - Verification: A verifier uses the public key embedded in the
did:keyto cryptographically verify the signature's authenticity. - Example: A university issues a digital diploma (a VC) signed with its
did:key, which a graduate can then present to an employer.
02
Decentralized Web (DWeb) & DID-Auth
In the Decentralized Web, did:key enables secure, passwordless authentication. It's used in protocols like DID Auth and Sign-In with Ethereum (SIWE) variants.
- Authentication Flow: A user proves control of a
did:keyby signing a challenge with their private key. - Session Keys: Can be used to generate ephemeral
did:keyidentifiers for secure, temporary sessions. - Resource Access: Grants access to decentralized storage (e.g., IPFS) or compute resources by proving key ownership.
03
Secure Messaging & DIDComm
did:key is a core identifier type for DIDComm, a secure, peer-to-peer messaging protocol built for decentralized identity.
- Peer DIDs: Many DIDComm implementations use a
did:keyvariant calleddid:peerfor private relationships. - Encryption: The public key in a
did:keyis used to encrypt messages specifically for that identifier's controller. - Agent Communication: Enables wallets, agents, and services to establish encrypted, authenticated channels without pre-shared secrets.
05
Key Management & Wallet Integration
did:key identifiers are natively managed by digital identity wallets and key management systems (KMS).
- Wallet Creation: Wallets like Spruce ID, Trinsic, and Bloom generate and store the private keys for
did:keyDIDs. - Key Agility: Wallets can manage multiple
did:keyidentifiers for different contexts (professional, personal, device-specific). - Hardware Security: Private keys for
did:keycan be secured in hardware security modules (HSMs) or secure enclaves, linking high-assurance hardware to a simple DID.
06
Limitations & Appropriate Use Cases
did:key is purpose-built for specific scenarios due to its simplicity and lacks features of stateful DID methods.
- Best For: Static relationships, offline verification, demo/prototyping, and ephemeral interactions.
- Key Limitation: No key rotation or revocation. If a private key is compromised, the DID becomes unusable.
- Not For: Long-lived public identities or scenarios requiring key updates, which need stateful methods like
did:ethrordid:ion.
DID:KEY
Frequently Asked Questions
A decentralized identifier (DID) method that encodes a public key directly into the identifier itself, providing a simple, self-contained mechanism for cryptographic verification.
A did:key is a Decentralized Identifier (DID) method where the identifier itself is a direct, encoded representation of a cryptographic public key. It works by taking a public key, applying a multibase and multicodec encoding, and prefixing it with the did:key: scheme (e.g., did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK). This creates a self-contained, resolvable DID where the DID Document can be algorithmically generated from the key material without needing a registry or blockchain, enabling immediate verification of signatures and key agreement protocols.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall