DID Key Recovery Threat Model
& Security Specification

§Status of This Document

This is the Editors Draft of the DID Key Recovery Threat Model & Security Specification (DID-TM), prepared by Amir Hameed Mir of Sirraya Labs. This document is a companion to the DID Key Recovery Extension (DID-KR v1.0.0) and extends the W3C Decentralized Identifier specification's §10 (Security Considerations) and §11 (Privacy Considerations) into a standalone, normative framework.

1. Introduction

Decentralized identity systems invert the classical security model. In centralized systems, a trusted third party — an identity provider, a certificate authority, a directory service — anchors trust, bears security obligations, and provides out-of-band recovery paths. Security practitioners can reason about such systems using well-established frameworks: STRIDE models spoofing and tampering against known service boundaries; LINDDUN maps privacy threats against a data controller; PASTA derives attack scenarios from a defined application architecture.

Decentralized identifier systems eliminate the trusted third party by design. The DID controller is simultaneously the subject, the authority, and the recovery path. Verifiable Credentials travel directly between issuers and holders without a central directory. Key recovery, if it exists at all, is a cryptographic construction — not an operational procedure. This architectural shift renders classical threat frameworks structurally incomplete.

The most visible symptom of this incompleteness is the Key Lifecycle Gap: no existing framework — not STRIDE, not LINDDUN, not PASTA, not MITRE ATT&CK — contains a threat class for failures arising from the cryptographic key management lifecycle in a system where the key is the identity. Guardian collusion in a secret-sharing scheme, share drift across MPC epoch boundaries, VDF difficulty miscalibration, and post-quantum algorithm migration all represent threats with no natural home in any existing taxonomy. This specification creates that home.

1.1 Why a New Taxonomy

The argument for a purpose-built taxonomy rests on three observations:

1. Trust model mismatch: STRIDE's threat categories implicitly assume boundaries between trusted and untrusted zones, mediated by a server the defender controls. In DID systems, the resolver is not controlled by the subject. The ledger is not controlled by any party. The guardian is a social relationship, not an administrative role. Threats must be modeled across a fundamentally different trust topology.
2. Cryptographic primitives as first-class attack surfaces: Classical threat models treat cryptography as a solved sub-problem — "encrypt the channel," "sign the message." DID systems expose cryptographic constructions (VSS polynomials, Schnorr proofs, VDFs, fROST ceremonies) as protocol-level surfaces that can be attacked at the algebraic, implementation, and operational layers simultaneously.
3. Privacy as a structural property: LINDDUN treats privacy threats as threats against a data controller's handling of personal data. In SSI systems, privacy is a structural property of the protocol — selective disclosure, unlinkability, and holder binding are baked into the cryptographic design. Threats to privacy are therefore threats to cryptographic properties, not to data handling policies.

1.2 Design Goals

• Completeness: Every threat relevant to DID/SSI systems MUST be expressible within the taxonomy.
• Precision: Each threat class and attack entry MUST be defined precisely enough to be cited in a security audit, a CVE description, or a standards body comment.
• Traceability: Every normative security requirement MUST trace to one or more threat entries, and every threat entry MUST have at least one normative mitigation.
• Interoperability: Threat metadata MUST be expressible in JSON-LD for embedding in DID Documents and VC proofs.
• Literature grounding: Every threat class and cryptographic analysis MUST cite peer-reviewed literature or recognized standards documents.

1.3 Relationship to Existing Standards

This specification extends and complements the following:

• W3C DID Core §10–11: This specification operationalizes the security and privacy considerations of DID Core into normative, testable requirements.
• DID-KR (Sirraya Labs): The DID Key Recovery Extension defines recovery mechanisms; this specification formally characterizes the threats those mechanisms must address and provides the K-class taxonomy they exemplify.
• W3C VC Data Model §8: Verifiable Credential security considerations are subsumed by the VC/VP attack catalog in §14.
• NIST SP 800-63: Where applicable, requirements are aligned with NIST's digital identity guidelines for authentication assurance levels.
• ETSI EN 319 401 / eIDAS 2.0: EU regulatory alignment is addressed in §27.

2. Conformance

All authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else 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.

A conforming DID Method with respect to this specification is one that documents its security profile using the taxonomy and attack identifiers defined herein, provides normative responses to all applicable threat classes, and publishes that documentation at a stable URL referenced from its DID Method specification.

A conforming DID Wallet is an implementation that satisfies all MUST-level requirements in §24 applicable to the wallet boundary and passes all test assertions in Appendix A marked as applicable to wallets.

3. Terminology

Threat

A potential event or action that could cause harm to a DID system, its controllers, or its participants.

Attack

A deliberate realization of a threat by an adversary.

Threat Class

A category of related threats sharing common attack mechanisms, affected assets, and countermeasure families. This specification defines seven threat classes (§4–5).

Attack Surface

The set of interfaces, protocols, and data stores that an adversary can interact with to mount an attack.

Adversary

An entity that deliberately attempts to compromise the security or privacy properties of a DID system.

Trust Boundary

An interface at which control of data or execution transitions from one principal to another, and across which security properties cannot be assumed without verification.

