Re: Guidance on Privacy/Security or Threat Models?

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]
<https://www.w3.org/blog/2019/web-authentication-level-1-is-a-w3c-recommendation/>

*Announcement:*
W3C confirmed Level 1 as a Recommendation in March 2019. [w3.org]
<https://www.w3.org/blog/2019/web-authentication-level-1-is-a-w3c-recommendation/>
------------------------------
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]
<https://www.w3.org/TR/webauthn-2/>

*W3C announcement:*
Level 2 was explicitly published as a Recommendation and described as a
maintenance update. [w3.org]
<https://www.w3.org/news/2021/web-authentication-an-api-for-accessing-public-key-credentials-level-2-is-a-w3c-recommendation/>
------------------------------
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]
<https://www.w3.org/TR/webauthn-3/>

*Status confirmation:*
The W3C states that Level 3 must demonstrate sufficient implementation
experience before advancing to Recommendation. [w3.org]
<https://www.w3.org/TR/webauthn-3/>
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
>
>