DID Key Recovery 1.0

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.

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.

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.

Relationship to DID Core

This specification extends DID Core by defining:

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

Terminology

Some terminology used throughout this document is defined in the Terminology section of the [[[DID]]] specification. This section defines additional terms used throughout this specification.

Beneficiary: An entity authorized to inherit a DID in Type B schemes. The beneficiary is typically designated by the DID controller during setup and receives the ability to claim control of the DID after a specified time period or event, such as prolonged inactivity of the original controller.
Catch-up Protocol: A mechanism for synchronizing lagging MPC providers to the current [=epoch=]. The protocol enables providers that have missed share refreshment cycles to obtain verifiable refresh transcripts and update their shares without compromising the security of the underlying secret.
Commitment Group: The multiplicative group modulo a prime p, denoted Z_p*, used for Feldman commitments. This group is distinct from the [=scalar field=] and is chosen such that q divides (p−1), ensuring a subgroup of prime order q exists. All commitment operations are performed in this group.
Epoch: A version identifier for MPC provider share sets, incremented with each [=share refreshment=] operation. Epochs enable detection of state drift and provide a mechanism for synchronizing providers through the [=catch-up protocol=]. The current epoch value is published in the DID Document as part of the share rotation metadata.
Guardian: An entity holding a share of a recovery secret in Type A schemes. Guardians are trusted individuals or organizations selected by the DID controller to participate in the recovery process. A [=threshold=] of guardians must cooperate to reconstruct the recovery secret, with each guardian proving knowledge of their share through zero-knowledge proofs without revealing the share itself.
Provider: An MPC node participating in [=threshold=] signature generation for Type C schemes. Providers collectively hold shares of a secret key and perform distributed signing operations without any single provider reconstructing the full private key. Providers MAY be operated by independent entities to increase security and reduce trust requirements.
Recovery Method: A verification method specifically designated for recovering control of a DID. Recovery methods are published in the DID Document under the recovery verification relationship and define the protocol, parameters, and participants necessary to perform recovery operations. These methods MUST NOT be used for general authentication or assertion purposes.
Safe Prime: A prime p such that p = 2q+1 and q is also prime. Safe primes are used to guarantee the existence of a subgroup of prime order q in Z_p*. The use of safe primes ensures that the order of any element g (other than 1 and p−1) is either q or 2q, enabling selection of a generator g with order exactly q for cryptographic operations.
Scalar Field: A prime field of order q, denoted Z_q, used for polynomial arithmetic in Verifiable Secret Sharing (VSS). All share values, polynomial coefficients, and Lagrange interpolation operations are performed in this field. The field order q MUST be prime and MUST satisfy the condition that q divides (p−1) where p is the [=commitment group=] modulus.
Share Refreshment: The process of generating new secret shares without changing the secret or the public commitments. Share refreshment is achieved by adding shares of a zero-secret refresh polynomial to existing shares, effectively re-randomizing the share distribution. This process, also known as proactive secret sharing, limits the exposure window for compromised shares and enables recovery from share leakage without changing the underlying secret.
Threshold: The minimum number of shares or participants required to complete recovery. In Type A schemes, threshold (t) represents the number of guardians whose shares must be combined to reconstruct the recovery secret. In Type C schemes, threshold represents the minimum number of MPC providers that must participate to generate a valid threshold signature. The threshold MUST be less than or equal to the total number of participants (n) and is typically set to a value that balances security against availability requirements.
Verifiable Delay Function: A function requiring a specific amount of sequential computation to evaluate, while producing a proof that can be verified efficiently. Verifiable Delay Functions (VDFs) are used in Type B schemes to create decentralized time-locks, ensuring that inheritance keys cannot be released before a specified time period has elapsed, regardless of available parallel computing resources.
Verifiable Secret Sharing: A method for distributing a secret among a group of participants such that each participant receives a share, and a [=threshold=] number of shares is required to reconstruct the secret. Feldman's VSS provides the additional property that participants can verify that their shares are consistent with public commitments, detecting dishonest dealers without revealing the shares themselves.

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.

Discovery Model

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

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

Lifecycle

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

Recovery Method Types

Type A: Social ZKP Recovery