DID Controller

As defined in DID Core: the entity authorized to make changes to a DID Document.

Holder

An entity that possesses one or more Verifiable Credentials and can generate Verifiable Presentations.

Issuer

An entity that creates and signs Verifiable Credentials.

Verifier

An entity that receives and verifies Verifiable Presentations.

Guardian

An entity holding a cryptographic share as part of a social recovery scheme.

Key Ceremony

A formal, witnessed procedure for generating, distributing, or destroying cryptographic key material.

Share Drift

A state in which the secret shares held by distributed participants become inconsistent across epoch boundaries, potentially preventing successful threshold reconstruction.

CVSS-DID

An extension of the Common Vulnerability Scoring System (CVSS 3.1) with additional metrics specific to decentralized identity systems, defined in §7.

Attack Tree

A formal model representing the ways an attacker can reach an attack goal, using AND/OR logical composition of sub-goals (Schneier 1999).

Post-Quantum Security

Security against adversaries with access to a cryptographically relevant quantum computer capable of running Shor's or Grover's algorithms at scale.

4. STRIDE-DID Threat Classes

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a threat elicitation framework introduced by Loren Kohnfelder and Praerit Garg at Microsoft in 1999 and formalized in [STRIDE-ORIGINAL]. This specification re-specifies each STRIDE class for the decentralized identity context, replacing implicit assumptions about centralized control with explicit definitions applicable to DID/SSI architectures.

The relationship between original STRIDE and STRIDE-DID is analogous to the relationship between generic network security models and post-perimeter security models: the original categories remain relevant but their definitions, threat agents, and countermeasures must be re-derived from a different threat model.

5. K — Key Lifecycle Failure (Novel Class)

Definition: A K-class threat arises when the cryptographic key management lifecycle — including key generation, distribution, custody, rotation, recovery, and post-quantum migration — fails in a way that causes permanent loss of identity control, unauthorized transfer of identity control, or structural degradation of the cryptographic guarantees that back the identity system. K-class failures are distinct from all other threat classes because they are often irreversible: unlike a data breach (I-class), a compromised DID from a K-class failure cannot be remediated by changing a password or invalidating a session. The key is the identity.

5.1 Why K Cannot Be Subsumed by Existing Classes

A naive analysis might assign key management failures to existing STRIDE classes: key theft to S (Spoofing), share manipulation to T (Tampering), key unavailability to D (DoS). This analysis is insufficient for three reasons:

1. Lifecycle coherence: K-class failures span the entire key lifecycle as a unified phenomenon. A share drift failure (§18, attack DID-TM-ATK-401) begins with an operational failure (missed epoch refresh), manifests as a cryptographic inconsistency, and results in either DoS (reconstruction fails) or privilege escalation (wrong secret reconstructed). No single existing class captures this lifecycle arc.
2. Cryptographic construction as attack surface: K-class threats attack the design of the cryptographic construction, not just its implementation. A VDF calibrated to a reference platform that has been superseded by ASIC hardware is not a DoS attack or a tampering attack — it is a failure of the key lifecycle specification that makes the time-lock property invalid.
3. Non-custodial irreversibility: In non-custodial systems, there is no authority with the power to override a key management failure. The irreversibility of K-class failures in fully decentralized systems requires a distinct threat class with its own countermeasure family.

5.2 K-Class Sub-categories

K1 — Key Ceremony Failure

Failure of the formal procedure by which key material is generated, backed up, or distributed, resulting in insecure key generation, unwitnessed key ceremonies, or improper key escrow.

K2 — Share Lifecycle Failure

Failure in the distribution, custody, refreshment, or reconstruction of secret shares in threshold schemes. Includes share drift (§18, DID-TM-ATK-401), share loss, and proactive refresh desynchronization.

K3 — Time-Lock Integrity Failure

Failure of a VDF or time-lock construction to enforce the intended temporal property. Includes difficulty miscalibration, ASIC advantage exploitation, and false proof acceptance.

K4 — Rotation and Revocation Failure

Failure of key rotation or revocation to take effect correctly, leaving revoked keys accepted or creating windows of dual validity.

K5 — Post-Quantum Migration Failure

Failure to migrate cryptographic constructions to quantum-resistant algorithms before a cryptographically relevant quantum computer becomes available, resulting in retroactive compromise of archived identity records.

K6 — Inheritance and Recovery Chain Failure

Failure of the designated succession path for a DID — including dead-man's switch failures, beneficiary key loss, and inheritance chain breaks — resulting in permanent loss of identity control after the controller's incapacity.

6. LINDDUN-DID Privacy Threat Mapping

LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance) is a privacy threat elicitation framework developed by Deng et al. [DENG-2011]. This section maps LINDDUN categories to DID/SSI-specific privacy threats and identifies where DID architecture creates novel privacy threat surfaces not covered by the original framework.

7. CVSS-DID Scoring Methodology

The Common Vulnerability Scoring System v3.1 [CVSS-31] provides a standardized method for assessing vulnerability severity. This specification extends CVSS 3.1 with four additional metrics specific to decentralized identity systems. CVSS-DID scores are used throughout the attack catalog in Part III.

