Re: Guidance on Privacy/Security or Threat Models?

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.
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.
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/
> >
>
>
>