OpenID4VP invocation via platform provided Digital Credentials API

[leecam]

Section 7 of the specification presents a list of mechanisms to invoke a native mobile Wallet application from the web (or other native app). These currently include Android and iOS platform specific methods such as Custom URL schemes, Universal Links and App Links. It also includes a QR code based flow for cross-device invocation.

Up until recently these were the only viable options available to OpenID4VP but they come with a number of drawbacks.

• Custom URLs suffer from a number of user experience issues as captured here
• They do not provide a secure phishing resistant cross-device presentation flow that could meet LoA High requirements of the EU.

To address these issues a new Digital Credentials browser API is being developed. This API is designed to allow websites to initiate a request for digital credentials, using their presentation protocol of choice, such as OpenID4VP.

This issue to track the changes required to the OpenID4VP specification to include support for innovation via the Digital Credentials API.

This document presents a sketch and serves as a starting point for how that might be done https://docs.google.com/document/d/1uuOJsaDU2kbh0LN8YE2yOQerGKLVARmGQ7yRVf3Bhx4/edit?usp=sharing

[c2bo]

I didn't have time to properly think about this yet so take this with a grain of salt, but the first question I had when reading the proposed API call was how would this work with the JAR based approach where the request object is a signed JWT?

Quite a few of the client_id_scheme options introduced to establish trust in the relying party are based on this approach where the authorization request is signed (in the form of a JWT as defined in JAR). Would we just duplicate some of the data contained in the request object to allow for the matching and still pass the request object JWT via request_uri?

[Sakurann]

If we assume/agree that establishing trust in the verifier is what happens between wallet and the verifier directly, browser API can be oblivious to request_uri vs request as a JWT, etc because it does not need to understand client_id, client_id_scheme, request signature, etc., as long as request to the browser API contains all of the necessary information for the browser to render a meaningful wallet/credential screen to the end-user.

So this probably means that verifier always needs to pass presentation_definition object in the browser API request, regardless whether it is using request_uri/JAR or not.

[Sakurann]

this is addressed by PR #155, right?

[jogu]

I agree, it is. I think we can close this in favour of issue #125, although strictly speaking they're not quite duplicates.

[jogu]

Duplicate of #125