New Work Item Proposal: DID Key Recovery (DID-KR)
Link to Abstract or Draft
Abstract
This specification defines a standardized, interoperable mechanism for recovering control of Decentralized Identifiers (DIDs) when private keys are lost or compromised. It introduces three complementary recovery types — Social ZKP Recovery, Deterministic Seedling Inheritance, and MPC-based Mediated Recovery — each addressing different trust models and user personas.
The specification includes cryptographic hardening through mathematically correct Verifiable Secret Sharing (Feldman VSS over a proper prime-order group), Verifiable Delay Functions, Proactive Secret Refreshment, and comprehensive security considerations with a formal JSON-LD context for machine interoperability.
List Owners
- Lead: Amir Hameed Mir (@amir-hameed-mir)
- Co-editor: [Open for volunteers - seeking cross-organizational participation]
- Co-sponsor: @msporny (Digital Bazaar)
Work Item Questions
1. Explain what you are trying to do using no jargon or acronyms.
We are creating a standard way for people to recover control of their digital identity when they lose their private keys. Just as you can reset a password on a website, this specification gives people a way to regain access to their self-sovereign identity through trusted methods like friends, family, institutions, or backup systems—without relying on any central authority.
The specification supports three main approaches:
- Social recovery: Trusted guardians help you recover your identity using cryptographic proofs that keep your secrets safe
- Seed-based recovery: Recovery through a master password or phrase, with optional time-locked inheritance for passing identity to beneficiaries
- Enterprise recovery: Multi-party computation where multiple organizations help sign off on recovery without any single party holding the full key
2. How is it done today, and what are the limits of the current practice?
Currently, if you lose the private key for a decentralized identifier, your identity is permanently lost—along with any reputation, verifiable credentials, or relationships associated with it. This creates a critical barrier to adoption, as real users cannot risk losing access to their digital identity.
Some wallets offer proprietary backup solutions, but these are:
- Siloed: They only work within specific ecosystems
- Non-interoperable: Recovery methods cannot be discovered or used across different wallets
- Centralized: Often rely on cloud storage, undermining self-sovereignty
- Incomplete: Focus only on key backup, not the full identity context
Communities like Nostr have seen multiple competing proposals for key migration, none of which have converged. There is no standardized way to express recovery capabilities in a DID Document or execute recovery across different implementations.
3. What is new in your approach and why do you think it will be successful?
Our approach is mechanism-agnostic—it doesn't prescribe one specific cryptographic method but provides a standard structure for expressing recovery relationships in the DID Document itself. This allows multiple recovery mechanisms (social guardians, Shamir secret sharing, MPC, hardware backups, seed phrases) to coexist and interoperate.
Key innovations:
- Recovery verification relationship: A new property in DID Documents specifically designated for recovery
- Three complementary types: Covering individual, inheritance, and enterprise use cases
- Mathematically rigorous: Properly parameterized Feldman VSS with safe prime groups
- Privacy-preserving: Guardian anonymity, minimal metadata leakage
- Future-proof: Cryptographic agility for post-quantum transition
Why it will succeed:
- It addresses a real, urgent user need (evident from Nostr, did:method implementers, and enterprise interest)
- It builds on existing work rather than reinventing (Blockchain Commons libraries already in production wallets)
- It remains flexible enough to serve diverse use cases
- The CCG provides the right forum for cross-organizational collaboration
4. How are you involving participants from multiple skill sets and global locations in this work item?
Technical contributors:
- Blockchain Commons – production cryptographic implementations (SSKR, CSR, FROST)
- Digital Bazaar – DID specifications, JSON-LD expertise
- Nostr developers – real-world deployment experience, urgent recovery needs
- did:method implementers – diverse method requirements
Global representation:
- North America: Blockchain Commons, Digital Bazaar
- Europe: [Connections being established]
- Asia-Pacific: Outreach underway to communities with mobile-first identity needs
- Middle East: Sirraya Labs presence
Skill sets engaged:
- Cryptographic/technical: Core specification development, security reviews
- UX/product: Input from wallet developers and end-user communities
- Privacy/anthropological: Guardian privacy considerations, cultural attitudes toward trust and recovery
- Standards/legal: Compliance with emerging regulations, interoperability requirements
We welcome and actively seek broader participation from all regions and disciplines.
5. What actions are you taking to make this work item accessible to a non-technical audience?
We are committed to making this work understandable and relevant beyond technical audiences:
- Plain language documentation: User stories and real-world scenarios explaining recovery problems without jargon
- Visual guides: Diagrams illustrating recovery flows (included in the specification)
- Non-normative explanatory sections: The spec includes clear explanations alongside technical requirements
- Community engagement: Working with communities like Nostr where the human impact of key loss is immediate and visible
- Primers and educational materials: Planned development of introductory resources for wallet users and implementers
- Threat modeling in plain terms: Drawing from resources like Blockchain Commons' #SmartCustody to explain risks to non-experts
The goal is to ensure the specification remains grounded in real user needs and accessible to implementers, product managers, and end users alike.
We request creation of did-kr repo & adoption of DID-KR as a CCG work item and look forward to advancing this work with the community.
New Work Item Proposal: DID Key Recovery (DID-KR)
Link to Abstract or Draft
Abstract
This specification defines a standardized, interoperable mechanism for recovering control of Decentralized Identifiers (DIDs) when private keys are lost or compromised. It introduces three complementary recovery types — Social ZKP Recovery, Deterministic Seedling Inheritance, and MPC-based Mediated Recovery — each addressing different trust models and user personas.
The specification includes cryptographic hardening through mathematically correct Verifiable Secret Sharing (Feldman VSS over a proper prime-order group), Verifiable Delay Functions, Proactive Secret Refreshment, and comprehensive security considerations with a formal JSON-LD context for machine interoperability.
List Owners
Work Item Questions
1. Explain what you are trying to do using no jargon or acronyms.
We are creating a standard way for people to recover control of their digital identity when they lose their private keys. Just as you can reset a password on a website, this specification gives people a way to regain access to their self-sovereign identity through trusted methods like friends, family, institutions, or backup systems—without relying on any central authority.
The specification supports three main approaches:
2. How is it done today, and what are the limits of the current practice?
Currently, if you lose the private key for a decentralized identifier, your identity is permanently lost—along with any reputation, verifiable credentials, or relationships associated with it. This creates a critical barrier to adoption, as real users cannot risk losing access to their digital identity.
Some wallets offer proprietary backup solutions, but these are:
Communities like Nostr have seen multiple competing proposals for key migration, none of which have converged. There is no standardized way to express recovery capabilities in a DID Document or execute recovery across different implementations.
3. What is new in your approach and why do you think it will be successful?
Our approach is mechanism-agnostic—it doesn't prescribe one specific cryptographic method but provides a standard structure for expressing recovery relationships in the DID Document itself. This allows multiple recovery mechanisms (social guardians, Shamir secret sharing, MPC, hardware backups, seed phrases) to coexist and interoperate.
Key innovations:
Why it will succeed:
4. How are you involving participants from multiple skill sets and global locations in this work item?
Technical contributors:
Global representation:
Skill sets engaged:
We welcome and actively seek broader participation from all regions and disciplines.
5. What actions are you taking to make this work item accessible to a non-technical audience?
We are committed to making this work understandable and relevant beyond technical audiences:
The goal is to ensure the specification remains grounded in real user needs and accessible to implementers, product managers, and end users alike.
We request creation of did-kr repo & adoption of DID-KR as a CCG work item and look forward to advancing this work with the community.