Recommend the browser API over traditional OID4VP?

[jogu]

As per Lee's comment we might want to go as far as saying the Browser API (where available) is preferred/recommended.

[Sakurann]

in the future, yes, absolutely. but not yet in my opinion. we should wait for the W3C API work to be moved to the WG at least.

[charsleysa]

I would be against recommending the W3C API until it supports web wallets and is supported by multiple platforms. The openid4vp: scheme is the better option to recommend at the moment for its ease of implementation and better support with current technologies.

[timcappalli]

Recommend changing the title to "Digital Credentials API" to cover native and app2app use cases.

[ThierryThevenet]

In practice the behavior of browsers on smartphones are all different and poses concrete problems today with deeplinks and weblinks that are not interpreted the same way or even not accepted by the browser. The use of a browser API will be probably worst for years. The only solution that is simple, understood by all users and works all the time is cross device and qrcode. would it be also possible to improve the security of the qr code itself and the flow with the qrcode ?

[jogu]

I would be against recommending the W3C API until it supports web wallets and is supported by multiple platforms. The openid4vp: scheme is the better option to recommend at the moment for its ease of implementation and better support with current technologies.

Is that two separate points? Because I didn't know openid4vp:// worked for web wallets.

[jogu]

In practice the behavior of browsers on smartphones are all different and poses concrete problems today with deeplinks and weblinks that are not interpreted the same way or even not accepted by the browser. The use of a browser API will be probably worst for years.

I have implemented the Browser API. My experience is apparently different from yours as (when it is available, which you can tell programmatically) I'm seeing it work well and not have the problem associated with custom schemes.

The only solution that is simple, understood by all users and works all the time is cross device and qrcode. would it be also possible to improve the security of the qr code itself and the flow with the qrcode ?

The only good fix we've got for cross device is the Browser API. There are various small improvements that can be done, but they're often reliant on the user which is generally not a useful element to rely on.

[charsleysa]

I would be against recommending the W3C API until it supports web wallets and is supported by multiple platforms. The openid4vp: scheme is the better option to recommend at the moment for its ease of implementation and better support with current technologies.

Is that two separate points? Because I didn't know openid4vp:// worked for web wallets.

Currently, it's not supported out-of-box.

However support for it can be more easily achieved for web wallets using existing implemented experimental standards.

The protocol_handler allows for PWA web wallets to register to handle a safe scheme or custom scheme beginning with web+. This functionality is already widely available in Chrome / Edge browsers.

If openid4vp was added as a safe scheme that would allow web wallets to work. The other option is for the scheme to be changed to web+openid4vp which would allow web wallets to work immediately without any changes required to existing browsers.

[jogu]

Interesting, thanks.

If openid4vp was added as a safe scheme that would allow web wallets to work.

Given the browsers are threatening to block/add extra friction around custom schemes I can't see them cooperating on enabling them for PWA (which is the ask right?), and it would still be a poor solution on iOS if there's more than one wallet installed.

[ThierryThevenet]

@jogu On our side we have 6 different smartphones on the desk to test our wallets. The day we will have at least 4 out of the 6 that support browser APIs the same way we will implement browser APIs. Right now the only solution that works all time is QR code and the solution to jump to another horse which seems better is not the best approach for deployment in practice. So it looks strange to recommend a new solution which is not supported by several platforms. My humble opinion would be to wait until the technology is actually supported unless a better one comes along.

[timcappalli]

Regardless of which way we go here, we will need to provide guidance on how to fall back from the Digital Credentials API (please stop referring to it as "browser API"), to legacy methods.

I believe the spec should include text recommending the use of the Digital Credentials API when available and also provide guidance on how to fall back.

Also just as an FYI (not trying to get into a discussion here), there is exploratory work happening to see how web platform-based wallets can plug into the Digital Credentials API (so their credentials can appear in a selector), or even into FedCM (as they follow a similar pattern.

[ThierryThevenet]

The deep integration of the Digital Credentials API makes the browser and later FIDO CTAP as central components of the OIDC4VP protocole and so it creates a strong dependence. Is that not an issue ? Pros of this solution are clearly explained in Appendix A. Let's the ecosystem/regulation decides if it is recommended or mandatory.

[timcappalli]

They would be dependencies only for one option. The alternative does not have those dependencies. So no, I don't think that's an issue.

[ThierryThevenet]

At least we agree on that : it is just an option. Appendix A is enough and clear.

[jogu]

The deep integration of the Digital Credentials API makes the browser and later FIDO CTAP as central components of the OIDC4VP protocole and so it creates a strong dependence. Is that not an issue ?

Why might it be an issue? Is it an issue for Passkeys / webauthn?

Pros of this solution are clearly explained in Appendix A. Let's the ecosystem/regulation decides if it is recommended or mandatory.

Given the security benefits it seems sensible for us to give people guidance. Developers appreciate guidance as it makes it easier for them to implement a spec in the recommended way.

@jogu On our side we have 6 different smartphones on the desk to test our wallets. The day we will have at least 4 out of the 6 that support browser APIs the same way we will implement browser APIs. Right now the only solution that works all time is QR code and the solution to jump to another horse which seems better is not the best approach for deployment in practice. So it looks strange to recommend a new solution which is not supported by several platforms. My humble opinion would be to wait until the technology is actually supported unless a better one comes along.

It sounds like you are in favour of "recommended where available" then, you just want to hold off your own development till more implementations have shipped? That's absolutely fine as a position. (Although note that by the time that many implementations have shipped your ability to influence how the Digital Credential API works will be much smaller.)

[ThierryThevenet]

In fact, the problem behind all this is that it puts the browser back at the center of the protocol with a distribution of tasks and trust between the wallet and the browser and that, as ultimately the two main browser providers are also wallet providers. It is clear that this further amplifies the dominance of these same companies.

[jogu]

What's your alternative suggestion to improve the user experience / cross device security Thierry?

[ThierryThevenet]

Why don't you wait a few months until there are already more platforms available?