Add Request/Respose Tampering Security Considerations - #493
Add Request/Respose Tampering Security Considerations#493simoneonofri wants to merge 10 commits into
Conversation
Related to: #479 - Added response and request tampering threats - Added a section for protocol considerations with tampering mitigations - Changed the other threat from Tampering to Network Tampering - Changed the normative/non-normative structure similar to WebAuthn, to have non-normative related to this API (as it refers to normative parts elsewhere), and normative parts for security requirements to the ecosystem. This new structure can also be useful to address this privacy-related issue #255 [follow-up from: #487]
simoneonofri
added
security-tracker
- Fix garbled in-scope threat text (broken merge of old/new wording)
- Rename "Tampering requests through the networks" to "Network Tampering"
- Fix Response Tampering description ("requests" → "responses")
- Fix plural link targets (presentation protocols → presentation protocol)
- Reframe MUST requirements from protocol conformance to user agent
conformance, per convention that RFC 2119 keywords only apply to
user agent requirements in this spec
- Remove contradictory intro sentence and note that claimed the spec
does not normatively require protocol properties
- Fix "at protocol level" → "at the protocol level"
- Normalize cross-ref case for [=response tampering=]
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
6c10c86 to
d647ec0
Compare
|
When reviewing the changes, please use https://github.com/w3c-fedid/digital-credentials/pull/493/changes?w=1 (hide whitespace) |
Remove class="informative" from the Threat Model and Security Considerations for the User Agent subsections. These sections define terms and describe mitigations used normatively elsewhere, so they should be normative. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
d647ec0 to
2c42318
Compare
The two subsections were nearly identical, differing only in "request" vs "response". A single MUST requirement covering both reduces duplication with the same normative effect. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add a paragraph after the protocols table pointing readers to the Security Considerations for Protocols section. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Merge the nearly identical Request Tampering and Response Tampering definitions into a single Protocol Tampering definition. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
afbfbec to
073758a
Compare
Remove incorrect reference to insecure contexts; the API requires secure contexts, so the threat is simply an attacker on the network attempting to modify content in transit. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
martinthomson
left a comment
martinthomson
left a comment
There was a problem hiding this comment.
I find these changes to be a little imprecise about what they are addressing.
This changes "Request Tampering" to "Network Tampering", which seems like it might be narrowing the scope unnecessarily. Attacks from the network are generally addressed using HTTPS, making the new scope uninteresting in the extreme. However, the original scope might have been read to include browsers, CDN operators, and others who had access to the messages.
Perhaps the intent here is to split those aspects out into the new "Data Tampering" section, but that is not particularly clear about which entities might be able to make those modifications.
As for mitigations, the use of digital signatures to counteract tampering is weird. It's not sufficient to say "just sign it". You need to have expectations about who is going to sign and with what key.
As for the new requirements on protocols, I can see how some people might have a threat model in which the proposed requirements become necessary, but the request/response integrity arrangement is not one that is consistent with my understanding of the web platform. A website that asks for information and is given that information is sufficient to address a need. That suffices.
That suggests that the decision to insist on tamper resistance extends beyond what is normal for the web platform. That means that stronger justification than what is provided for the requirement is needed.
Again, "just sign it" is an insufficient means of dealing with this problem as well.
marcoscaceres
left a comment
marcoscaceres
left a comment
There was a problem hiding this comment.
Your point that "just sign it" is an insufficient means of dealing with this problem is correct, and the gap you identified is real.
The intent behind the MUST is that the UA can only gate on whether a protocol defines integrity mechanisms — it cannot inspect runtime crypto. For government-issued identity documents, that gate matters: the issuer, wallet, user agent, and verifier form a chain of trust that doesn't exist in ordinary web content. But the spec currently requires only that mechanisms exist, not that they be adequate. A protocol could define signing with an ephemeral self-generated key and technically comply. That's not the bar we mean to set.
On the naming split: "Network Tampering" (in-transit, TLS handles it) and "Data Tampering" (post-creation at protocol level, TLS does not handle it) are intentionally separate. The rationale for the split needs to be in the text.
Your "who is going to sign and with what key" is the precise question the spec needs to answer. We'd welcome your help specifying what makes a mechanism adequate — the trust relationship requirements are exactly where the text needs more precision.
- Network Tampering: add sentence distinguishing it from Data Tampering; note that transport security (secure contexts) mitigates in-transit modification - Data Tampering: name the parties that may perform this attack (verifier, issuer, holder); clarify it occurs at the protocol level, not mitigated by transport security alone - Security Considerations for Protocols: add rationale paragraph before the MUST explaining why the UA gates on protocol-level integrity support (UA cannot inspect runtime crypto; only determines protocol support via userAgentAllowsProtocol)
I don't agree with this being in scope of the specification. Request signing and trust frameworks are very complex and vary drastically by region and use case. |
|
"Trust" is a dangerous word to use, and is inherently vague. I think there are many ways "trust" might be argued as beyond our charter. "Cryptographically sign", "cryptographically verify", and the like, and all their details, are much less vague and harder to argue as beyond our charter. |
|
Perhaps correct the PR title from |
There was a problem hiding this comment.
Pull request overview
Updates the Digital Credentials API specification’s security considerations to explicitly address protocol-level request/response tampering, and to normatively require integrity protections as a condition of protocol support.
Changes:
- Adds a cross-reference from the Protocols table to new “Security Considerations for Protocols”.
- Refines the threat model by distinguishing in-scope “Network Tampering” from out-of-scope “Data Tampering”.
- Introduces a normative requirement that a user agent MUST NOT support presentation/issuance protocols lacking request/response integrity mechanisms.
| Modification of a [=digital credential/presentation protocol=] or | ||
| [=digital credential/issuance protocol=] request or response by a | ||
| [=verifier=], [=issuer=], [=holder=], or other party in the exchange | ||
| after the message is created. Unlike [=network tampering=], this | ||
| threat occurs at the protocol level and is not mitigated by transport |
| A user agent MUST NOT support a [=digital credential/presentation | ||
| protocol=] or [=digital credential/issuance protocol=] unless the | ||
| protocol defines mechanisms that allow all parties to determine that a | ||
| request or response has not been modified after creation. In general, | ||
| this is achieved by signing requests and responses at the protocol |
Closes #479
Adds request and response tampering to the threat model and establishes normative integrity requirements for protocols used with the Digital Credentials API.
Why this matters
The DC API mediates access to digital credentials, including government-issued identity documents. It defines the user agent's mediation behavior, but does not by itself guarantee the end-to-end security of credential exchanges. That depends on the underlying protocols.
Without normative integrity requirements, the spec is silent on whether a protocol must protect requests and responses from modification. This gap leaves users exposed to tampering attacks at the protocol level, which the user agent cannot detect or prevent after handoff.
RFC 7258 (BCP 188) established the IETF consensus that known attacks must be mitigated in protocol design: "pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible." The same design principle applies to integrity attacks on credential exchanges. The W3C Ethical Web Principles (§2.6) cite RFC 7258 directly: "Our work should not enable state censorship, surveillance or other practices that seek to limit this freedom."
This PR applies that principle: a user agent MUST NOT support a protocol that lacks integrity mechanisms for requests and responses.
Changes
The following tasks have been completed:
Modified Web platform tests— no observable behavior changeImplementation commitment:
Documentation and checks
Follow-up from: #487
Preview | Diff