- From: Will Abramson <will@legreq.com>
- Date: Fri, 27 Mar 2026 11:16:20 +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: <CAPJWd2Q+SU86_C4B989uP5MSD=7n9cBmDQZwgvA8b4RGAMae0g@mail.gmail.com>
Thanks Amir, I appreciate this: > I hear you on the time constraints everyone is under. Our intention is pure: we want to ensure that if DID-KR is adopted, it is done so with a rigorous, dedicated security analysis. Also > *Specialized Scope:* While the general Threat Modelling Guide and the work led by Joe Andrieu are essential for the core DID/Resolution specs, DID-KR introduces three distinct recovery methods that we believe require a dedicated, granular threat profile. We view this not as a competing effort, but as a specialized extension that addresses risks unique to the recovery lifecycle—risks that might be too specific for the core modeling work. This is the correct approach. I do agree with you that the DID-KR work should have a threat model that addresses threats specific to the DID KR specification. I know the hope is that in future, all specifications will include a threat model. I do think the next step is to spin up this work item - I was not at the CCG call this week so I am not sure we announced it. Typically we like to adopt CCG work items on the call, although this is not a strict requirement. I would prefer if we adopt on the call. To do so, we will need to generate a CCG repo that uses the W3C ReSpec style for the specification, rather than the existing https://sirraya-labs.github.io/did-kr/. For example this is the repo for the recently adopted did:cel work item - https://github.com/w3c-ccg/did-cel-spec. I could not find a blank template unfortunately - perhaps someone else knows where one is? In terms of aligning your with the Security IG, if you have not already I encourage you to read through the guide https://w3c.github.io/threat-modeling-guide. Perhaps Simone and Joe can comment further. A good place to start would be attending the meetings if you are able to. Also, I would add that implementation experience of the DID KR spec you are trying to drive is always valuable. That may be somewhere you can independently focus your energy. Hope that helps, Will On Thu, Mar 26, 2026 at 2:59 PM Amir Hameed <amsaalegal@gmail.com> wrote: > Hi Will, > > Thank you for the candid feedback. I appreciate you taking the time to > share these resources and for pointing out the ongoing work within the DID > WG and the Security IG. > > I’d like to clarify , as there may be a slight misunderstanding regarding > the intent behind the DID-KR documentation. The goal was never to work in a > silo or bypass the community, but rather to provide a concrete "first > principles" foundation for feedback. > > Here are a few points for : > > - > > *Specialized Scope:* While the general Threat Modelling Guide and the > work led by Joe Andrieu are essential for the core DID/Resolution specs, > DID-KR introduces three distinct recovery methods that we believe require a > dedicated, granular threat profile. We view this not as a competing effort, > but as a specialized extension that addresses risks unique to the recovery > lifecycle—risks that might be too specific for the core modeling work. > - > > *A "DID-First" Implementation:* Our work has been built from the > ground up with a DID-native architecture. Naturally, this leads to some > architectural differences compared to legacy-adjacent models. Sharing the > document was intended to be an act of transparency—offering the community a > "working prototype" of a threat model to react to, rather than just an > abstract concept. > - > > *The "We":* To answer your question, "we" refers to the research team > at my lab (Sirraya Labs) and myself. While I do leverage AI as a > sophisticated collaborator for refining technical documentation because I > am a non-English individual, the architectural logic and cryptographic > foundations are driven by our team’s research. > > I hear you on the time constraints everyone is under. Our intention is > pure: we want to ensure that if DID-KR is adopted, it is done so with a > rigorous, dedicated security analysis. > > I am more than happy to align our efforts with the Security IG or Joe’s > work to ensure we aren't duplicating labor. Let me know the best way to > integrate these specific KR recovery profiles into the broader W3C security > discussions. > > Best regards, > > Amir > > On Thu, 26 Mar 2026 at 20:17, Will Abramson <will@legreq.com> wrote: > >> 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 Friday, 27 March 2026 11:16:37 UTC