Threat modelling, security & privacy (was FW: Guidance for VC WG please?)

Hi all,

Following discussions in the task forces and WG calls last week, I contacted W3C's security lead (Simone) seeking advice on how to handle the security and privacy sections of the many docs we have in flight. The response is detailed and, IMO, v helpful. I have forwarded the entire, unedited, exchange below. I included Hadley as a TAG co-chair as well as I'm anxious to engage the TAG sooner rather than later.

Summarizing Simone's recommendation

1. Complete the stand-alone threat model doc

2. Include S&P sections in each of our docs, highlight key points as they affect that specific doc, and point to threat model for more.

Completing the stand-alone doc makes is easier to meet the requirements of having inline S&P sections in each doc, so this is not duplicated effort.

Cheers

Phil

-----Original Message-----
From: Simone Onofri <simone@w3.org>
Sent: 10 April 2026 19:53
To: Phil Archer <phil.archer@gs1.org>
Cc: Hadley Beeman <hadley.beeman@gmail.com>; Brent Zundel <brent.zundel@gmail.com>; Ivan Herman <ivan@w3.org>; Tara Whalen <tara@w3.org>
Subject: Re: Guidance for VC WG please?

Hi Phil,

[cc’ing Tara for Privacy]

Thank you for the email and for the question.

For context, I think this is the earlier discussion here [1].

At a practical level, my reading is the following [2][3][4]:
- Specifications going for review should include in-line Security Considerations and Privacy Considerations sections
- A threat model is the structured way to develop the content of those sections
- If the threat model is small, it can be included directly in the specification; if it is larger, it can live in a separate document and be referenced from the in-line sections.

So, I would not frame this as “either the sections or the threat model”. Rather, the threat model should inform the sections, and may also be published separately when that is the more usable form.

I understand why the earlier answer may have sounded non-definitive. Part of the reason is that the Threat Modeling Guide explains how to do threat modeling while also leaving room for groups to apply it in ways that fit the technology they are standardizing. We are also still collecting implementation experience across groups, so it is useful to reason about concrete cases together.

I understand also that, with so many specs you are managing, the question is how to optimize the work, and, actually, the Threat Model is a way to do that better and speed up the reviews as well.

From the review perspective, however, the core point is simpler: reviewers need enough information to understand the system, the relevant threats, and how the specification responds to them, without having to reconstruct that reasoning from scratch.

The SPQ points to RFC 3552 for Security Considerations and RFC 6973 for Privacy Considerations. For security in particular, RFC 3552 section 5 says that authors must describe [4]:

- Which attacks are out of scope, and why
- Which attacks are in scope
- Which attacks the protocol is susceptible to
- Which attacks the protocol protect against

RFC 3552 gives a baseline set of attacks that specifications should consider (the Threat Model), from which the attacks were derived, and so consider in every protocol. In addition, the Security Considerations Section is the External Security Notes Section of a Threat Model.

Simplifying a bit, the Threat Modeling Guide structures the work around:
- What are we working on?
- Who is impacted?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?

In practice, that means:
- describing the system, usually with one or more diagrams;
- identifying the relevant actors and stakeholders;
- identifying the threats and attacks, including those affecting both the technology and the people involved;
- explaining the responses, mitigations, and any residual risk that is being accepted.

When the threat model is implicit, the reviewer often has to reconstruct the architecture, infer the threats, and then verify that the mitigations are present and correctly placed in the specification. That is where much of the review time is lost.

To summarize, the contents are similar, and I have made a diagram here showing how the various elements and their logical connections (okay, it's a graph!) [5].

A practical example is the Digital Credentials API, where we created a separate model from the Decentralized Credentials [6]:
 - In the Digital Credentials API, the WebIDL specifies that a Secure Context is required, which basically makes the API available only if you are under HTTPS and other conditions.
- In the Security Consideration Sections, we refer to the general Threat Model document, which specifies the threat of “Network Tampering”. In the Security Considerations section, this threat is declared in scope and explained, with mitigation details provided by referring to the Secure Context in the spec.

If that mapping is made explicit, the review becomes much easier. Often, these logical steps are missing, making it very difficult to understand what went through the mind of the person who wrote the specification.

Otherwise, if the mapping is implicit and there's no threat model, we have to recalculate it by understanding the technology (which normally takes me a lot of time if I'm not an expert in that specific technology), assessing the threats, and verifying that those threats have been mitigated correctly.