Type URI: RecoveryMethodZKPSocial

The Social ZKP Recovery mechanism enables recovery through a [=threshold=] of trusted [=guardians=] without revealing secret shares to any party, including the guardians themselves. Implementations MUST use Feldman's Verifiable Secret Sharing (VSS) with zero-knowledge proofs for share verification.

Cryptographic Requirements

Verifiable Secret Sharing (VSS): Feldman's VSS using safe-prime group parameters.
Zero-Knowledge Proofs: Schnorr proofs of share consistency.
Group: The 256-bit safe-prime group (p, q, g) defined in §Cryptographic Primitives.

Setup Phase

Generates a random secret s ∈ Z_q (the recovery key).
Constructs a random polynomial P(x) of degree t−1 over Z_q where P(0) = s.
Computes shares s_i = P(i) mod q for each of n guardians.
Computes Feldman commitments C_j = g^a_j mod p for each coefficient a_j.
Publishes commitments, guardian identifiers/endpoints, and [=threshold=] t in the DID Document.

Recovery Phase

Recovering party contacts t guardians.
Each guardian generates a Schnorr ZKP proving knowledge of share s_i consistent with commitments.
ZKPs are verified and shares are reconstructed using Lagrange interpolation in Z_q.
The reconstructed secret s is used to generate new DID keys.

DID Document Representation

{
  "id": "did:example:123#recovery-social",
  "type": "RecoveryMethodZKPSocial",
  "controller": "did:example:123",
  "recoveryThreshold": 3,
  "vssScheme": "feldman-safe-prime-256",
  "vssGroupParameters": {
    "p": "0x50179e4375e428b3af8fe52af1f2a50e5100b916d0d1c1bbedc304c3d35f3217",
    "q": "0x280bcf21baf21459d7c7f29578f9528728805c8b6868e0ddf6e18261e9af990b",
    "g": "4"
  },
  "vssCommitments": ["0x2a3f...", "0x7c91..."],
  "recoveryGuardians": [
    {
      "id": "urn:hash:sha256:3a7b...c9f2",
      "guardianEndpoint": "https://guardian1.example.com/recover",
      "commitmentIndex": 0
    }
  ]
}

Figure 1 — Type A: Social ZKP Recovery Flow

sequenceDiagram
    participant User as User (Recovering Party)
    participant G1 as Guardian 1
    participant G2 as Guardian 2
    participant G3 as Guardian 3
    User->>G1: Request recovery (nonce, commitments)
    User->>G2: Request recovery (nonce, commitments)
    User->>G3: Request recovery (nonce, commitments)
    G1-->>User: ZKP Proof
    G2-->>User: ZKP Proof
    G3-->>User: ZKP Proof
    User->>User: Verify ZKPs & reconstruct secret
    User->>User: Generate new DID keys

Type B: Deterministic Seedling Inheritance

Type URI: RecoveryMethodDeterministic

The Deterministic Seedling mechanism enables recovery through a master seed phrase, with optional time-locked inheritance for [=beneficiaries=] using [=Verifiable Delay Functions=] (VDFs).

Cryptographic Requirements

Hierarchical Deterministic Keys: BIP-32 or BIP-39 style derivation.
Encryption: XChaCha20-Poly1305 for seed lockbox.
Time-Locks: [=Verifiable Delay Functions=] (Wesolowski or Pietrzak).

{
  "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,
      "vdfAlgorithm": "wesolowski-2024"
    },
    "inactivityPeriod": "P1Y"
  }
}

Type C: MPC-Mediated Recovery

Type URI: RecoveryMethodMPC

The MPC-Mediated Recovery mechanism distributes key shares across multiple independent [=providers=] who perform [=threshold=] signatures without reconstructing the full key, using fROST (Flexible Round-Optimized Schnorr Threshold) signatures.

Cryptographic Requirements

Threshold Signatures: fROST (Flexible Round-Optimized Schnorr Threshold) signatures.
Proactive Secret Sharing: [=Share refreshment=] as specified in §Cryptographic Primitives.
Authentication: Verifiable Credentials or WebAuthn.
Transport: mTLS or Noise Protocol for secure provider communication.