7.1 CVSS-DID Extension Metrics

7.2 Severity Classification

8. The DID Stack

This specification models the DID ecosystem as a four-layer stack. Each layer has a distinct attack surface, set of trust assumptions, and applicable countermeasure family. Attacks typically exploit weaknesses at a single layer but may propagate across layer boundaries.

8.1 Layer 1 — Registry and Method Layer

The registry layer encompasses the substrate on which DID Documents are anchored. This includes public blockchain ledgers (Ethereum, Bitcoin, Hyperledger Indy), web servers (for did:web), distributed hash tables (for IPFS-backed methods), and DNS infrastructure. The security properties of this layer are entirely determined by the DID method and are largely outside the control of the DID subject.

Primary threats: Smart contract vulnerabilities (T-class), ledger consensus manipulation (T-class), DNS hijacking for did:web (S-class), IPFS content addressing collisions (T-class).

8.2 Layer 2 — Resolution and Transport Layer

The resolution layer encompasses DID resolvers — universal or method-specific — that transform DID strings into DID Documents. Resolvers are trust boundaries: a resolver that returns a manipulated DID Document invalidates all security properties that depend on the resolved document, regardless of the strength of the underlying registry.

Primary threats: Resolver cache poisoning (S-class), DNS-over-HTTPS MITM (T-class), resolution result tampering (T-class), resolver DoS (D-class).

8.3 Layer 3 — Protocol Layer

The protocol layer encompasses the exchange protocols that use DIDs and Verifiable Credentials: DIDComm messaging, OpenID for Verifiable Credentials (OID4VC), the Verifiable Presentation Request protocol, and credential status protocols. This layer's primary threats concern the integrity and privacy of credential exchanges.

Primary threats: Credential forgery (T-class), holder binding bypass (S-class, E-class), presentation replay (S-class), credential correlation (I-class).

8.4 Layer 4 — Application and Wallet Layer

The wallet layer is the most heterogeneous and, in practice, the highest-risk layer. Wallets hold private key material, manage credential stores, and execute user-facing operations. Hardware security module (HSM) integration and secure enclave usage vary widely across implementations.

Primary threats: Private key extraction (K-class, E-class), seed phrase compromise (K-class), wallet malware (K-class, S-class), biometric bypass (S-class, E-class).

9. Adversary Model

This specification defines four adversary tiers based on capability and resources. Each attack entry in Part III is annotated with the minimum adversary tier required to execute the attack.

9.1 Adversary Goals

Adversaries attacking DID systems pursue goals that differ meaningfully from classical adversaries. The primary goals, in approximate order of prevalence:

1. Identity takeover — gaining full control of a target's DID, enabling impersonation and credential issuance
2. Credential forgery — creating false credentials without controlling the issuer's DID
3. Correlation and surveillance — building behavioral profiles of subjects across verifiers without their knowledge
4. Identity denial — preventing a legitimate subject from using or recovering their DID
5. Recovery subversion — gaining the ability to trigger or manipulate recovery mechanisms at a time of the adversary's choosing

10. Identity Lifecycle Threat Map

Every DID passes through a common lifecycle. This section maps the primary threat classes applicable at each lifecycle stage.

The threat classes annotated on each transition arrow indicate which classes are most active during the transition. For example, the transition from Creation to Issuance carries S (key ceremony impersonation), T (DID Document tampering during registration), and K sub-class K1 (key ceremony failure).

The attack catalog assigns each attack a permanent identifier of the form DID-TM-ATK-NNN. Identifiers are stable across versions of this specification; attacks are never renumbered. Deprecated attacks are marked as such but retain their identifier.

Each entry contains: identifier, name, primary and secondary threat class(es), CVSS-DID score and severity, affected DID stack layer, minimum adversary tier, attack description, attack tree (abbreviated), normative mitigation references, and peer-reviewed literature citations.

11. Registry and Method Layer Attacks (50x)

12. Resolution and Transport Layer Attacks (100x)

13. Wallet and Key Material Attacks (200x)

14. Verifiable Credential and Presentation Attacks (300x)

15. Recovery-Specific Attacks (400x)

Recovery attacks are a sub-family of K-class threats that specifically target the mechanisms defined in DID-KR. This catalog entry series maps directly to the recovery types defined in [DID-KR].

16. Cross-Cutting Attacks (500x)

11. Registry and Method Layer Attacks (50x)

12. Resolution and Transport Layer Attacks (100x)

13. Wallet and Key Material Attacks (200x)

14. Verifiable Credential and Presentation Attacks (300x)

15. Recovery-Specific Attacks (400x)

Recovery attacks are a sub-family of K-class threats that specifically target the mechanisms defined in DID-KR. This catalog entry series maps directly to the recovery types defined in [DID-KR].

16. Cross-Cutting Attacks (500x)

17. Algebraic Assumptions and Failure Conditions

The cryptographic constructions used in DID systems rest on a hierarchy of hardness assumptions. An assumption failure — whether due to mathematical advances, implementation errors, or quantum computing — cascades upward through all constructions that depend on it. This section catalogs the relevant assumptions and their failure consequences.

