Re: Guidance on Privacy/Security or Threat Models?

Hi all,

Thanks for the discussion, some points.

# Living Threat Models and updating RECs

Yes, in the Threat Modeling Guide (TMG) we wrote “The best threat models are living documents” [1], which is why in general it makes sense to me to keep them as Group Notes and more easily updatable than a REC, and then have the Security Consideration sections as “External Notes” (in practical terms, the group tell you what they did in the REC with respect to the identified threats).

Obviously, the question is finding a good way to synchronize Threat Models with Consideration sections (or finding a way to make it easy/automatic), so as not to overload the working groups (in any case, reasoning with threat models was already specified long ago in the S&P questionnaire; what we're doing here is making the approach easier).

To update RECs, the W3C Process provides an option to do so; the issue is coded here in case of vulnerabilities. doable e indeed [2].

# Threat Model for Security and Privacy 

On the issue of avoiding doing two Threat Model Security and Privacy, it doesn't impose an excessive burden on the groups, in particular when we use an integrated/modular approach (and a few days ago I read a paper by Nick Doty where he said a similar thing [3]). Going in phases from the TMG:

- Model the system: this is something in the domain expertise of the person who writes the specification, explaining what their technology does.
I can put myself with my Security hat on, I need to reverse engieering what the group had in their heads, but it takes a lot of my time (then this could be in an explainer, in a separate Group Note, in the specification, the important thing is that we have this information) particularly if there is no diagram to reason about. This step takes the most time, especially for longer specs. And this is needed both for Security and Privacy reviews.

- Identify & Evaluate Stakeholders: This is a step we've made explicit, but it's basically understanding the impacted users.
Also, here, domain expertise of the specification is needed (for example, if we think about Accessibility, there is granularity of different impacted categories of users that have visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities… so we can have an Accessibility Threat Model, too).

- Identity & Evaluate Threats: This is where basically the expertise of the horizontal groups is useful, but on the flip side, there are simplified frameworks for enumerating both Privacy and Security threats (and the security review process is aligned with the privacy review process [4]). Basically we do the same thing: we analyze the data/element/user flows (identified in the previous steps, and if I have a diagram to follow and a list of elements in a table, I make it faster that I don't have to create it myself) and we identify the threats that insist using the different angles (Security: STRIDE, RFC 3552; Privacy: LINDDUN, RFC 6973) and we also have specific items in the S&P Questionnarie [5] (SOP Violation, 3P Tracking, Legitimate Misuse) and in addition the Mitigating Browser Fingerprinting [6] documet. So, in the same Threat Model, there can be Security and Privacy threats in two different sections (fingerprinting also impacts security). Moreover, at this stage - having the stakeholders made explicit - we can also easily identify the threats from the system to the users (societal impact, harms, etc.).

- Consider Responses: for identified threats, horizontal groups can recommend remediation (or a good exit criteria), but then it is the group that writes the specification that decides and updates the specification with mitigation and residual threats that they accept.

- Publication for consideration: on the one hand, for transparency, since our work is open, and on the other hand, because it's useful for implementers, and so as to understand post-implementation as well.

- Iteration: As the threats are evolving, the story never ends, and this also allows us to monitor it post-implementation. This has already happened at W3C, for example, with the Vibration API, which, after several post-implementation abuses, is now quite a work in progress [7].

So the purpose of this is not to make things more complicated, but to “standardize” the activities already defined more effectively (since the process we use in Security and Privacy is similar) and to provide the necessary tools to speed them up and reduce hassle for everyone.

As Joe wrote, it might be more practical to have a separate document, and maybe having a registry with examples to reference and “import” might make it easier?

Thank you,

Simone


[1] https://www.w3.org/TR/threat-modeling-guide/#when-to-threat-model-at-the-w3c
[2] https://w3c.github.io/security-disclosure/
[3] https://npdoty.name/writing/privacy-reviews/iwpe/npd-reviewing-iwpe.pdf
[4] https://github.com/w3c/securityig/blob/main/administration/how-to-review.md 
[5] https://www.w3.org/TR/security-privacy-questionnaire/
[6] https://www.w3.org/TR/fingerprinting-guidance/
[7] https://github.com/w3c/vibration/issues/33



> On 29 Mar 2026, at 20:28, Tom Jones <thomasclinganjones@gmail.com> wrote:
> 
> I belong to the threat modeling school that believes a TM should be updated, preferably yearly, as a standard security check.
> The result of the new TM might require an update to the spec, but it certainly acts as an update for the dev team.
> From a practical perspective, I guess the W3C process seems to work, but I really don't like it.  Here is an AI example from one such effort.
> Note that while a new std is being developed, developers cannot easily access defects in the older specification with this approach.
> Joe's ideas may be ok.
> Perhaps others have an opinion?  ..tom
> 
> the formal (“final”) W3C publications for Web Authentication (WebAuthn) Levels 1, 2, and 3, with their official status, publication dates, and canonical specification links - being precise about status because only Levels 1 and 2 are final W3C Recommendations; Level 3 is not yet final.
> WebAuthn Level 1 — Final
> Official title: Web Authentication: An API for accessing Public Key Credentials — Level 1
> W3C status: W3C Recommendation (final standard)
> Publication date: 4 March 2019 (announced 10 March 2019)
> What this means: This is the first fully ratified WebAuthn standard and is considered stable and normative.
> Canonical spec (TR):
> https://www.w3.org/TR/webauthn/ [w3.org]
> Announcement:
> W3C confirmed Level 1 as a Recommendation in March 2019. [w3.org]
> WebAuthn Level 2 — Final
> Official title: Web Authentication: An API for accessing Public Key Credentials — Level 2
> W3C status: W3C Recommendation (final standard)
> Publication date: 8 April 2021
> What this means: Level 2 supersedes Level 1 and is the current fully ratified version of WebAuthn.
> Canonical spec (TR):
> https://www.w3.org/TR/webauthn-2/ [w3.org]
> W3C announcement:
> Level 2 was explicitly published as a Recommendation and described as a maintenance update. [w3.org]
> WebAuthn Level 3 — NOT final
> Official title: Web Authentication: An API for accessing Public Key Credentials — Level 3
> W3C status: Candidate Recommendation Snapshot (not final)
> Publication date (CR snapshot): 13 January 2026
> What this means:
>     • Level 3 is still in the standards track
>     • It is explicitly marked as “may be updated, replaced, or obsoleted”
>     • It has not yet reached Recommendation status
> Current spec (TR):
> https://www.w3.org/TR/webauthn-3/ [w3.org]
> Status confirmation:
> The W3C states that Level 3 must demonstrate sufficient implementation experience before advancing to Recommendation. [w3.org]
> Peace ..tom jones
> 
> On Sun, Mar 29, 2026 at 11:22 AM Joe Andrieu <joe@legreq.com> wrote:
> 
> 
> On Sun, Mar 29, 2026 at 10:03 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
> I guess what you are saying is that a w3c standard requires a threat analysis (mitigations, acceptances, etc.) as well as a threat model.
> I really don't like this idea because it seems to assume that the final word on the threats and mitigations can be known at spec time.  This is demonstrably false.
> 
> No one is suggesting that any of these threat models are the final word, especially not at spec-time.
> 
> Instead, what they are is the best thinking **by those who created the specification** about the threats understood when the spec was written. Its more a form of self-disclosure than a statement about "all the threats".
> 
> No threat model will ever be complete, IMO. Such a threat model would have to encompass so many threats as to be unwieldy. Should the CSS specification worry about fraudulent silicon on an Apple smartphone? What about algorithmic errors in the crypto that secures TLS? Or the risks of extracting browser information through clever font manipulation?
> 
> Clearly, some would find these reasonable threats, given a threat model that has included these elements for consideration. But somewhere, the threat modeler has to draw the line and set the scope of the inquiry. That's why the diagram is such an important element in how we (at the W3C are approaching threat modeling. If the possibly fraudulent silicon isn't represented in the diagram, it is out of scope. If the crypto algorithm (or at least a process running that algorithm) isn't in the diagram, it is out of scope.  
> 
> Other threat models will have their own locus of attention. There could be/should be hardware analyses that *do* care about electronic supply chain questions. There could/should be algorithmic evaluations that do care about the quality of the algorithm *and* its implementation in hardware and software. They just don't all need to be in the same diagram, nor do they need to be in the same threat model.
>  Worst it doesn't allow for updates to the analysis which might be required during the lifetime of the standard.
> Perhaps a better approach would be to attach an analysis to the standard as released and updated from time to time without requiring an update on the spec?
> just my thoughts of the moment.
> 
> Ah... now this I like, actually.
> 
> I think we should explore how a threat model can be set up as a W3C registry so that additional threats and responses can be added even after the WG is done with the work.
> 
> That's probably the right way to maintain an ongoing perspective on threats for a given specification.
> 
> -j
> 
>  Peace ..tom jones
> 
> 
> On Sun, Mar 29, 2026 at 3:06 AM Simone Onofri <simone@w3.org> wrote:
> Hi Manu,
> 
> Nice question :)
> 
> From the literature, we can say that the Security Consideration Section is the "External Security Notes” section of a classic Threat Model.
> 
> In this particular case, the issue is that the specification needs to contain enough information (e.g., use case(s), diagram(s), elements, threats considered, how the standard responds to these threats, and residual threats accepted) so that even a reviewer w/o previous knowledge of the technology can understand these elements without reverse engineering everything to figure out what was in the editors' heads.
> 
> For example, with the Digital Credentials API, we have a separate Threat Model (which also includes adjacent layers) and Security Considerations, and we also discussed this at TPAC, both as a matter of length and because in that case the Threat Model was used as an ongoing tool to understand the threats and the Security Consideration sections to map the threats, and how they were mitigated within the specification.
> 
> A further thought, derived from these reasonings, is that the audience of a specification is not only the implementers, but also the reviewers (whether design, security, privacy, accessibility, internationalization), and they need to be given enough information (or pointers to that information) to be able to make revisions quickly and limit back-and-forths (not because they are not useful, on the contrary, but because they often require time and synchronization).
> 
> For now, a common approach for review (I was reading the Privacy documentation, too) is precisely to understand the use cases (which are in the first sections of a specification), and then to use as a drive the security consideration sections to understand what the threats are and how they are managed, according to where the data pass (which is why one or more diagrams are useful).
> 
> Thank you,
> 
> Simone
> 
> > On 24 Mar 2026, at 14:52, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > 
> > Hi W3C Security and Privacy groups,
> > 
> > We are getting ready to move a few Credential Community Group
> > specifications over to the W3C Verifiable Credentials Working Group.
> > We need to complete the Privacy and Security Considerations sections
> > /or/ replace them with a "Threat Model" section before we request
> > horizontal review. We would prefer to do the latter (just one Threat
> > Model section), as the former feels like it will repeat a lot of the
> > information that ends up being contained in the latter.
> > 
> > We have not yet published FPWDs for these documents, and so would like
> > to use our time most effectively on the privacy and security / threat
> > model work. The worst outcome for us is to have to create a privacy,
> > security, AND threat model.
> > 
> > At this point in time, what is considered the best practice?
> > 
> > For example, is it considered a best practice at present to replace
> > the Privacy and Security Considerations sections with a Threat Model
> > section?
> > 
> > -- manu
> > 
> > -- 
> > Manu Sporny - https://www.linkedin.com/in/manusporny/
> > Founder/CEO - Digital Bazaar, Inc.
> > https://www.digitalbazaar.com/
> > 
> 
> 
> 
> 
> -- 
> Joe Andrieu
> President
> joe@legreq.com
> +1(805)705-8651
> Legendary Requirements
> https://legreq.com
>

Received on Tuesday, 31 March 2026 11:02:15 UTC