Refine processing expected_origins and processing steps#719
Conversation
awoie
requested review from
c2bo,
dpostnikov,
fkj,
jogu,
marcoscaceres and
martijnharing
Co-authored-by: Oliver Terbu <o.terbu@gmail.com>
|
I removed the term "opaque" as per WG consensus. |
awoie
changed the title
Co-authored-by: Oliver Terbu <o.terbu@gmail.com>
fkj
left a comment
fkj
left a comment
There was a problem hiding this comment.
I think the clarity could be improved by also adding text to note that an Origin can really be any string in the definition of Origin.
|
APAC DCP WG discussion:
|
Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com>
Co-authored-by: Oliver Terbu <o.terbu@gmail.com>
|
Discussed during call. In general Marco's proposed change seems fine, but it should have correct references and retain some example text. |
|
@marcoscaceres could you respond to comments made so far? |
|
I added the changes discussed in comments with the reference to the html origin terminology. I wasn't sure about the link to whatwg - in IETF we had to pin to a specific commit instead of the living standard , so I did the same here. |
| In addition to the above-mentioned parameters, a new parameter is introduced for OpenID4VP over the W3C Digital Credentials API: | ||
|
|
||
| * `expected_origins`: REQUIRED when signed requests defined in (#signed_request) are used with the Digital Credentials API (DC API). A non-empty array of strings, each string representing an Origin of the Verifier that is making the request. The Wallet MUST compare values in this parameter to the Origin to detect replay of the request from a malicious Verifier. If the Origin does not match any of the entries in `expected_origins`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. | ||
| * `expected_origins`: REQUIRED when signed requests defined in (#signed_request) are used with the Digital Credentials API (DC API). A non-empty array of strings, each string representing an Origin of the Verifier that is making the request. The Wallet MUST compare values in this parameter to the provided Origin, treated as a string, using simple string comparison, without any prior processing or interpretation of either the `expected_origins` values or the provided Origin, to detect replay of the request from a malicious Verifier. Values using unsafe or unsupported URI schemes, including `ftp`, `javascript`, `data`, `ws`, and `wss`, MUST NOT be used. Values using the http scheme MUST NOT be used unless they are explicitly allowed for constrained scenarios such as local development or equivalent non-production environments. If the Origin does not match any of the entries in `expected_origins`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. |
There was a problem hiding this comment.
It's not clear what "Values using unsafe or unsupported URI schemes" are, and the current list leaves it open ended. Would it be worthwhile to just restrict to http and https for now?
Similarly, the "Values using the http scheme MUST NOT be used unless they are explicitly allowed for constrained scenarios such as local development or equivalent non-production environments."
That's ambiguous. I think you want to go through the "is potentially trustworthy?" checks of the Secure Context spec. That covers the "local development or equivalent non-production environments" case unambiguously and safely.
There was a problem hiding this comment.
Since we also allow want to allow calls from other apps with an expected_origins value , we shouldn't restrict to http/https imho.
There was a problem hiding this comment.
WG discussion. given that there are use-cases for app-to-app, preference is to not limit it to http/https only.
we could quote https://www.w3.org/TR/secure-contexts/#is-url-trustworthy for the cases when values are http/https. @marcoscaceres is Secure context document published? it says [W3C Candidate Recommendation Draft](https://www.w3.org/standards/types#CRD), 10 November 2023 which means it's not a TR but URL says TR? if it's CR draft, then "These documents MUST NOT be cited as W3C standards and may or may not become W3C standards." ...
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
|
WG discussion: ready to merge once the last comment from marcos is resolved |
10 participants
Fixes #224