18. VSS-Specific Threats

Feldman's Verifiable Secret Sharing (as specified in DID-KR §7.1) has several attack surfaces arising from incorrect parameterization, implementation errors, and adversarial dealer behavior. This section documents these threats and their normative mitigations.

18.1 Incorrect Group Parameterization (DID-TM-ATK-410)

The most critical VSS implementation error is using the wrong modulus for share arithmetic. If shares s_i = P(i) mod p are computed modulo the group prime p rather than the scalar field order q, the Feldman verification equation fails silently for large share values — shares appear to verify but Lagrange interpolation recovers the wrong secret.

Formally: shares live in the scalar field Z_q; commitments live in the group Z_p*. These are distinct algebraic objects. The invariant that enables verification is: ord(g) = q, so g^(x mod q) = g^x mod p for any integer x. This invariant holds only when g is a generator of a subgroup of order exactly q in Z_p*.

18.2 Dishonest Dealer Attack (DID-TM-ATK-411)

A dishonest dealer can distribute inconsistent shares — shares that are not evaluations of any single polynomial — if VSS commitment verification is not performed by each participant before acknowledging receipt. The Feldman commitment scheme makes this detectable: if a share s_i does not satisfy the verification equation, the dealer is provably cheating.

Mitigations: REQ-420: Each participant MUST verify their share against all commitments upon receipt, before acknowledging. REQ-421: Any participant who receives a share that fails verification MUST broadcast a complaint with the failing verification equation.

18.3 Share Refreshment Zero-Term Error (DID-TM-ATK-412)

During proactive refresh (DID-KR §7.1.4), the refresh polynomial R(x) must satisfy R(0) = 0 to preserve the secret. If an implementation inadvertently includes a non-zero constant term — due to an off-by-one error in polynomial construction or incorrect coefficient generation — the refresh changes the secret, rendering previously issued credentials (whose holder binding references the original public key) invalid.

19. ZKP-Specific Threats

19.1 Proof Malleability (DID-TM-ATK-420)

A malleable proof scheme allows an adversary to modify a valid proof to produce another valid proof for the same or a related statement, without knowing the witness. For Schnorr proofs as used in DID-KR §7.2, malleability can arise if the challenge derivation is not commitment-binding or if the verifier accepts proofs with negated response values (since -z is also a valid response in some parameterizations).

Mitigation: REQ-430: Implementations MUST use the Fiat-Shamir heuristic with a domain-separated hash function for non-interactive Schnorr proofs. The challenge MUST be derived as c = H(g || g^r || commitments || session_context) where session_context includes the DID, the recovery session ID, and the current timestamp. REQ-431: Response values MUST be checked to be in [0, q-1] before verification.

19.2 Soundness Failure under Weak Fiat-Shamir (DID-TM-ATK-421)

The Fiat-Shamir transform produces a non-interactive proof that is only sound in the Random Oracle Model. Implementations that use non-random hash functions, truncated hash outputs, or domain separation that allows cross-protocol collision are vulnerable to soundness attacks where a prover without knowledge of the witness can forge a valid proof.

Mitigation: REQ-432: All Fiat-Shamir transformations MUST use SHA-256 or SHA-3-256 with proper domain separation. The domain separator MUST include the protocol identifier "DID-KR-ZKP-v1" and the specific statement type. Hash output MUST NOT be truncated below 128 bits for the challenge.

20. VDF-Specific Threats

20.1 ASIC Hardware Advantage (DID-TM-ATK-430)

VDF security relies on the assumption that sequential computation cannot be parallelized. For RSA-based VDFs (Wesolowski, Pietrzak), this assumption holds for software adversaries. However, custom ASIC hardware optimized for modular squaring can execute the sequential squaring chain at clock speeds 10x–100x faster than a reference CPU, undermining the time-lock guarantee by the same factor.

Mitigation: REQ-440: VDF parameter specifications MUST include an ASIC advantage factor in the difficulty calibration. For Wesolowski VDFs, a minimum ASIC resistance factor of 10x SHOULD be applied — meaning the intended wall-clock time should be achievable by an ASIC adversary at no less than 10% of the nominal time before the parameter is considered broken. REQ-441: VDF parameters MUST be versioned and updatable without changing the DID controller's key material.

20.2 Wesolowski Proof Forgery via Low-Order Elements (DID-TM-ATK-431)

The Wesolowski VDF uses an RSA group whose order is unknown (under the assumption that factoring is hard). An adversary who finds a low-order element in the group can forge a VDF proof without performing the sequential computation. This threat is mitigated by careful modulus generation (using a modulus with no small factors) but must be explicitly verified.

Mitigation: REQ-442: VDF moduli MUST be generated using a verifiably random process. REQ-443: Modulus generation ceremonies MUST be documented and publicly auditable. REQ-444: Implementations MUST verify that the VDF input x ∈ QR(N) (quadratic residuosity check) before evaluation.

21. Threshold Signature Threats

21.1 fROST Nonce Reuse (DID-TM-ATK-440)

