DID Key Recovery (DID-KR)

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.

Status of This Document

This is the Editors Draft prepared by Amir Hameed Mir of Sirraya Labs. This document defines the normative requirements for DID Key Recovery implementations.

1. Introduction

The Decentralized Identifier (DID) architecture provides the foundation for self-sovereign identity but deliberately omits key recovery mechanisms, leaving implementers to develop ad-hoc, non-interoperable solutions. This gap represents a critical barrier to mass adoption, as users face permanent loss of identity or vendor lock-in when keys are lost.

The DID Key Recovery Extension (DID-KR) addresses this gap by defining standardized recovery methods that can be published in DID Documents, discovered by resolvers, and executed through interoperable protocols. The specification embraces a "three-way solution" recognizing that no single recovery model suits all use cases:

• Type A (Social ZKP Recovery): For users prioritizing autonomy, using threshold cryptography with zero-knowledge proofs to prevent guardian collusion.
• Type B (Deterministic Seedling): For inheritance and migration, using hierarchical deterministic keys with Verifiable Delay Functions for decentralized time-locks.
• Type C (MPC-Mediated): For enterprise and convenience users, using multi-party computation with threshold signatures and proactive share refreshment.

1.1 Design Goals

• Non-Custodial: No single entity ever possesses the full private key.
• Interoperable: Recovery methods are discoverable and executable across different wallet implementations.
• Privacy-Preserving: Recovery metadata minimizes leakage of social graphs and security posture.
• Mathematically Sound: All cryptographic constructions use correctly parameterized groups with proven security properties.
• Future-Proof: Cryptographic agility allows migration to quantum-resistant algorithms.

1.2 Relationship to DID Core

This specification extends DID Core by defining:

1. A new recovery verification relationship.
2. Three new verification method types for recovery.
3. Service endpoint definitions for recovery protocols.
4. A JSON-LD context for machine-readable discovery.

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

DID Controller

The entity authorized to make changes to a DID Document.

Recovery Method

A verification method specifically designated for recovering control of a DID.

Guardian

An entity holding a share of a recovery secret in Type A schemes.

Beneficiary

An entity authorized to inherit a DID in Type B schemes.

Provider

An MPC node participating in threshold signature generation for Type C schemes.

Threshold (t)

The minimum number of shares/participants required to complete recovery.

Scalar Field Z_q

A prime field of order q used for polynomial arithmetic in VSS. All share values and polynomial coefficients live in Z_q.

Commitment Group Z_p*

The multiplicative group modulo a prime p used for Feldman commitments. Distinct from the scalar field; chosen so that q divides (p−1).

Safe Prime

A prime p such that p = 2q+1 and q is also prime. Used to guarantee a subgroup of prime order q in Z_p*.

Share Refreshment

The process of generating new secret shares without changing the secret or the public commitments, achieved by adding shares of a zero-secret refresh polynomial.

Verifiable Delay Function (VDF)

A function requiring a specific amount of sequential computation to evaluate.

Epoch

A version identifier for MPC provider share sets, incremented with each refreshment.

Catch-up Protocol

A mechanism for synchronizing lagging MPC providers to the current epoch.

4. The Recovery Method Architecture

The DID-KR architecture introduces a new verification relationship recovery in the DID Document. This relationship contains one or more recovery methods that define how a DID can be recovered.

4.1 Discovery Model

Recovery methods are discovered through standard DID resolution. A resolver or wallet implementing DID-KR:

1. Resolves the DID Document.
2. Checks for the @context including the DID-KR context.
3. Extracts the recovery verification relationship.
4. Parses the recovery methods according to their type.

4.2 Lifecycle

1. Setup: The DID Controller generates recovery parameters and publishes them in the DID Document.
2. Execution: When recovery is needed, the recovering party initiates the protocol defined by the recovery method.
3. Completion: Upon successful recovery, the DID Document is updated with new verification methods, and the recovery methods may be rotated.
4. Revocation: Recovery methods can be revoked by the current controller using an active verification method.

5. Recovery Method Types