It may sound strange, but we do this thinking innately, and I think Verifiable Credentials is a way to have, yes, something cool online, but also to mitigate other identity models and address the threats of Tampering and Spoofing.

If that mapping is made explicit, the review becomes much easier.

So, in practical terms, my recommendation would be:
 1. Start from a separate threat model document, even if initially at a high level; for credentials, there is already draft work in that direction [6];
    1.a If a single threat model becomes too broad, split it by specification or layer, but cross-link them
    1.b If a threat model remains small and self-contained, it can be folded into the specification itself.
 2. In all cases, keep the inline Security Considerations and Privacy Considerations sections, and use them to summarize what is in scope for that specification and how the specification addresses those threats.

Why keep both the separate threat model and the inline sections?
- The detailed threat model can become long, and separating it can improve readability.
- The threat model can be useful beyond the specification text itself, including for implementers and for derivative analyses.
- The threat model published as a Note can evolve more easily as implementation experience accumulates and new threats become clearer, and this is also something that can help us to fulfill some directions provided by the UN OHCHR for human rights considerations (socio-technical threats)

In my view, this helps make security and privacy by design more explicit, improves reviewability, and reduces the likelihood of discovering important issues too late in the process, if the threat model starts in the early stages

Happy to discuss this further at SING/TMCG or in a future VC WG meeting.

Thank you,

Simone

[1] https://lists.w3.org/Archives/Public/public-security/2026Mar/0017.html

[2] https://www.w3.org/TR/security-privacy-questionnaire/

[3] https://www.w3.org/TR/threat-modeling-guide/

[4] https://datatracker.ietf.org/doc/html/rfc3552

[5] https://docs.google.com/presentation/d/1D1Wv3776ItFUQuEfWwSWT-jkQeA5c9I9n8a-QGcZNXY/edit?slide=id.g3871e0f896a_0_17#slide=id.g3871e0f896a_0_17

[6] https://w3c.github.io/threat-model-decentralized-credentials/


> On 7 Apr 2026, at 18:24, Phil Archer <phil.archer@gs1.org> wrote:
>
> Hi Simone and TAG Hadley,
>
> An issue just came up on one of our VCWG task forces that I know Manu has exchanged emails with Simone about but the outcome wasn't deterministic. So I've said I'll follow up with you directly.
>
> As the standards and technologies around Verifiable Credentials expand, we're really building the pieces of an ecosystem now. The basics are done, we're filling in the gaps and addressing some real world practicalities. See the list of Task Forces at https://www.w3.org/groups/wg/vc/task-forces/ and I know there's at least one more to come. The question then becomes: how should we be tackling security issues. Does each spec need its own threat model section, and security and privacy section, or can we point to an overall threat model doc for VCs and say that it covers those issues?
>
> Unless Brent says otherwise, I'd like to invite Simone and whichever TAG member Hadley deems appropriate to a future VC WG meeting if possible please? (ideally, but not necessarily on the same occasion) We now meet weekly on Wednesdays at 17:00 CET.
>
> Thanks
>
> Phil
>
>
> Phil Archer
> Web Solutions Director
> GS1 Global Office
> +44 7887 767755
> https://www.gs1.org

>
> https://philarcher.org

> https://mastodon.social/@PhilA

>
> CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are  confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium).
> If you are not the addressee, or if this has been copied or sent to you in error, you must not use data herein for any purpose, you must delete it, and should inform the sender.
> GS1 disclaims liability for accuracy or completeness, and opinions expressed are those of the author alone.
> GS1 may monitor communications.
> Third party rights acknowledged.
> (c) 2020.
>

CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are  confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium). 
If you are not the addressee, or if this has been copied or sent to you in error, you must not use data herein for any purpose, you must delete it, and should inform the sender. 
GS1 disclaims liability for accuracy or completeness, and opinions expressed are those of the author alone. 
GS1 may monitor communications. 
Third party rights acknowledged. 
(c) 2020.

Received on Monday, 13 April 2026 10:18:18 UTC