fROST threshold signatures require each participant to generate a fresh nonce for each signing ceremony. Nonce reuse — whether due to a faulty PRNG, a state rollback, or incorrect ceremony management — allows an adversary who observes two signing rounds with the same nonce to recover the participant's secret share using simple algebra. This is the single most critical implementation requirement for any Schnorr-based threshold signature scheme.

Mitigation: REQ-450: fROST implementations MUST use deterministic nonce generation per RFC 6979, seeded with the participant's secret share and the message being signed. REQ-451: Participants MUST abort any signing ceremony where the same nonce has been used in a prior ceremony.

21.2 Rogue Key Attack in Key Generation (DID-TM-ATK-441)

In fROST distributed key generation (DKG), a malicious participant can choose their public key share to cancel out or manipulate contributions from other participants, effectively controlling the aggregate public key. This attack is mitigated by requiring proof of knowledge of the corresponding secret key during DKG.

Mitigation: REQ-452: fROST DKG implementations MUST require each participant to prove knowledge of their secret key contribution using a Schnorr proof before their public key share is accepted. This is the KOSK (Knowledge of Secret Key) assumption enforcement.

22. Side-Channel and Implementation Threats

22.1 Timing Attacks on Key Derivation

Variable-time key derivation or signature operations allow an adversary who can measure operation timing (locally or via remote timing) to extract information about secret key material. For DID wallets, the most common timing attack surface is in the comparison of credential proofs or the conditional branches in Lagrange interpolation.

Mitigation: REQ-460: All cryptographic operations involving secret values MUST be implemented in constant time. This includes modular arithmetic, scalar multiplications, and any conditional branch whose path depends on a secret value. Implementations MUST use constant-time comparison functions for all proof verification.

22.2 Fault Injection in Hardware Wallets

Hardware wallets are vulnerable to fault injection attacks — voltage glitching, electromagnetic fault injection (EMFI), or laser fault injection — that can cause the secure element to skip security checks, reveal intermediate computation values, or produce faulty signatures from which the key can be derived.

Mitigation: REQ-461: Hardware wallets MUST implement fault detection countermeasures including instruction duplication, computation result verification, and random delays. Security certifications (Common Criteria EAL4+, FIPS 140-2 Level 3) are RECOMMENDED for hardware wallets used with high-assurance DIDs.

23. Post-Quantum Threat Model

The NIST Post-Quantum Cryptography standardization process concluded in 2024, producing final standards for ML-KEM (CRYSTALS-Kyber), ML-DSA (CRYSTALS-Dilithium), and SLH-DSA (SPHINCS+) [NIST-PQC-2024]. DID systems built on elliptic curve cryptography face a long-term threat from quantum computing that requires a deliberate migration strategy.

23.1 Harvest-Now Decrypt-Later

An adversary can archive encrypted DIDComm messages, sealed credential lockboxes, and other encrypted identity data today, with the intent to decrypt them when a cryptographically relevant quantum computer becomes available. For long-lived identity data (medical records, legal credentials, financial history), this represents a present-day threat to future privacy.

Mitigation: REQ-470: DIDComm implementations SHOULD migrate to hybrid classical/post-quantum key encapsulation mechanisms (HPKE with ML-KEM-768 + X25519). REQ-471: VDF moduli MUST be transitioned to class group-based constructions that are believed to be quantum-resistant, as RSA-group VDFs are broken by Shor's algorithm.

23.2 Migration Window Analysis

Post-quantum migration for DID systems requires coordinated updates across four layers simultaneously: signing algorithms for DID Document proofs, key agreement algorithms for DIDComm, credential proof algorithms for VCs, and threshold signature algorithms for MPC recovery. Partial migration leaves the weakest layer as the attack vector.

24. Normative Security Requirements

The following requirements are normative. Each requirement is assigned an identifier, a requirement level (MUST/SHOULD/MAY per RFC 2119), the applicable DID stack component, and a pointer to the threat(s) it mitigates.

24.1 DID Registry Requirements

• REQ-50: [MUST] DID registry smart contracts MUST implement Checks-Effects-Interactions. Mitigates: DID-TM-ATK-050.
• REQ-51: [MUST] Registry contracts MUST use a reentrancy guard. Mitigates: DID-TM-ATK-050.
• REQ-52: [MUST] did:web implementations MUST use DNSSEC and TLS certificate monitoring. Mitigates: DID-TM-ATK-051.
• REQ-53: [SHOULD] did:web DID Documents SHOULD include a self-signed proof for detection of unauthorized modification. Mitigates: DID-TM-ATK-051.
• REQ-54: [MUST] Resolvers MUST connect to multiple independent ledger nodes. Mitigates: DID-TM-ATK-052.

24.2 Resolver Requirements

