- From: Simone Onofri <simone@w3.org>
- Date: Sun, 29 Mar 2026 12:06:06 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: public-security@w3.org, public-privacy@w3.org
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/ >
Received on Sunday, 29 March 2026 10:06:41 UTC