{
  "id": "did:example:123#recovery-mpc",
  "type": "RecoveryMethodMPC",
  "controller": "did:example:123",
  "mpcThreshold": 2,
  "mpcTotalProviders": 3,
  "mpcProtocol": "fROST-ed25519",
  "mpcProviders": [
    {
      "id": "did:provider:one#mpc-node",
      "endpoint": "https://provider1.example.com/mpc",
      "authType": "vc-presentation"
    }
  ],
  "shareRotation": {
    "rotationInterval": "P30D",
    "currentEpoch": 42,
    "lastRotationProof": "0x8a3c...f2b5",
    "synchronization": {
      "maxEpochSkew": 1,
      "catchupProtocol": "vss-refresh-verifiable-2025",
      "timeout": "PT30S",
      "requiredQuorum": 2
    }
  }
}

Provider State Synchronization

When providers operate at different epochs, the recovery protocol MUST handle version skew. The [=catch-up protocol=] ensures lagging providers can synchronize:

Catch-up Request: Lagging provider sends a signed request to an up-to-date provider.
Verifiable Refresh Transcript: Responding provider returns the group public key plus verifiable transcript of each refresh operation.
Verification and Update: Lagging provider verifies each transcript and updates their local share.

Verification Relationships

The recovery verification relationship indicates that the associated [=recovery 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://w3c-ccg.github.io/did-recovery/context/v1"
  ],
  "id": "did:example:123",
  "recovery": [
    "did:example:123#recovery-social",
    "did:example:123#recovery-seedling",
    "did:example:123#recovery-mpc"
  ]
}

Processing Rules

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

Cryptographic Primitives

VSS Group Parameters

Feldman VSS verification requires the equation:

g s i \equiv \prod j=0 t-1 C j i j (mod p)

For this to hold consistently, exponents on both sides must reduce modulo the same value — the order of the generator g in the group. This requires:

A [=scalar field=] of prime order q for polynomial arithmetic.
A group prime p with q | (p−1), so that a subgroup of order exactly q exists.
A generator g of order exactly q in the [=commitment group=] Z_p*.

Implementations MUST use the following parameters, or an equivalent set verifiable by the same properties:

p0x50179e4375e428b3af8fe52af1f2a50e5100b916d0d1c1bbedc304c3d35f3217

q0x280bcf21baf21459d7c7f29578f9528728805c8b6868e0ddf6e18261e9af990b

bits256-bit [=safe prime=] (p = 2q+1)

Parameter verification MUST ensure:

isPrime(p) = True isPrime(q) = True p = 2\cdotq + 1 pow(g, q, p) = 1 pow(g, 1, p) \neq 1

