2024 07 15 Meeting Notes

2024-07-15 (A Call)

Organizer: Tim Cappalli

Scribe: Tim Cappalli

Agenda

• Continue Threat Modeling Discussion: https://github.com/WICG/digital-credentials/issues/115

Attendees

• Tim Cappalli (Okta)
• Nick Doty (CDT)
• Simone Onofri (W3C)
• Brian Campbell (Ping)
• Ben VanderSloot (Mozilla)
• Chris Needham (BBC)
• Ryan Galluzzo (NIST)
• Wendy Seltzer (Tucows)
• Hicham Lozi (Apple)
• Joseph Heenan (Authlete/OIDF)
• Hiroyuki Sano (Sony Group)
• Ted Thibodeau (OpenLink Software)
• Mike Jones

Notes

[Simone]

• Thanks to Nick for introducing this important topic
• During the discussion about adding this work to a WG, there was an ask to have a document analyzing the threats for decentralized identities and digital credentials
• Not just a threat model for the DC API, bigger discussion around privacy and threats for this technology area
• Privacy and security are tightly mixed together
• Two documents / deliverables / work items: first has begun (larger topic). Second is a threat model for the API itself, a subset of the bigger threat model specific to the API
• Thinking about proposing a community group for threat modeling. Touches on human rights, privacy, etc. Joint effort across groups.
• Contributions and expertise welcome to help understand the threats
• First question: need to understand the things we are building
• Second question: what are the threats? What can go wrong?
• What are the mitigations? Lots of talk about BBS+, for example. But not quantum proof…
• Need to have a security mechanism or algorithm for selective disclosure + post quantum proof
• Also connecting with some regulators as well, useful beyond the group
• Can also use privacy considerations and security considerations as inputs
• Also threat models specific to the wallet that can be contributed

[Manu]

• Fantastic that you're driving this work, glad it is finding a home. Hope it starts guiding other working groups, such as the VC WG, lots of it applies there. Even applies to mDL, which will go over the DC API, but not in W3C.
• How do we make sure it applies to the VC WG work, and even mDL over DC API? How do we make sure it "has teeth"?

[Simone]

• We want to collaborate with VC WG. Power of this work is just to be public. Been thinking about how it can be effective. We will understand the threats, and understand the mitigations, but someone can decide to not adopt.
• Feedback has been positive on the early work so far, even from outside
• Inside W3C, putting threat models as requirements for specs moving forward
• Goal is to publish formally at W3C
• Each protocol, format, element, etc., is being looked at; take each one and derive requirements

[Manu]

• What I'm hearing: focus on documenting things; once it is published, can figure how to apply to various specs over time

[Simone]

• Many protocols are from OIDF
• Studying a lot to understand all of these credentials and protocols
• Then understanding the architecture
• Linddun model to facilitate the work
• Need to have joint work with the spec developers and the people developing the technology
• Needs to be a living document and work with snapshots as threats evolve (e.g., ransomware 10 years ago vs today)

[Tim]

• What do you need from folks in this group to help?

[Simone]

• First is to review the issue
• Then we can start publishing as a document

[Paolo via chat]

• A threat model should have been utilized in the development of the protocol. Understanding this threat model is crucial, as the protocol itself should be designed to mitigate identified risks. Doing it ex-post facto sounds a bit weird

[Simone]

• During spec development, this should probably be done during the explainer phase
• Then evaluate during horizontal review
• Next steps: start to organize an interactive threat modeling session
• New work in IETF SPICE to be integrated into the threat model as well
• Balance of threat experts and spec experts

[Tom]

• Make sure we're talking about the same things
• E.g., informed consent
• Taxonomy would be helpful

[Ben]

• Identify some concrete things: e.g., actors; being able to talk about the same things

[Tom]

• Need to be careful about actors, could be protocol specific

[Ben]

• Need to have some commonality for the browser API layer, otherwise it is hard to reason about the assumptions we're making

[Simone]

• Thinking about: there should be a trust relationship between the holder and the verifier.
• What about browsers as a threat actor?
• Generic attacks, not an active actor, malware on devices with wallets, etc.
• tl;dr: lots of threat actors

[Tim]

• Mike, isn't there a venue at IETF for open security discussion?

[Mike]

• Security Area meeting, but that has a schedule
• You can schedule side meetings

[Tim]

• Next call is canceled for IETF
• Following call is an A call, normal agenda
• The next B call is tentatively going to be a presentation from Google about their ZKP scheme