- From: Will Abramson <will@legreq.com>
- Date: Thu, 26 Mar 2026 14:47:25 +0000
- To: Amir Hameed <amsaalegal@gmail.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>, Joe Andrieu <joe@legreq.com>, Simone Onofri <simone@w3.org>
- Message-ID: <CAPJWd2Qi--MpvtMO1VYd9U2ZBFwrf3TVM=dmb8=QTEzrF8L6yw@mail.gmail.com>
Hi Amir, I appreciate your enthusiasm. However, can I suggest that instead of going off and independently producing a large document and then asking the community to engage with and adopt your work, that you first engage with the community. If you had done so, you might have learnt that there is extensive work going into threat modelling at the W3C and within the DID WG at the moment. For example, with the development of the Threat Modelling Guide https://w3c.github.io/threat-modeling-guide/ and from the Security Interest Group led by Simone - https://www.w3.org/groups/ig/security/ Additionally, just this Tuesday a session was held on DID Resolution threat modelling as part of the Threat Modelling Community Group. Joe Andrieu is actively leading a DID threat modelling effort for both the DID and DID Resolution specification for the DID WG. Your contributions would be most welcome to any of these efforts. This is how work gets done at within the CCG and the wider W3C - collaboratively. Also, can I confirm who we is in this instance? Is it you and your AI collaborator? Please reconsider how you engage with this community, we could really use active collaborators working with us to move the work forwards. However, we are all time constrained and cannot spend the time necessary to meaningfully engage with the content you keep sharing. Happy to chat with you about this further if you have any questions. Thank you, Will On Thu, Mar 26, 2026 at 1:27 PM Amir Hameed <amsaalegal@gmail.com> wrote: > 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 >
Received on Thursday, 26 March 2026 14:47:43 UTC