did:key creates a decentralised identifier directly from a public key, so the DID can be resolved without a registry or network lookup. It is simple and self-contained, but the identifier changes if the key changes. Practitioners should use it only where key rotation, recovery, and long-term governance are understood.
What did:key is, and why it behaves differently from registry-backed DIDs
did:key is a method for turning a public key into a decentralised identifier without asking a registry, directory, or ledger to assign or resolve that identifier. The DID document is derived directly from the key material, which makes the mechanism compact and portable. That also means the identifier is not a stable human-friendly name, it is bound to the key itself.
The practical upside is simplicity. A verifier can resolve the DID from the key encoding alone, which reduces dependencies and removes infrastructure that can become unavailable or inconsistent. The trade-off is that key material becomes the root of identity continuity: if you replace the key, you change the DID, unless you design a higher-level identity layer around it.
How resolution works from the public key alone
did:key encodes the public key into the DID string, then reconstructs a minimal DID document from that encoded key. Because the method is self-contained, resolution does not depend on external discovery, name registration, or a lookup service. In practice, that makes it useful for cryptographic proof exchange where the verifying party already has the DID string and only needs to obtain the corresponding verification material.
This self-contained model is also why did:key is often described as “stateless”. There is no method-managed registry state to synchronise, no mutable record to query, and no shared namespace to administer. The verifier is trusting the cryptographic binding in the identifier itself, not an external authority that vouches for what the identifier points to.
Where did:key is strongest, and where it becomes fragile
did:key works best for short-lived, low-friction, or tightly controlled use cases where key continuity is easy to manage. It is weakest when the identifier needs to outlive the key, support routine rotation, or participate in governance processes that assume a persistent identifier with update control. If the key changes, the DID changes, so continuity has to be handled by application design rather than by the DID method.
That is why the main operational question is not “Can we generate a DID?” but “Can we tolerate identity churn when the key lifecycle changes?” If your use case needs recovery, revocation, delegation, or organisational ownership over time, you usually need an additional governance layer, such as external credential logic, policy, or a different DID method with update semantics. Verifiable Credentials Guide is the most useful starting point for seeing how DID choices interact with trust frameworks, status, and presentation flows. Digital Identity, eID and Identity Wallets Guide shows the broader wallet and credential context where identifier persistence matters more than the key encoding trick itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-57 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | did:key depends on stable key material, so key lifespan is central to continuity |
| Recommendation — Limit key lifetime and plan rotation before deploying did:key in persistent trust flows. | ||
| NIST SP 800-57 | NIST-800-57 — Key Management | The subject hinges on how key lifecycle affects identifier continuity and recovery |
| Recommendation — Define key generation, rotation, recovery, and destruction rules before binding identity to a key. | ||
| OWASP ASVS | V9 — Self-contained Tokens | did:key is a self-contained cryptographic representation whose trust depends on local validation |
| Recommendation — Validate the embedded key material and reject assumptions that require external resolution. | ||
Practitioner Guidance
What to verify: Confirm whether the DID only needs to authenticate a key-bound subject, or whether it also needs operational continuity across rotation, recovery, and organisational change. If continuity matters, did:key alone is usually too rigid for the lifecycle.
Decision rule: Use did:key when the simplest possible cryptographic identifier is the goal and the key is expected to remain stable for the life of the relationship. If you need recoverability, revocation paths, or long-term governance, treat did:key as a component, not the whole identity architecture.
Common mistake: Teams often treat “decentralised” as synonymous with “durable”. With did:key, decentralisation removes dependency on a registry, but it does not remove the operational burden of key protection, rollover planning, or lost-key handling.
Practitioner takeaway: did:key is excellent when you want resolution to be as simple as the key itself, but that same simplicity pushes lifecycle risk onto you, so choose it only when key change and identity continuity are deliberately solved elsewhere.