Handling of `origin` in Native Mobile Platform App to App flows for DC API

[tplooker]

When using OpenID4VP to accomplish an App to App flow (e.g where the verification application is a native mobile application rather than a web application), the origin used in the DC API flow takes a different form to when using the W3C DC API on the web.

In Appendix A currently all the examples are focused around using the W3C DC API via the web, so the origin is always a web origin, e.g origin1.example.com.

However, when performing an App to App flow, the origin is mobile platform specific.

For example on Android using the Android Credential Manager, the origin that wallets are using, such as CMWallet follows the following syntax

android:apk-key-hash-sha256:<base64_encoded_sha256_hash-of-apk-signing-cert>

See here for a reference.

Which in turn looks to be based on the FIDO standard which is used for solving a similar problem for FIDO credentials.

Currently in VP we have text that notes the origin is platform specific in these scenarios, however we could improve guidance here either pointing externally or adding some text describing how to handle the origin in these cases.

[jogu]

Discussed on today's WG call:

If we add this, it is non normative guidance as this at the discretion of the platforms.

We could tweak our definition of "Origin" perhaps. Consensus not to actually linked to OS developer pages as these do tend to move around, and we should tell verifier implementors to find the relevant documentation for the platform they are developing for.

[javereec]

Is this still relevant? In the latest draft "Origin" already includes clarification on this

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.

[brentzundel]

As discussed in the DCP call, this issue calls for an example, otherwise this is addressed by #719

[fkj]

Some additional considerations were surfaced (primarily by @martijnharing) while discussing #224.
I'm moving them here to avoid blocking #224 which is otherwise handled by #719.

Some additional guidance should be added to make it clear that:

• The platform must provide unique and collision-resistant strings even though this is not something that can be verified externally.
• The platform must ensure that the exact same string is generated for the origin on both the wallet and the verifier side. This guidance applies both to the DC API and any platform-specific equivalents.
• The security properties of the DC API must be preserved when implementing platform-specific DC API equivalents.

[brentzundel]

The suggestion is that @martijnharing would be an ideal candidate to draft this additional language.