{
  "id": "did:example:123#recovery-social",
  "type": "RecoveryMethodZKPSocial",
  "controller": "did:example:123",
  "recoveryThreshold": 3,
  "vssScheme": "feldman-safe-prime-256-2025",
  "vssGroupParameters": {
    "p": "0x50179e4375e428b3af8fe52af1f2a50e5100b916d0d1c1bbedc304c3d35f3217",
    "q": "0x280bcf21baf21459d7c7f29578f9528728805c8b6868e0ddf6e18261e9af990b",
    "g": "4"
  },
  "vssCommitments": [
    "0x2a3f...",
    "0x7c91..."
  ],
  "recoveryGuardians": [
    {
      "id": "did:guardian:abc#key-1",
      "guardianEndpoint": "https://guardian1.example.com/recover",
      "guardianType": "person",
      "commitmentIndex": 0
    }
  ],
  "curve": "safe-prime-256"
}

{
  "id": "did:example:123#recovery-seedling",
  "type": "RecoveryMethodDeterministic",
  "controller": "did:example:123",
  "seedDerivationPath": "m/44'/0'/0'/0/0",
  "derivationStandard": "bip32-ed25519",
  "encryptedSeedLockbox": {
    "ciphertext": "0x7b3a...f9c2",
    "algorithm": "XChaCha20-Poly1305",
    "iv": "0x1a2b...3c4d",
    "beneficiaryPublicKey": "did:beneficiary:abc#key-1",
    "beneficiaryKeyType": "x25519"
  },
  "deadMansSwitch": {
    "type": "VDFTimeLock",
    "vdfParameters": {
      "difficulty": 1000000,
      "estimatedWallTime": "P30D",
      "referencePlatform": "intel-i9-13900k-2024",
      "tolerance": 0.2,
      "modulus": "0x8f3b...a1c4",
      "challenge": "0x2d4e...f8a1",
      "vdfAlgorithm": "wesolowski-2024"
    },
    "inactivityPeriod": "P1Y"
  }
}

{
  "id": "did:example:123#recovery-mpc",
  "type": "RecoveryMethodMPC",
  "controller": "did:example:123",
  "mpcThreshold": 2,
  "mpcTotalProviders": 3,
  "mpcProtocol": "fROST-ed25519-2024",
  "mpcProviders": [
    {
      "id": "did:provider:one#mpc-node",
      "endpoint": "https://provider1.example.com/mpc",
      "authType": "vc-presentation"
    }
  ],
  "shareRotation": {
    "rotationInterval": "P30D",
    "currentEpoch": 42,
    "lastRotationProof": "0x8a3c...f2b5"
  }
}

"shareRotation": {
  "rotationInterval": "P30D",
  "currentEpoch": 42,
  "providerStateEndpoint": "https://provider1.example.com/state",
  "lastRotationProof": "0x8a3c...f2b5",
  "synchronization": {
    "maxEpochSkew": 1,
    "catchupProtocol": "vss-refresh-verifiable-2025",
    "timeout": "PT30S",
    "requiredQuorum": 2
  }
}

6. Verification Relationships

6.1 The recovery Relationship

The recovery verification relationship indicates that the associated verification methods are specifically authorized for recovering control of the DID. These methods are limited to recovery operations and MUST NOT be used for general authentication.

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://sirraya.org/ns/did/recovery/v1"
  ],
  "id": "did:example:123",
  "recovery": [
    "did:example:123#recovery-social",
    "did:example:123#recovery-seedling",
    "did:example:123#recovery-mpc"
  ]
}

6.2 Processing Rules

1. The resolver MUST verify that the recovery method is listed in the recovery relationship.
2. The resolver MUST verify that the recovery method's controller is authorized to modify the DID Document.
3. The resolver MUST perform dependency checking to prevent recovery loops (see §8.4).

7. Cryptographic Primitives

"vdfParameters": {
  "difficulty": 1000000,
  "estimatedWallTime": "P30D",
  "referencePlatform": "intel-i9-13900k-2024",
  "tolerance": 0.2,
  "verificationMode": "wesolowski-optimistic"
}

8. Security Considerations

8.1 Guardian Collusion (Type A)

Threat: A threshold of guardians collude to reconstruct the user's private key.

Mitigation: Feldman VSS with Pedersen commitments ensures shares are individually verifiable. Guardians SHOULD be selected from diverse trust domains, and threshold SHOULD be ≥ 3-of-5.

DID-TM Mapping: This threat is classified as E — Privilege Escalation and K (K2 — Share Lifecycle Failure). Full analysis in DID-TM-ATK-400 (Guardian Collusion at Threshold). Normative mitigations: REQ-400, REQ-401, REQ-402, REQ-403.

