Refine processing expected_origins and processing steps

[awoie]

Fixes #224

[awoie]

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

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

[Sakurann]

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

[lj-raidiam]

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

[fkj]

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

[marcoscaceres]

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.

[awoie]

See proposal below.

[marcoscaceres]

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.

[fkj]

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.

[c2bo]

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

[marcoscaceres]

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.

[awoie]

Since expected_origins is part of the OID4VP protocol payload, OID4VP can define constraints on the values a verifier is allowed to provide there. The platform-provided origin itself is outside the scope of OID4VP and is determined by the W3C Digital Credentials API / platform layer. OID4VP can therefore only specify how the wallet compares expected_origins with the origin provided by the platform, and how the wallet behaves when no match is found, or the value of expected_origins uses an unsafe / unsupported URI scheme.

We could say something like this (wdyt @marcoscaceres @fkj @c2bo ?) :

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.

[awoie]

How about the following which combines @marcoscaceres reference while including native applications as well as retaining the examples?

Origin: 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 HTML Section 7.1.1 "Origins"[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.

We could then also add a constraint on expected_origins as follows:

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.

[awoie]

Wdyt about the above proposal @fkj @marcoscaceres @c2bo @lj-raidiam ?

[c2bo]

That sounds good to me!

[fkj]

I think we should add that the platform-specific application origins MUST be treated as opaque origins (cf. the HTML spec).

[c2bo]

The Origin provided by the underlying platform is outside the scope of this specification.

I guess we could modify the last sentence along those lines?

The Origin provided by the underlying platform is outside the scope of this specification and MUST be treated as an opaque string.

[brentzundel]

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

[brentzundel]

@marcoscaceres could you respond to comments made so far?

[paulbastian]

wg call:

• suggestion from @c2bo and @fkj to further iterate on @awoie latest proposal, taking reference from Marcos suggesting and merging them with ideas from @awoie
• @c2bo is syncing with @awoie to make a new proposal, as it seems to complicated in a suggestion