Skip to content

Refine processing expected_origins and processing steps #719

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
awoie wants to merge 17 commits into
base: main
Choose a base branch
from
Open

Refine processing expected_origins and processing steps #719

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
e7992bb
clarify origin is an opaque string incl errata
awoie Apr 16, 2026
34938f7
updated errata
awoie Apr 16, 2026
725f539
fix doc history
awoie Apr 16, 2026
5a85931
undo line remove
awoie Apr 16, 2026
5314027
add trust assumption
awoie Apr 16, 2026
a0e649f
clarify no prior processing of expected_origins / provided Origin is …
awoie Apr 16, 2026
58b4527
Remove "opaque" as per DCG feedback
awoie Apr 16, 2026
eb30c93
Refined wording
awoie Apr 16, 2026
71f8ed9
Applied Frederik's suggestion
awoie Apr 23, 2026
681d67a
Applied Frederik's suggestion
awoie Apr 23, 2026
3cbf51a
Apply suggestion from @awoie
brentzundel Apr 27, 2026
a7a8f3b
Merge branch 'main' into awoie/fix-224
paulbastian May 7, 2026
45db976
Merge branch 'main' into awoie/fix-224
brentzundel May 15, 2026
365edca
incorporate proposal to reference html origin
c2bo Jun 22, 2026
3dae756
change links to html spec (origin reference)
c2bo Jun 29, 2026
6cf00bf
Merge branch 'main' into awoie/fix-224
c2bo Jun 29, 2026
6b07092
Apply suggestions from Marcos' code review
Sakurann Jul 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 16 additions & 3 deletions 1.0/openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -121,7 +121,7 @@ Issuer-Holder-Verifier Model:
: A model for exchanging claims, where claims are issued in the form of Credentials independent of the process of presenting them as Presentations to the Verifiers. An issued Credential may be used multiple times.

Origin:
: An identifier for the calling website or native application, asserted by the web or app platform. A web origin is the combination of a scheme/protocol, host, and port, with port being omitted when it matches the default port of the scheme. An app platform may use a linked web origin, or use a platform-specific URI for the app origin. For example, the Verifier for the organization MyExampleOrg is served from https://verify.example.com. The web origin is `https://verify.example.com` with `https` being the scheme, `verify.example.com` being the host, and the port is not explicitly included as `443` is the default port for the protocol `https`. The native applications origin on some platforms will also be `https://verify.example.com` and on other platforms, may be `platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0`.
: An identifier for the calling website or native application, asserted by the underlying web or application platform. For Web-based callers, the Origin is an opaque `origin` or `tuple origin` as defined in the "Origins" section of [@!whatwg.html]. For native application callers, the Origin follows a platform-specific convention. Some platforms use a linked web origin, while others use a platform-specific application origin. For example, the Verifier for the organization MyExampleOrg is served from https://verify.example.com. The corresponding web Origin is https://verify.example.com, where https is the scheme, verify.example.com is the host, and the port is not explicitly included because 443 is the default port for https. On some platforms, a native application uses the same Origin, while on others it uses a platform-specific value such as platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0. The Origin provided by the underlying platform is outside the scope of this specification and MUST be treated as an opaque string.

