Introducing DID Threat Model (DID-TM) – Formal Security & Privacy Framework for DID Key Recovery and Beyond

Dear CCG Community,

Following our recent discussions on the DID Key Recovery Extension
(DID-KR) work
item adoption, we are pleased to introduce the DID Threat Model
Specification (DID-TM) —a formal, normative security and privacy framework
for decentralized identifier systems.

Background

During the development of DID-KR, we identified a critical gap: existing
threat frameworks (STRIDE, LINDDUN, MITRE ATT&CK) are structurally
insufficient for decentralized identity systems where the key *is* the
identity and no trusted third party exists. The security and privacy
considerations in DID-KR—guardian collusion, MPC share drift, VDF time-lock
integrity, recovery-loop prevention—demanded a formal threat taxonomy that
could provide traceable, normative requirements.

The DID Threat Model (DID-TM)

DID-TM provides:

   -

   STRIDE-DID – A re-specification of the classical STRIDE taxonomy for the
   decentralized identity context, replacing implicit assumptions about
   centralized control with explicit definitions applicable to DID/SSI
   architectures.
   -

   K-Class (Key Lifecycle Failure) – A novel threat class with no
   equivalent in any existing framework. K-Class addresses failures in key
   generation, distribution, custody, rotation, recovery, and post-quantum
   migration—threats that are often irreversible in decentralized systems.
   -

   Attack Catalog – 50+ structured attacks with unique identifiers
   (DID-TM-ATK-xxx), CVSS-DID scoring, attack trees, and normative mitigation
   references.
   -

   Cryptographic Threat Analysis – Formal treatment of threats specific to
   VSS, ZKP, VDF, and threshold signature schemes, including algebraic
   assumption failures and side-channel vulnerabilities.
   -

   Normative Requirements – Security and privacy requirements
   (MUST/SHOULD/MAY) with a traceability matrix mapping each control to the
   specific threats it mitigates.
   -

   Compliance Alignment – Mappings to NIST SP 800-63, ISO 27001, SOC 2, and
   eIDAS 2.0.

Why This Matters for DID-KR

DID-KR defines three recovery types (Type A: Social Recovery, Type B:
Time-Locked Inheritance, Type C: MPC-Mediated Recovery). Each carries
distinct security and privacy risks that cannot be adequately described
using generic threat models. DID-TM formalizes these risks:

   -

   Type A (Social Recovery) – Key threats include guardian collusion
   (ATK-400), share pollution (ATK-403), and Sybil attacks on guardian
   networks (ATK-500).
   -

   Type B (Time-Locked Inheritance) – Key threats include VDF difficulty
   miscalibration (ATK-402), ASIC hardware advantage (ATK-430), and Wesolowski
   proof forgery (ATK-431).
   -

   Type C (MPC-Mediated Recovery) – Key threats include MPC epoch share
   drift (ATK-401), refresh desynchronization, and fROST nonce reuse (ATK-440).
   -

   Cross-Cutting – Key threats include recovery loop deadlock (ATK-404),
   governance attacks on DID method registries (ATK-502), and cross-DID
   correlation via resolver logs (ATK-501).

Call for Community Feedback

We are seeking the community's views on:

   1.

   Completeness – Are there threat categories or attack vectors we have
   missed? The K-Class is our primary novel contribution—does it adequately
   capture key lifecycle risks across different DID methods?
   2.

   CVSS-DID Metrics – Our extension adds Decentralization Factor (DF),
   Recovery Availability (RA), Threshold Collusion (TC), and Quantum Advantage
   (QA). Do these metrics meaningfully improve vulnerability assessment for
   DID systems?
   3.

   Traceability – The threat-to-control matrix links each attack to
   normative requirements. Is this level of traceability appropriate for
   inclusion in a W3C CCG work item?
   4.

   DID Method Profiles – Section 28 provides security profiles for did:web,
   did:key, did:ion, and did:peer. Should additional methods be profiled
   before adoption?
   5.

   Integration Path – How should DID-TM relate to DID-KR and other CCG work
   items? Should it remain a separate specification with normative references,
   or be incorporated as an appendix to DID-KR?

We intend to:

   -

   Collect and incorporate community feedback on DID-TM
   -

   Finalize both DID-KR and DID-TM in parallel
   -

   Seek adoption of DID-KR as a formal CCG work item, with DID-TM as its
   companion security specification

Resources

   -

   DID-TM HTML Preview: https://sirraya-labs.github.io/did-tm/
   -

   DID-TM GitHub Repository: https://github.com/sirraya-labs/did-tm
   -

   DID-KR Specification: https://github.com/sirraya-labs/did-
   <https://github.com/sirraya-labs/did-tm>kr
   -

   Previous Discussion: Re: [PROPOSAL]: Adopt DID-KR Key Recovery Extension
   as a CCG Work Item from Amir Hameed on 2026-03-19
   (public-credentials@w3.org from March 2026)
   <https://lists.w3.org/Archives/Public/public-credentials/2026Mar/0095.html>

We welcome your thoughts, critiques, and suggestions. Your feedback is
essential to ensuring both specifications meet the needs of the
decentralized identity community.

Thank you,

Amir Hameed Mir
Sirraya Labs
amir@sirraya.org