8.2 Time-Lock Bypass (Type B)

Threat: An attacker compromises the dead man's switch to release inheritance keys prematurely.

Mitigation: VDFs provide computational asymmetry that cannot be parallelized, making premature release computationally infeasible within the specified time window.

DID-TM Mapping: This threat is classified as K (K3 — Time-Lock Integrity Failure). Full analysis in DID-TM-ATK-402 (VDF Difficulty Miscalibration) and DID-TM-ATK-431 (Wesolowski Proof Forgery). Normative mitigations: REQ-408, REQ-409, REQ-410, REQ-411, REQ-442, REQ-443, REQ-444.

8.3 Provider State Drift (Type C)

Threat: MPC providers update shares independently, causing key desynchronization.

Mitigation: Proactive Secret Sharing with verifiable refresh transcripts (§7.1.4) ensures consistency. The catch-up protocol (§5.4.3) handles epoch lag.

DID-TM Mapping: This threat is classified as K (K2 — Share Lifecycle Failure) and D — Denial of Service. Full analysis in DID-TM-ATK-401 (MPC Epoch Share Drift). Normative mitigations: REQ-404, REQ-405, REQ-406, REQ-407.

8.4 Recovery-Loop Prevention

Threat: Circular recovery dependencies make recovery impossible.

Mitigation: Implementations MUST validate that the dependency graph of recovery methods is acyclic at publication time, at recovery initiation, and during periodic health checks.

DID-TM Mapping: This threat is classified as D — Denial of Service and K (K6 — Inheritance and Recovery Chain Failure). Full analysis in DID-TM-ATK-404 (Recovery Loop Deadlock). Normative mitigations: REQ-415, REQ-416, REQ-417.

8.5 Key Wrapping Security

Threat: Weak encryption of seed lockboxes.

Mitigation: All encrypted payloads MUST use AEAD with ≥ 256-bit keys. XChaCha20-Poly1305 or AES-256-GCM are REQUIRED. The algorithm MUST be explicitly named in the DID Document.

DID-TM Mapping: This threat is classified under I — Information Disclosure and K (K1 — Key Ceremony Failure). Refer to DID-TM §22 (Side-Channel and Implementation Threats) for cryptographic implementation requirements. Normative mitigations: REQ-460, REQ-461.

8.6 Quantum Computing Resistance

Current algorithms are secure against classical computers. Implementations SHOULD plan transition paths:

• Type A: Consider lattice-based VSS for post-quantum security.
• Type B: Use hash-based signatures for seed commitment.
• Type C: Transition to threshold lattice signatures when standardized.

DID-TM Mapping: This threat is classified as K (K5 — Post-Quantum Migration Failure). Full analysis in DID-TM §23 (Post-Quantum Threat Model), including Harvest-Now Decrypt-Later attacks and migration dependency analysis. Normative mitigations: REQ-470, REQ-471.

9. Privacy Considerations

9.1 Metadata Leakage

Recovery methods may expose social graph (guardian identities), security posture (threshold values), and activity patterns. Mitigations include encrypted DID Document entries, guardian anonymity via onion services, and minimum-disclosure design.

DID-TM Mapping: This threat falls under I — Information Disclosure and LINDDUN-DID's Linkability and Detectability categories. Refer to DID-TM-ATK-501 (Cross-DID Correlation via Resolver Logs) and PRI-301 (hashed guardian identifiers).

9.2 Guardian Privacy

Instead of full DIDs, implementations SHOULD publish salted hashes:

"recoveryGuardians": [
        {
            "id": "urn:hash:sha256:3a7b...c9f2",
            "salt": "0x4d8e...f2a3",
            "guardianEndpoint": "http://guardian1.onion/recover",
            "commitmentIndex": 0
        }
        ]

DID-TM Mapping: This mitigation corresponds to DID-TM PRI-301 (Recovery method representations MUST use hashed or pseudonymous guardian identifiers).

9.3 Correlation Risk

The same recovery method across multiple DIDs could correlate them. DID controllers SHOULD use different guardian sets, salt values, and encryption keys per DID.

DID-TM Mapping: This threat is addressed by DID-TM PRI-200 (pairwise DIDs) and PRI-201 (ZKP unlinkability). Refer to DID-TM §25.2 for complete unlinkability requirements.

9.4 Beneficiary Privacy

