Refine processing expected_origins and processing steps by awoie · Pull Request #719 · openid/OpenID4VP

awoie · 2026-04-16T14:38:37Z

Fixes #224

…needed

Co-authored-by: Oliver Terbu <o.terbu@gmail.com>

awoie · 2026-04-16T15:47:20Z

I removed the term "opaque" as per WG consensus.

Co-authored-by: Oliver Terbu <o.terbu@gmail.com>

fkj

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.

fkj · 2026-04-20T09:12:47Z

 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 (e.g., user agent), which is important for phishing resistance.


Same comment as above regarding other trusted platforms than user agents.

Sakurann · 2026-04-22T08:53:08Z

APAC DCP WG discussion:

to resolve Clarifications on processing expected_origins and processing steps #224,
- current text looks good to clarify origin is a string and must not be parsed
- suggestion is to add to this PR clarification of origin definition for non-native app RPs. @fkj will make a suggestion
keep discussion of native app origin value out of scope of this PR and continue that discussion in Handling of origin in Native Mobile Platform App to App flows for DC API #646

Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com>

Co-authored-by: Oliver Terbu <o.terbu@gmail.com>

lj-raidiam · 2026-04-27T17:18:21Z

 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`.
+Origin:
+: An identifier for the calling website or native application, asserted by the web or app platform. The Origin is any string, but will typically follow a platform-specific convention. 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`.


We use the terms "app origin" and "web origin" here, where "app origin" can be a URI. Could we reference the relevant RFCs for clarity? WDYT @awoie @fkj?
If this suggestion is added, RFC 6454 should be added to the references at the bottom.

Suggested change

: An identifier for the calling website or native application, asserted by the web or app platform. The Origin is any string, but will typically follow a platform-specific convention. 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 web or app platform. The Origin is any string, but will typically follow a platform-specific convention. A web origin follows scheme, host, and port convention defined in [@!RFC6454], 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 syntax as defined by [@!RFC3986] 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`.

I don't see why not, it might add some clarity.

I don’t think that’s the right spec. Browser and most modern URL implementations use WHATWG URL.

Similarly, origin you probably want :
https://html.spec.whatwg.org/multipage/browsers.html#concept-origin

Generally, please avoid redefining what’s in other specs. Subtle wording differences can lead to confusion.

marcoscaceres · 2026-05-01T02:59:12Z

 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`.
+Origin:
+: An identifier for the calling website or native application, asserted by the web or app platform. The Origin is any string, but will typically follow a platform-specific convention. 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`.


I think this is all you want here, but check:

Suggested change

: An identifier for the calling website or native application, asserted by the web or app platform. The Origin is any string, but will typically follow a platform-specific convention. 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 [origin](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin) or an [opaque origin](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-opaque) [[HTML]]. See [7.1.1 Origins](https://html.spec.whatwg.org/multipage/browsers.html#origin) of HTML for details.

Good point. I think we were not previously aware that WHATWG actually defined the opaque origin as a concept. I still think it might be relevant to say that the opaque origin is platform-specific.

We should still preserve text with examples about platform-provided origin (app-to-app) imho. Even if we re-use other, existing terminology. I believe we should be more explicit here, especially with an example what a platform-provided origin could look like

Yes, a non-normative example would be great. If there’s a common one that’s already in use, all the better. However, it’s important to think about any that we know absolutely must not be allowed (e.g., file:, http:)… they don’t need to be defined here, but should be somewhere.

something like:

If the url's scheme is a local scheme, or http:, or file:, or javascript:, or ws:, or wss:, return error.

marcoscaceres · 2026-05-01T03:00:04Z

 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.


Origin should link to definition

for what it's worth, OpenID specs usually don't like to Terminology like the w3c specs do

marcoscaceres · 2026-05-01T03:00:38Z

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


brentzundel · 2026-05-07T15:47:45Z

Discussed during call. In general Marco's proposed change seems fine, but it should have correct references and retain some example text.

brentzundel · 2026-05-14T15:24:36Z

@marcoscaceres could you respond to comments made so far?

awoie added 4 commits April 16, 2026 16:35

clarify origin is an opaque string incl errata

e7992bb

updated errata

34938f7

fix doc history

725f539

undo line remove

5a85931

awoie requested review from c2bo, dpostnikov, fkj, jogu, marcoscaceres and martijnharing April 16, 2026 14:39

awoie mentioned this pull request Apr 16, 2026

Clarifications on processing expected_origins and processing steps #224

Open

awoie added 2 commits April 16, 2026 16:46

add trust assumption

5314027

clarify no prior processing of expected_origins / provided Origin is …

a0e649f

…needed