• REQ-100: [MUST] Cached DID Documents MUST be cryptographically anchored to the registry. Mitigates: DID-TM-ATK-100.
• REQ-101: [MUST] Cache TTLs MUST NOT exceed DID method minimum update propagation time. Mitigates: DID-TM-ATK-100.
• REQ-103: [MUST] Resolvers MUST validate all DID Document URLs against an allowlist. Mitigates: DID-TM-ATK-101.
• REQ-105: [MUST] DID Document size MUST be limited (RECOMMENDED: 64 KB). Mitigates: DID-TM-ATK-102.
• REQ-107: [MUST] Resolvers MUST implement rate limiting per source IP and DID method. Mitigates: DID-TM-ATK-102.

24.3 Wallet Requirements

• REQ-200: [MUST] Wallets MUST use OS-provided secure key storage for all private key material. Mitigates: DID-TM-ATK-200.
• REQ-201: [MUST] Seed phrases MUST NOT be held decrypted in heap memory beyond minimum required time. Mitigates: DID-TM-ATK-200.
• REQ-203: [MUST] Wallets MUST display seed phrases in a secure UI surface preventing clipboard access. Mitigates: DID-TM-ATK-201.
• REQ-205: [MUST] Wallets MUST use hardware-backed biometric APIs. Mitigates: DID-TM-ATK-202.
• REQ-460: [MUST] All cryptographic operations involving secret values MUST be constant-time. Mitigates: §22.1.

24.4 Credential and Presentation Requirements

• REQ-300: [MUST] Verifiable Presentations MUST include a verifier-provided nonce bound to the proof. Mitigates: DID-TM-ATK-300.
• REQ-301: [MUST] Presentation expiry MUST NOT exceed 5 minutes for interactive authentication. Mitigates: DID-TM-ATK-300.
• REQ-303: [MUST] Credentials MUST include credentialSubject.id corresponding to a holder-controlled DID. Mitigates: DID-TM-ATK-301.
• REQ-306: [MUST] ZKP presentation proofs MUST use fresh, cryptographically secure randomness for each generation. Mitigates: DID-TM-ATK-302.

24.5 Recovery Requirements

• REQ-400: [MUST] Guardian sets MUST be distributed across independent jurisdictions and organizations. Mitigates: DID-TM-ATK-400.
• REQ-404: [MUST] MPC implementations MUST implement the catch-up protocol (DID-KR §5.4.3). Mitigates: DID-TM-ATK-401.
• REQ-408: [MUST] VDF difficulty MUST include a tolerance factor ≥ 0.3. Mitigates: DID-TM-ATK-402.
• REQ-412: [MUST] Every submitted VSS share MUST be verified against Feldman commitments before Lagrange interpolation. Mitigates: DID-TM-ATK-403.
• REQ-415: [MUST] Recovery method dependency graphs MUST be validated as acyclic at publication time. Mitigates: DID-TM-ATK-404.
• REQ-450: [MUST] fROST implementations MUST use deterministic nonce generation per RFC 6979. Mitigates: DID-TM-ATK-440.

25. Normative Privacy Requirements

25.1 Selective Disclosure Requirements

• PRI-100: [MUST] Credential issuers MUST support selective disclosure schemes (BBS+, SD-JWT, or AnonCreds) for credentials containing more than one attribute.
• PRI-101: [MUST] Wallet implementations MUST NOT present more claims than explicitly requested by the verifier's presentation request.
• PRI-102: [SHOULD] Verifiers SHOULD request the minimum set of claims necessary for their use case (data minimization principle).

25.2 Unlinkability Requirements

• PRI-200: [MUST] Holders MUST use pairwise DIDs (unique DID per verifier relationship) for all interactions where unlinkability is a requirement.
• PRI-201: [MUST] ZKP presentation proofs MUST achieve proof unlinkability across presentations (no shared proof components across presentations to different verifiers).
• PRI-202: [SHOULD] DID resolution SHOULD be performed through anonymizing infrastructure (Tor, onion services) where unlinkability at the resolver layer is required.

25.3 Minimization Requirements

• PRI-300: [MUST] DID Documents MUST NOT contain personal data. Service endpoints MUST NOT include information that could identify the subject without DID resolution.
• PRI-301: [MUST] Recovery method representations in DID Documents MUST use hashed or pseudonymous guardian identifiers (see DID-KR §9.2). Mitigates: DID-TM-ATK-501.
• PRI-302: [SHOULD] Issuers SHOULD issue single-use credentials for sensitive attributes to prevent accumulation of presentation history at verifiers.

26. Threat-to-Control Traceability Matrix

The following matrix maps selected attacks to their primary normative controls. Y = directly addresses the threat; P = partially addresses; N = not addressed by this control.

27. Regulatory and Framework Alignment

27.1 NIST SP 800-63 Digital Identity Guidelines

NIST SP 800-63 defines Identity Assurance Levels (IAL), Authentication Assurance Levels (AAL), and Federation Assurance Levels (FAL). DID-TM security requirements map to these levels as follows:

27.2 ISO/IEC 27001 and SOC 2

DID-TM requirements applicable to infrastructure operators (resolver services, MPC providers, guardian services) map to ISO 27001 controls and SOC 2 Trust Services Criteria as follows: The Annex A control A.12.2 (Protection from malware) maps to REQ-201 and REQ-203. A.14.2.8 (System security testing) maps to the test assertions in Appendix A. SOC 2 CC6.1 (logical access controls) maps to REQ-200 through REQ-206.