Beneficiaries SHOULD use single-use derived keys specific to each inheritance relationship, not linked to their primary identity.

DID-TM Mapping: This aligns with DID-TM PRI-102 (data minimization) and PRI-302 (single-use credentials for sensitive attributes).

10. Interoperability Requirements

10.1 Mandatory-to-Implement Algorithms

10.2 Optional Algorithms

10.3 DID Method Compatibility

This specification is DID method agnostic but requires methods that support DID Document updates, resolution for recovery method discovery, and deactivation of compromised recovery methods.

11. JSON-LD Context

Available at: https://sirraya.org/ns/did/recovery/v1.jsonld

{
  "@context": {
    "@version": 1.1,
    "@protected": true,

    "id": "@id",
    "type": "@type",

    "RecoveryMethod": "https://sirraya.org/ns/did/recovery#RecoveryMethod",
    "RecoveryMethodZKPSocial": "https://sirraya.org/ns/did/recovery#RecoveryMethodZKPSocial",
    "RecoveryMethodDeterministic": "https://sirraya.org/ns/did/recovery#RecoveryMethodDeterministic",
    "RecoveryMethodMPC": "https://sirraya.org/ns/did/recovery#RecoveryMethodMPC",

    "recovery": {
      "@id": "https://sirraya.org/ns/did/recovery#recovery",
      "@type": "@id",
      "@container": "@set"
    },
    "recoveryThreshold": {
      "@id": "https://sirraya.org/ns/did/recovery#recoveryThreshold",
      "@type": "xsd:integer"
    },
    "vssGroupParameters": {
      "@id": "https://sirraya.org/ns/did/recovery#vssGroupParameters",
      "@type": "@id"
    },
    "vssScheme": {
      "@id": "https://sirraya.org/ns/did/recovery#vssScheme",
      "@type": "xsd:string"
    },
    "recoveryGuardians": {
      "@id": "https://sirraya.org/ns/did/recovery#recoveryGuardians",
      "@type": "@id",
      "@container": "@set"
    },
    "guardianEndpoint": {
      "@id": "https://sirraya.org/ns/did/recovery#guardianEndpoint",
      "@type": "xsd:anyURI"
    },
    "vssCommitments": {
      "@id": "https://sirraya.org/ns/did/recovery#vssCommitments",
      "@type": "xsd:string",
      "@container": "@list"
    },
    "seedDerivationPath": {
      "@id": "https://sirraya.org/ns/did/recovery#seedDerivationPath",
      "@type": "xsd:string"
    },
    "encryptedSeedLockbox": {
      "@id": "https://sirraya.org/ns/did/recovery#encryptedSeedLockbox",
      "@type": "@id"
    },
    "deadMansSwitch": {
      "@id": "https://sirraya.org/ns/did/recovery#deadMansSwitch",
      "@type": "@id"
    },
    "vdfParameters": {
      "@id": "https://sirraya.org/ns/did/recovery#vdfParameters",
      "@type": "@id"
    },
    "mpcThreshold": {
      "@id": "https://sirraya.org/ns/did/recovery#mpcThreshold",
      "@type": "xsd:integer"
    },
    "mpcProviders": {
      "@id": "https://sirraya.org/ns/did/recovery#mpcProviders",
      "@type": "@id",
      "@container": "@set"
    },
    "shareRotation": {
      "@id": "https://sirraya.org/ns/did/recovery#shareRotation",
      "@type": "@id"
    },
    "currentEpoch": {
      "@id": "https://sirraya.org/ns/did/recovery#currentEpoch",
      "@type": "xsd:integer"
    },
    "synchronization": {
      "@id": "https://sirraya.org/ns/did/recovery#synchronization",
      "@type": "@id"
    },
    "maxEpochSkew": {
      "@id": "https://sirraya.org/ns/did/recovery#maxEpochSkew",
      "@type": "xsd:integer"
    },
    "catchupProtocol": {
      "@id": "https://sirraya.org/ns/did/recovery#catchupProtocol",
      "@type": "xsd:string"
    }
  }
}

12. Recovery Protocol Flows

12.1 Type A Recovery Protocol

Request:

POST /recover HTTP/1.1
Host: guardian1.example.com
Content-Type: application/json