Verifiable Secret Sharing (Feldman's VSS)

Let (p, q, g) be as defined above. All scalar operations are in Z_q. All commitment operations are in Z_p*.

Share Generation

Dealer chooses secret s ∈ Z_q and random coefficients a₁, …, a_t-1 ←_R Z_q.
Forms polynomial P(x) = s + a₁x + … + a_t-1x^t-1 over Z_q.
For participant i = 1…n, share s_i = P(i) mod q.
Computes Feldman commitments: C_j = g^a_j mod p for j = 0…t-1.

Share Verification

Participant i verifies their share by checking:

g s i \equiv \prod j=0 t-1 C j i j mod q (mod p)

Secret Recovery

Given t shares {(i, s_i)}, recover s = P(0) via Lagrange interpolation in Z_q:

s = \sum j s j \cdot L j (0) mod q L j (0) = \prod m\neqj (0 - x m) / (x j - x m) mod q

Proactive Share Refreshment

To re-randomize shares without changing the secret ([=share refreshment=]):

Generate refresh polynomial R(x) = r₁x + … + r_t-1x^t-1 over Z_q with R(0) = 0.
Compute refresh shares δ_i = R(i) mod q and refresh commitments D_j = g^r_j mod p.
Update shares: s_i^new = (s_i^old + δ_i) mod q.
Update commitments: C_j^new = C_j^old · D_j mod p.

Zero-Knowledge Proof of Share

To prove knowledge of share s_i ∈ Z_q without revealing it (Schnorr proof):

Prover chooses random r ← Z_q.
Prover sends R = g^r mod p.
Verifier sends challenge c ← Z_q.
Prover sends z = (r + c · s_i) mod q.
Verifier checks: g^z ≡ R · (∏ C_j^{i^j mod q})^c (mod p).

Verifiable Delay Function (Wesolowski)

Input: x ∈ QR(N), time parameter T
Output: y = x^{2^T} mod N, proof π

Compute y = x^{2^T} mod N via sequential squaring.
Let l = ⌊2^T / 2⌋, compute π = x^l mod N.
Verifier checks: π^{2^(T/2)} · x^{2^T mod 2^(T/2)} = y mod N.

Security Considerations

Guardian Collusion (Type A)

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

Mitigation: Feldman VSS with commitments ensures shares are individually verifiable. Guardians SHOULD be selected from diverse trust domains, and [=threshold=] SHOULD be ≥ 3-of-5. The use of zero-knowledge proofs prevents guardians from learning each other's shares during recovery.

Time-Lock Bypass (Type B)

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

Mitigation: [=Verifiable Delay Functions=] provide computational asymmetry that cannot be parallelized, making premature release computationally infeasible within the specified time window. The Wesolowski proof system enables efficient verification that the required sequential computation was performed.

Provider State Drift (Type C)

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

Mitigation: [=Share refreshment=] with verifiable refresh transcripts ensures consistency. The [=catch-up protocol=] handles [=epoch=] lag by providing cryptographically verifiable refresh transcripts that lagging providers can verify and apply.

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.

function checkAcyclic(did, visited = new Set()): if visited.has(did): return false visited.add(did) for each recoveryMethod in resolve(did).recovery: for each guardian in recoveryMethod.guardians: if guardian.id is DID and not checkAcyclic(guardian.id, visited): return false visited.delete(did) return true

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.

Cryptographic Algorithm Aging

Threat: Current cryptographic algorithms may become vulnerable over time.

Mitigation: 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.

Interoperability Requirements

Mandatory-to-Implement Algorithms

Algorithm	Usage
Ed25519	Signatures, guardian keys
SHA-256	Hashing
XChaCha20-Poly1305	Seed lockbox encryption
AES-256-GCM	Share encryption at rest
BIP-32	Key derivation
fROST (Ed25519)	Threshold signatures
Feldman VSS (p,q,g per §Cryptographic Primitives)	Verifiable secret sharing
Wesolowski VDF	Time-locks

Optional Algorithms

Algorithm	Usage
secp256k1	Blockchain compatibility
BLS12-381	Pairing-based cryptography
Pietrzak VDF	Alternative time-locks
Dilithium	Post-quantum signatures
Kyber	Post-quantum encryption

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.

JSON-LD Context

The JSON-LD context is available at: https://w3c-ccg.github.io/did-recovery/context/v1.jsonld

{
  "@context": {
    "@version": 1.1,
    "@protected": true,
    "recovery": "https://w3c-ccg.github.io/did-recovery#recovery",
    "RecoveryMethodZKPSocial": "https://w3c-ccg.github.io/did-recovery#RecoveryMethodZKPSocial",
    "RecoveryMethodDeterministic": "https://w3c-ccg.github.io/did-recovery#RecoveryMethodDeterministic",
    "RecoveryMethodMPC": "https://w3c-ccg.github.io/did-recovery#RecoveryMethodMPC",
    "recoveryThreshold": "https://w3c-ccg.github.io/did-recovery#recoveryThreshold",
    "vssScheme": "https://w3c-ccg.github.io/did-recovery#vssScheme",
    "vssGroupParameters": "https://w3c-ccg.github.io/did-recovery#vssGroupParameters",
    "vssCommitments": "https://w3c-ccg.github.io/did-recovery#vssCommitments",
    "recoveryGuardians": "https://w3c-ccg.github.io/did-recovery#recoveryGuardians",
    "guardianEndpoint": "https://w3c-ccg.github.io/did-recovery#guardianEndpoint",
    "seedDerivationPath": "https://w3c-ccg.github.io/did-recovery#seedDerivationPath",
    "encryptedSeedLockbox": "https://w3c-ccg.github.io/did-recovery#encryptedSeedLockbox",
    "deadMansSwitch": "https://w3c-ccg.github.io/did-recovery#deadMansSwitch",
    "mpcThreshold": "https://w3c-ccg.github.io/did-recovery#mpcThreshold",
    "mpcProviders": "https://w3c-ccg.github.io/did-recovery#mpcProviders",
    "shareRotation": "https://w3c-ccg.github.io/did-recovery#shareRotation",
    "currentEpoch": "https://w3c-ccg.github.io/did-recovery#currentEpoch",
    "synchronization": "https://w3c-ccg.github.io/did-recovery#synchronization",
    "maxEpochSkew": "https://w3c-ccg.github.io/did-recovery#maxEpochSkew",
    "catchupProtocol": "https://w3c-ccg.github.io/did-recovery#catchupProtocol"
  }
}

Test Vectors

Type A Test Vector — Feldman VSS

Group parameters: (p, q, g) as defined in §Cryptographic Primitives.

Setup: Secret s = 42, [=threshold=] t = 2, total shares n = 3, polynomial P(x) = 42 + 17·x (over Z_q).

Shares: s₁ = P(1) mod q = 59 s₂ = P(2) mod q = 76 s₃ = P(3) mod q = 93

Commitments: C₀ = 4⁴² mod p, C₁ = 4¹⁷ mod p

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

LHS = 4 93 mod p RHS = C₀ 1 \cdot C₁ 3 mod q mod p = 4 42 \cdot 4 17\cdot3 mod p = 4 42+51 mod p = 4 93 mod p ✓

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

L₁(0) = (0-2)/(1-2) mod q = (-2)\cdot(-1)⁻¹ mod q = 2 L₂(0) = (0-1)/(2-1) mod q = (-1)\cdot(1)⁻¹ mod q = q-1 s = 59\cdot2 + 76\cdot(q-1) mod q = 118 - 76 = 42 ✓

Type A Test Vector — Proactive Refresh

Applying a refresh polynomial R(x) = 5·x (R(0)=0):

δ₁ = 5, δ₂ = 10, δ₃ = 15 s₁ᶰᵉʷ = 59 + 5 = 64 s₂ᶰᵉʷ = 76 + 10 = 86 s₃ᶰᵉʷ = 93 + 15 = 108 C₀ᶰᵉʷ = C₀ \cdot g⁰ = C₀ C₁ᶰᵉʷ = C₁ \cdot 4⁵ = 4¹⁷ \cdot 4⁵ = 4²² mod p Recovery: 64\cdot2 + 86\cdot(q-1) = 128 - 86 = 42 ✓

Type B Test Vector

Master Seed: 0x7f3a9b8c2d5e1f4a3b6c7d8e9f0a1b2c

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

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

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

Type C Test Vector

fROST t=2, n=3 — share format (illustrative):

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

Introduction

Design Goals

Relationship to DID Core

Terminology

Recovery Method Architecture

Discovery Model

Lifecycle

Recovery Method Types

Type A: Social ZKP Recovery

Cryptographic Requirements

Setup Phase

Recovery Phase

DID Document Representation

Type B: Deterministic Seedling Inheritance

Cryptographic Requirements

Type C: MPC-Mediated Recovery

Cryptographic Requirements

Provider State Synchronization

Verification Relationships

Processing Rules

Cryptographic Primitives

VSS Group Parameters

Verifiable Secret Sharing (Feldman's VSS)

Share Generation

Share Verification

Secret Recovery

Proactive Share Refreshment

Zero-Knowledge Proof of Share

Verifiable Delay Function (Wesolowski)

Security Considerations

Guardian Collusion (Type A)

Time-Lock Bypass (Type B)

Provider State Drift (Type C)

Recovery-Loop Prevention

Key Wrapping Security

Cryptographic Algorithm Aging

Privacy Considerations

Metadata Leakage

Guardian Privacy

Correlation Risk

Beneficiary Privacy

Interoperability Requirements

Mandatory-to-Implement Algorithms

Optional Algorithms

DID Method Compatibility

JSON-LD Context

Test Vectors

Type A Test Vector — Feldman VSS

Type A Test Vector — Proactive Refresh

Type B Test Vector

Type C Test Vector

Acknowledgements

References

Normative References

Informative References