Re: Guidance on Privacy/Security or Threat Models?

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