27.3 eIDAS 2.0 / European Digital Identity Wallet

The European Digital Identity (EUDI) Wallet under eIDAS 2.0 defines security requirements for qualified electronic signatures and seals that must be grounded in Common Criteria-certified hardware. DID-TM REQ-461 (hardware wallet certification) aligns with the eIDAS 2.0 QEAA (Qualified Electronic Attestation of Attributes) requirements. The credential format requirements of the EUDI Architecture Reference Framework (ARF) are satisfied by conformance to REQ-303 through REQ-308.

27.4 W3C DID Core §10–11 Gap Analysis

W3C DID Core §10 identifies security considerations including residual risks of compromise, authentication, verification relationships, and DID method security. This specification extends each consideration into normative requirements with specific attack identifiers and measurable test assertions. The primary gap filled by DID-TM is the absence of a formal threat taxonomy in DID Core: the specification lists considerations but does not provide a framework for systematically eliciting or classifying threats, a gap addressed by the STRIDE-DID taxonomy in §4–5.

28. DID Method Security Profiles

Different DID methods have materially different security properties. This section provides a threat exposure profile for the four most widely deployed methods.

Appendix A: Test Assertions

The following test assertions are normative. A conforming implementation MUST pass all applicable assertions. Assertions are designated by component scope: [W] = wallet, [R] = resolver, [M] = DID method, [V] = verifier.

{
  "testSuite": "DID-TM-v1",
  "assertions": [
    {
      "id": "DID-TM-TA-001",
      "scope": ["W"],
      "requirement": "REQ-200",
      "description": "Wallet MUST store private keys in OS secure storage",
      "method": "static-analysis",
      "passCriteria": "No private key bytes in cleartext heap or swap",
      "attack": "DID-TM-ATK-200"
    },
    {
      "id": "DID-TM-TA-002",
      "scope": ["V"],
      "requirement": "REQ-300",
      "description": "Verifier MUST reject VP without verifier-issued nonce",
      "method": "protocol-test",
      "passCriteria": "HTTP 400 response when presentation.proof.challenge absent",
      "attack": "DID-TM-ATK-300"
    },
    {
      "id": "DID-TM-TA-003",
      "scope": ["W"],
      "requirement": "REQ-412",
      "description": "VSS reconstruction MUST verify all shares before interpolation",
      "method": "unit-test",
      "passCriteria": "Reconstruction aborts with error when any share fails Feldman verification",
      "attack": "DID-TM-ATK-403"
    },
    {
      "id": "DID-TM-TA-004",
      "scope": ["M"],
      "requirement": "REQ-415",
      "description": "DID method MUST reject DID Documents with cyclic recovery dependencies",
      "method": "protocol-test",
      "passCriteria": "DID update rejected when recovery method dependency graph contains cycle",
      "attack": "DID-TM-ATK-404"
    },
    {
      "id": "DID-TM-TA-005",
      "scope": ["W"],
      "requirement": "REQ-450",
      "description": "fROST implementation MUST use deterministic nonce per RFC 6979",
      "method": "unit-test",
      "passCriteria": "Same (message, key) pair produces identical nonce across invocations",
      "attack": "DID-TM-ATK-440"
    }
  ]
}

Appendix B: Threat Register Template

Implementers SHOULD maintain a threat register using the following JSON schema for each DID system deployment. The register enables ongoing threat tracking and provides evidence for security audits.

{
  "$schema": "https://sirraya.org/schemas/did-tm-threat-register/v1",
  "system": "Example DID Wallet v2.1",
  "assessmentDate": "2026-01-15",
  "assessor": "Security Team, Example Corp",
  "threats": [
    {
      "attackId": "DID-TM-ATK-200",
      "attackName": "Cold Boot Seed Phrase Extraction",
      "class": "K",
      "cvss_did": "9.6",
      "inherentRisk": "Critical",
      "controlsImplemented": ["REQ-200", "REQ-201", "REQ-202"],
      "residualRisk": "Low",
      "residualRiskJustification": "iOS Secure Enclave stores key material; seed phrase cleared from memory immediately after derivation; mlock applied to key derivation buffers",
      "reviewDate": "2026-07-15"
    }
  ]
}

Appendix C: JSON-LD Context

Available at: https://sirraya.org/ns/did/threat-model/v1.jsonld

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

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

    "ThreatModel":        "https://sirraya.org/ns/did/threat-model#ThreatModel",
    "ThreatEntry":        "https://sirraya.org/ns/did/threat-model#ThreatEntry",
    "AttackCatalogEntry": "https://sirraya.org/ns/did/threat-model#AttackCatalogEntry",

    "threatModel": {
      "@id": "https://sirraya.org/ns/did/threat-model#threatModel",
      "@type": "@id"
    },
    "attackId": {
      "@id": "https://sirraya.org/ns/did/threat-model#attackId",
      "@type": "xsd:string"
    },
    "threatClass": {
      "@id": "https://sirraya.org/ns/did/threat-model#threatClass",
      "@type": "xsd:string"
    },
    "cvssDid": {
      "@id": "https://sirraya.org/ns/did/threat-model#cvssDid",
      "@type": "xsd:decimal"
    },
    "mitigationRefs": {
      "@id": "https://sirraya.org/ns/did/threat-model#mitigationRefs",
      "@type": "xsd:string",
      "@container": "@list"
    },
    "residualRisk": {
      "@id": "https://sirraya.org/ns/did/threat-model#residualRisk",
      "@type": "xsd:string"
    },
    "assessmentDate": {
      "@id": "https://sirraya.org/ns/did/threat-model#assessmentDate",
      "@type": "xsd:date"
    }
  }
}

