You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At W3C, we are working on the Threat Model for the Web. Last year, in breakout session #53, we started from a very basic but important question: “What are we working on?”. The answer was not obvious, because before modeling threats to the Web, we first need to understand what “the Web” is, at least from a security point of view.
This session is a follow-up to that discussion.
The goal is to collaboratively map the Web Security Model: the main components, assumptions, trust boundaries, and security responsibilities that Web specifications usually rely on when a new Web API is designed.
The point is to identify a baseline model (the highest part of the current diagram we have in the Threat Model for the Web) that can be reused by specification authors and reviewers when they need to reason about security by design.
In particular, I would like to discuss elements such as Web content, origins, user agents, browser UI, permission and mediation mechanisms. For each of these, we should try to understand what security properties are provided by the Web Platform, what remains API-specific, and where residual risks usually appear.
The expected outputs is a set of shared notes, and possibly one or more diagrams, that will be used to update the Threat Model for the Web.
Then, this work should help us create a boilerplate security model for designing Web APIs in a secure-by-design way. This may also inform future updates to the W3C Security and Privacy Questionnaire, so that new specifications can start from a common Web security baseline before analyzing their own feature-specific threats.
Type
Onsite
Other comments
This is intended as a working session, not just as a presentation.
Logistics
Facilitator(s)
@simoneonofri (W3C) @BDADAD-stack (FBK)
Summary
At W3C, we are working on the Threat Model for the Web. Last year, in breakout session #53, we started from a very basic but important question: “What are we working on?”. The answer was not obvious, because before modeling threats to the Web, we first need to understand what “the Web” is, at least from a security point of view.
This session is a follow-up to that discussion.
The goal is to collaboratively map the Web Security Model: the main components, assumptions, trust boundaries, and security responsibilities that Web specifications usually rely on when a new Web API is designed.
The point is to identify a baseline model (the highest part of the current diagram we have in the Threat Model for the Web) that can be reused by specification authors and reviewers when they need to reason about security by design.
In particular, I would like to discuss elements such as Web content, origins, user agents, browser UI, permission and mediation mechanisms. For each of these, we should try to understand what security properties are provided by the Web Platform, what remains API-specific, and where residual risks usually appear.
The expected outputs is a set of shared notes, and possibly one or more diagrams, that will be used to update the Threat Model for the Web.
Then, this work should help us create a boilerplate security model for designing Web APIs in a secure-by-design way. This may also inform future updates to the W3C Security and Privacy Questionnaire, so that new specifications can start from a common Web security baseline before analyzing their own feature-specific threats.
Type
Onsite
Other comments
This is intended as a working session, not just as a presentation.
A possible structure could be:
I would be happy to facilitate it on-site if travel and logistics allow it.