Presentation:
: Data that is presented to a specific Verifier, derived from a Credential. In this specification, Presentations are usually Verifiable Presentations including Holder Binding (as defined below), but may also be Presentations without Holder Binding (discussed in (#nkb-credentials)).
Expand Down Expand Up @@ -2389,6 +2389,17 @@ Ecosystems intending to use trusted authority mechanisms SHOULD ensure that the
</front>
</reference>

<reference anchor="whatwg.html" target="https://html.spec.whatwg.org#concept-origin">
<front>
<title>HTML - Living Standard</title>
<author>
<organization>WHATWG</organization>
</author>
<date day="22" month="June" year="2026"/>
</front>
<annotation>Commit snapshot: https://html.spec.whatwg.org/commit-snapshots/c560a56704e7a31887ab79299d30e6f68d696cf4/#concept-origin</annotation>
</reference>

# OpenID4VP over the Digital Credentials API {#dc_api}

This section defines how to use OpenID4VP with the Digital Credentials API.
Expand All @@ -2410,7 +2421,7 @@ Secondly, the session with the End-User will always continue in the initial cont

Thirdly, cross-device requests benefit from the use of secure transports with proximity checks, which are handled by the OS platform, e.g., using FIDO CTAP 2.2 with hybrid transports.

And lastly, as part of the request, the Wallet is provided with information about the Verifier's Origin as authenticated by the user agent, which is important for phishing resistance.
And lastly, as part of the request, the Wallet is provided with information about the Verifier's Origin as authenticated by the trusted platform (i.e. user agent), which is important for phishing resistance.
Comment thread
awoie marked this conversation as resolved.

## Protocol

Expand Down Expand Up @@ -2461,7 +2472,7 @@ The value of the `response_mode` parameter MUST be `dc_api` when the response is

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.

@marcoscaceres marcoscaceres Jun 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@c2bo c2bo Jun 29, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we also allow want to allow calls from other apps with an expected_origins value , we shouldn't restrict to http/https imho.

@Sakurann Sakurann Jul 2, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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." ...


The transport of the request and Origin to the Wallet is platform-specific and is out of scope of OpenID4VP over the Digital Credentials API.

Expand Down Expand Up @@ -3593,6 +3604,8 @@ The technology described in this specification was made available from contribut
* Clarify nonce entropy requirements
* Clarify that state is recommended to match text from Section 14.3.2. Protection of the Response URI
* Clarify that `encrypted_response_enc_values_supported` applies only if JWE content encryption algorithm is used
* Clarify provided Origin is a string without prior interpretation and validation is based on simple string comparison
* Add assumption that the platform that provides the Origin is trusted
* Clarified intent_to_retain value when not present
* Removed invalid_scope error guidance as duplicate of RFC6749
* Clarified that Multi-RP-sig section means Verifier Info instead of attestations
Expand Down
19 changes: 16 additions & 3 deletions 1.1/openid-4-verifiable-presentations-1_1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,7 +117,7 @@ Issuer-Holder-Verifier Model:
: A model for exchanging claims, where claims are issued in the form of Credentials independent of the process of presenting them as Presentations to the Verifiers. An issued Credential may be used multiple times.

Origin:
: An identifier for the calling website or native application, asserted by the web or app platform. A web origin is the combination of a scheme/protocol, host, and port, with port being omitted when it matches the default port of the scheme. An app platform may use a linked web origin, or use a platform-specific URI for the app origin. For example, the Verifier for the organization MyExampleOrg is served from https://verify.example.com. The web origin is `https://verify.example.com` with `https` being the scheme, `verify.example.com` being the host, and the port is not explicitly included as `443` is the default port for the protocol `https`. The native applications origin on some platforms will also be `https://verify.example.com` and on other platforms, may be `platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0`.
: An identifier for the calling website or native application, asserted by the underlying web or application platform. For Web-based callers, the Origin is an opaque `origin` or `tuple origin` as defined in the "Origins" section of [@!whatwg.html]. For native application callers, the Origin follows a platform-specific convention. Some platforms use a linked web origin, while others use a platform-specific application origin. For example, the Verifier for the organization MyExampleOrg is served from https://verify.example.com. The corresponding web Origin is https://verify.example.com, where https is the scheme, verify.example.com is the host, and the port is not explicitly included because 443 is the default port for https. On some platforms, a native application uses the same Origin, while on others it uses a platform-specific value such as platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0. The Origin provided by the underlying platform is outside the scope of this specification and MUST be treated as an opaque string.

Presentation:
: Data that is presented to a specific Verifier, derived from a Credential. In this specification, Presentations are usually Verifiable Presentations including Holder Binding (as defined below), but may also be Presentations without Holder Binding (discussed in (#nkb-credentials)).
Expand Down Expand Up @@ -2453,6 +2453,17 @@ Ecosystems intending to use trusted authority mechanisms SHOULD ensure that the
</front>
</reference>

<reference anchor="whatwg.html" target="https://html.spec.whatwg.org#concept-origin">
<front>
<title>HTML - Living Standard</title>
<author>
<organization>WHATWG</organization>
</author>
<date day="22" month="June" year="2026"/>
</front>
<annotation>Commit snapshot: https://html.spec.whatwg.org/commit-snapshots/c560a56704e7a31887ab79299d30e6f68d696cf4/#concept-origin</annotation>
</reference>

# OpenID4VP over the Digital Credentials API {#dc_api}

This section defines how to use OpenID4VP with the Digital Credentials API.
Expand All @@ -2474,7 +2485,7 @@ Secondly, the session with the End-User will always continue in the initial cont

Thirdly, cross-device requests benefit from the use of secure transports with proximity checks, which are handled by the OS platform, e.g., using FIDO CTAP 2.2 with hybrid transports.

And lastly, as part of the request, the Wallet is provided with information about the Verifier's Origin as authenticated by the user agent, which is important for phishing resistance.
And lastly, as part of the request, the Wallet is provided with information about the Verifier's Origin as authenticated by the trusted platform (i.e., user agent), which is important for phishing resistance.

## Protocol

Expand Down Expand Up @@ -2525,7 +2536,7 @@ The value of the `response_mode` parameter MUST be `dc_api` when the response is

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.

The transport of the request and Origin to the Wallet is platform-specific and is out of scope of OpenID4VP over the Digital Credentials API.

Expand Down Expand Up @@ -3660,6 +3671,8 @@ The technology described in this specification was made available from contribut
* Add security consideration not to use VP Token as Access Token
* Clarify that state is recommended to match text from Section 14.3.2. Protection of the Response URI
* Clarify that `encrypted_response_enc_values_supported` applies only if JWE content encryption algorithm is used; e.g., it does not apply to JOSE HPKE
* Clarify provided Origin is a string without prior interpretation and validation is based on simple string comparison
* Add assumption that the platform that provides the Origin is trusted
* Clarify that `aud` corresponds to `issuer` Wallet Metadata paremeter if Dynamic Discovery is used
* Clarified `intent_to_retain` value when not present
* Removed invalid_scope error guidance as duplicate of RFC6749
Expand Down
Loading