Appendix D: References

Normative References

[DID-CORE]

W3C. "Decentralized Identifiers (DIDs) v1.0." W3C Recommendation, 2022. https://www.w3.org/TR/did-core/

[DID-KR]

Mir, A. H. "DID Key Recovery Specification v1.0.0." Sirraya Labs, 2026.

[VC-DATA-MODEL]

W3C. "Verifiable Credentials Data Model 2.0." W3C Recommendation, 2024.

[RFC2119]

Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels." IETF RFC 2119, 1997.

[RFC8174]

Leiba, B. "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words." IETF RFC 8174, 2017.

[RFC6979]

Thomas, P. "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)." IETF RFC 6979, 2013.

[CVSS-31]

FIRST.org. "Common Vulnerability Scoring System v3.1 Specification." 2019.

[NIST-PQC-2024]

NIST. "Post-Quantum Cryptography Standards." FIPS 203, 204, 205, 2024.

[NIST-SP-800-63]

NIST. "Digital Identity Guidelines." SP 800-63-3, 2017.

Informative References

[STRIDE-ORIGINAL]

Kohnfelder, L. & Garg, P. "The threats to our products." Microsoft Interface, 1999.

[DENG-2011]

Deng, M., Wuyts, K., Scandariato, R., Preneel, B., Joosen, W. "A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements." Requirements Engineering Journal, 2011.

[FELDMAN-1987]

Feldman, P. "A Practical Scheme for Non-interactive Verifiable Secret Sharing." FOCS 1987.

[SHAMIR-1979]

Shamir, A. "How to Share a Secret." Communications of the ACM, 1979.

[HERZBERG-1995]

Herzberg, A., Jarecki, S., Krawczyk, H., Yung, M. "Proactive Secret Sharing, Or: How to Cope With Perpetual Leakage." CRYPTO 1995.

[BONEH-2018]

Boneh, D., Bonneau, J., Bünz, B., Fisch, B. "Verifiable Delay Functions." CRYPTO 2018.

[BONNEAU-2012]

Bonneau, J., Herley, C., van Oorschot, P. C., Stajano, F. "The Quest to Replace Passwords." IEEE S&P 2012.

[HALDERMAN-2008]

Halderman, J. A. et al. "Lest We Remember: Cold Boot Attacks on Encryption Keys." USENIX Security 2008.

[FETT-DID-2019]

Fett, D., Küsters, R., Schmitz, G. "An Extensive Formal Security Analysis of the OpenID Financial-grade API." IEEE S&P 2019.

[ATZEI-2017]

Atzei, N., Bartoletti, M., Cimoli, T. "A Survey of Attacks on Ethereum Smart Contracts." ICPSS 2017.

[HEILMAN-2015]

Heilman, E., Kendler, A., Zohar, A., Goldberg, S. "Eclipse Attacks on Bitcoin's Peer-to-Peer Network." USENIX Security 2015.

[CHAUM-1985]

Chaum, D. "Security without identification: Transaction systems to make big brother obsolete." CACM 1985.

[MUHLE-2018]

Mühle, A., Grüner, A., Gayvoronskaya, T., Meinel, C. "A Survey on Essential Components of a Self-Sovereign Identity." Computer Science Review, 2018.

[PEDERSEN-1992]

Pedersen, T. P. "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing." CRYPTO 1991.

[GENNARO-1996]

Gennaro, R., Jarecki, S., Krawczyk, H., Rabin, T. "Robust Threshold DSS Signatures." EUROCRYPT 1996.

Appendix E: Acknowledgements

The editor wishes to acknowledge the foundational contributions of the cryptographic research community whose work is cited throughout this specification, particularly the authors of the Feldman VSS, proactive secret sharing, and VDF literature. The DID-TM specification builds directly on the security work of the W3C Verifiable Credentials Working Group, the Decentralized Identity Foundation (DIF), and the Trust Over IP Foundation.

Special acknowledgement is due to the researchers whose work established the theoretical foundations that make formal DID Key Recovery Threat Modeling possible: the formalization of Schnorr proofs and their use in threshold schemes (Schnorr 1991), the Fiat-Shamir heuristic (Fiat & Shamir 1987), and the proactive secret sharing framework that underpins MPC-mediated recovery security (Herzberg et al. 1995).

The K-class taxonomy was developed in conjunction with the DID Key Recovery Extension (DID-KR), and the authors of that specification's cryptographic constructions directly informed the K2, K3, and K4 sub-category definitions.