Security Considerations: Writing first round of threats and mitigatio…

[simoneonofri]

(Web API level)

A first draft of the identified threats and potential mitigations (some already applied), particularly at the Web API level.

Threats

• SOP Violation
• Fingerprinting and Cross-Device Tracking
• Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF)
• Clickjacking & UI redressing
• Reply Attack
• Quishing
• Phishing/Harvesting

Mitigations (already implemented or to be considered)

• Data Minimization
• Secure contexts
• Limit API usage
• Informing the user
• Transient activation

Things to consider:

• What else could go wrong (if there are other threats)
• What can we do about the threats we have identified
• Do we like the countermeasures we already have in place
• Are there other mitigations to consider or write down
• Overlaps/joint with Privacy

[cc'ing @Sh-Amir and @ZAnsaroudi]

---

Preview | Diff

[marcoscaceres]

This still feel overly broad and not necessarily related to the API.

[npdoty]

I don't understand "replacing" here. It seems like the attack is presenting the user with a maliciously-crafted QR code which when followed, will lead to a credential presentation request that will deliver the results to an unexpected party (either the attacker, or as a confused deputy confirming the user's identity for a request that the attacker made to some other verifier). Maybe the attacker is inserting it in a place where it looks to the user like a legitimate request from a different verifier, and that's a kind of replacement?

[simoneonofri]

For the framing I was giving it, the QR code is managed directly by the API and displayed securely and not via an (controlled by an adversary).

Does that make sense to you, or do you think we should frame it differently?

[simoneonofri]

@marcoscaceres @timcappalli @npdoty @RByers, thanks for the feedback. We did a full rewrite of the section here:
https://github.com/w3c-fedid/digital-credentials/wiki/Security-Considerations-Section

If you have any feedback/questions before Friday, they are welcome so we can converge on Friday

[TallTed]

@simoneonofri — I suggest moving the draft from the wiki, which is surprisingly difficult to edit (e.g., I have no edit link), to either a distinct fork, or a PR against the existing section, upon which it should be easy for any of us to submit suggested revisions. (One such revision is to change a number — but not all! — of instances of Digital Credentials to the singular, especially in the Digital Credential API which reads far better than the Digital Credentials API).

[RByers]

This new format looks really great to me @simoneonofri, thank you! Broadly this seems great.

@mohamedamir is going to go over details and suggest some edits. What's the best way to iterate on proposed edits? Want to copy the contents back into this PR or just all co-edit in the wiki for now?

[simoneonofri]

@RByers @mohamedamir @TallTed thank you.

We have been working on a Google Docs, if that's helpful, or where ever you prefer.

[marcoscaceres]

I still don't agree with this approach, as it still feels overly broad and doesn't say how the mitigations work. IMO, the way we should approach this as:

Preventing/how we prevented:

• Zero-click attacks
• One-click attacks
• Cross origin (ab)use cases

And group accordingly. We generally shouldn't need to explain each attack (we should definitely not redefine here what "secure context" means, for instance... we should just link to the definition), but how the attacks are directly mitigated by the choices we've explicitly made in the API design (and where some mitigations might fall short... for example, it's easy for sites to trick users to get "transient activation").

Further, there are "Security Considerations" that are beyond the scope of this specification (e.g., the format nonce requirement). We should be really mindful of where the spec has clearly mitigated something, and say exactly how or point to the right section of the spec.

[simoneonofri]

Thanks TallTed, RByers, @mohamedamir, marcoscaceres for the comments received.

To work best with the Group, we moved to Google Docs.

https://docs.google.com/document/d/1BpBBiv7GgkGi1_Y7NvyD3Mkalj0g857Qw-aan3NqYwU/edit?tab=t.0

This document is a work in progress for the Threat Modeling exercise for the Digital Credentials API, as also recommended by the Preventing Abuse of Digital Credentials.

If you would like to contribute, feel free to request permission to suggest and comment.

Since the DC API is part of a larger ecosystem, it includes an analysis of the Credentials layer, with a deep dive into the specific aspects of the Digital Credentials API and neighboring technologies at the same level, to ensure maximum safety for the end user.

Once sufficient refinement and consensus within the Group have been achieved, relevant threats will be documented in the Security Considerations sections of the specification.
In general, the “Security Considerations” sections serve as notes on external security in a threat model, and this document will be referred to in a Group Note.

The security considerations will follow the structure specified in RFC 3552, including a discussion of the following:

• What threats/attacks are in scope
• What threats/attacks are out of scope, and why
• Threats that the specification is susceptible to
• Residual risk to users, implementers, and related technologies
• Threats the standards protect against (with reference to the specific section of the standard)