{
  "protocol": "did-kr-recovery-v1",
  "recoveryId": "did:example:123#recovery-social",
  "did": "did:example:123",
  "nonce": "a1b2c3d4e5f6...",
  "challenge": "0x4d5e6f7a8b9c...",
  "commitmentIndex": 0
}

Response:

{
  "status": "success",
  "proof": {
    "type": "schnorr-proof-2025",
    "commitment": "0x8f3a2b1c...",
    "challenge": "0x4d5e6f7a...",
    "response": "0x2b7c8d9e..."
  },
  "guardianId": "did:guardian:abc#key-1",
  "signature": "0x9a8b7c6d..."
}

12.2 Type B Recovery Protocol

Self-recovery:

POST /recover/seed HTTP/1.1
Host: wallet.example.com
Content-Type: application/json

{
  "protocol": "did-kr-recovery-v1",
  "recoveryId": "did:example:123#recovery-seedling",
  "seedPhrase": "abandon ability able about above ...",
  "derivationPath": "m/44'/0'/0'/0/0"
}

12.3 Type C Recovery Protocol

Phase 1: Authentication Response

{
  "status": "authenticated",
  "provider": "did:provider:one#mpc-node",
  "currentEpoch": 42,
  "lastRotation": "2024-05-15T10:30:00Z",
  "signature": "0x9a8b7c6d..."
}

Phase 2: MPC Signing Ceremony

POST /mpc/sign HTTP/1.1
Host: provider1.example.com
Content-Type: application/json

{
  "protocol": "did-kr-recovery-v1",
  "sessionId": "sess_abc123def456",
  "operation": {
    "type": "update-did",
    "newDocument": { "id": "did:example:123", "..." : "..." }
  },
  "commitment": "0x3e4f5a6b..."
}

13. Test Vectors

13.1 Type A Test Vector — Feldman VSS

Group parameters: (p, q, g) as in §7.0.

Setup:

• Secret: s = 42 (as a scalar in Z_q)
• Threshold: t = 2
• Total shares: n = 3
• Polynomial: P(x) = 42 + 17·x (over Z_q)

Shares (computed as P(i) mod q):

Commitments (computed as gaj mod p):

Share verification example for s₃ (x=3):

Recovery with shares s₁, s₂ (Lagrange in Z_q):

13.2 Type A Test Vector — Proactive Refresh

Continuing from §13.1 — applying a refresh polynomial R(x) = 5·x (R(0)=0):

13.3 Type B Test Vector

Master Seed: 0x7f3a9b8c2d5e1f4a3b6c7d8e9f0a1b2c

Derivation Path: m/44'/0'/0'/0/0

PBKDF2 salt: "did-kr-salt:did:example:123" (UTF-8), 100,000 iterations

Derived Private Key: SHA-256(PBKDF2(seed, salt, 100000, 32))

13.4 Type C Test Vector

fROST t=2, n=3 — share format (illustrative, not actual key material):

Group Public Key: 0x3a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d...
Share 1 (epoch 1): 0x8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f...
Share 2 (epoch 1): 0x2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e...
Share 3 (epoch 1): 0x7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c...

14. References

14.1 Normative References

[DID-CORE]

Decentralized Identifier Specification v1.0

[RFC2119]

Key words for use in RFCs

[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC2119

[BIP32]

Hierarchical Deterministic Wallets

[BIP39]

Mnemonic code for generating deterministic keys

[FROST]

Flexible Round-Optimized Schnorr Threshold Signatures

[VDF]

Verifiable Delay Functions — Boneh et al., 2018

[FELDMAN]

Feldman's Verifiable Secret Sharing — Feldman, 1987

[SAFE-PRIME]

Safe prime group parameter generation — NIST SP 800-57

14.2 Informative References

[SOCIAL-RECOVERY]

Social Key Recovery for Self-Sovereign Identity

[MPC-WALLET]

Threshold Signatures for Cryptographic Wallets

[TIME-LOCK]

Time-Lock Encryption with Verifiable Delay Functions

[ZKP-AUTH]

Zero-Knowledge Proofs for Authentication

[PROACTIVE]

Proactive Secret Sharing — Herzberg et al., 1995

15. Acknowledgements

The editor would like to thank the members of the decentralized identity community for their valuable feedback and contributions. Special thanks to the cryptographic reviewers who validated the group parameters, the privacy researchers who contributed to guardian privacy enhancements, and the implementers who provided integration feedback.

Appendices

Appendix A: Implementation Checklist