URL-Scheme is the wrong way conveying (wallet-)metadata

[ubamrein]

We recently had a discussion about the invocation for the wallet (especially in the same device flow). Currently, there are no concrete options available which are better than the custom url-scheme method (which has obvious issues security wise but also just UX wise), so we kind of relay on that for the moment.

However, defining a custom url-scheme for any new set of use-case/algorithms/ leads to even more issues.

Say we have a wallet supporting many different algorithms, also maybe ones that are not explicitly in the RFCs (yet). This goes on for whatever time amount. Then a new format makes it into openid4vp say JSON-LD, and the y introduce the json-ld-openid4vp:// custom url scheme. Now our initial wallet already supported json-ld for whatever reason, but did not put the json-ld-openid4vp:// custom url-scheme into the application manifest (plist or whatever way) for obvious reasons (it was defined later), hence cannot communicate with the new service. This is a pity, as it would be supported. Even worse, phone group A might not be able to update to the newest wallet version (as for device-fragmentation whatever reason) and are stuck with the version that actually supported json-ld, but "does not" because a new url-scheme was chosen.

In my opinion the current ways of communicating a) data-formats and b) algorithms for either signing or/and encryption are enough (c.f. client-metadata, dif-pex/dcql). There is no need for various different custom-url schemes. If a wallet supports the set of format/sig/enc then it knows that.

If an RP wants to enforce a specific profile, I'd rather suggest using something like ACR from the openid world, say profile with a url to a profile describing it (what the difference to the metadata is, I don't know, but there seems to be a wish to be able to do that)

[jogu]

Say we have a wallet supporting many different algorithms, also maybe ones that are not explicitly in the RFCs (yet). This goes on for whatever time amount. Then a new format makes it into openid4vp say JSON-LD, and the y introduce the json-ld-openid4vp:// custom url scheme. Now our initial wallet already supported json-ld for whatever reason, but did not put the json-ld-openid4vp:// custom url-scheme into the application manifest (plist or whatever way) for obvious reasons (it was defined later), hence cannot communicate with the new service. This is a pity, as it would be supported. Even worse, phone group A might not be able to update to the newest wallet version (as for device-fragmentation whatever reason) and are stuck with the version that actually supported json-ld, but "does not" because a new url-scheme was chosen.

Phrasing it like that makes it sounds like a trade off between effort for the wallet vendor (i.e. continuing to support old operating systems) and user experience (see below). If that is the tradeoff, then in my opinion user experience should always win.

The reality is, for the two main mobile operating systems as they work today, and with multiple wallets installed:

1. Android: Switching to a single custom url scheme would further put the burden onto the user to remember which wallet works with which verifier and holds which credential. (As the user would be presented with a list of all their wallets and asked to pick one. There is already some burden here if the user has installed multiple ISO mDL wallets for example.)

2. iOS: This would essentially restrict the user to having only one wallet installed (as only one wallet would be invoked based, they wouldn't have the option to have (say) different wallets installed for a USA driving license and a EU PIID.

On the flip side, if we want to optimise for the "user only has one wallet installed on their mobile phone" case, a single custom url scheme might make sense. I'm not sure we want to optimise for this case. Thoughts welcome, how do you see these cases playing out?

[ubamrein]

You're argument doesn't really hold I think. You'll have the same issue with multiple custom url-schemes, as they are not specific for one wallet, but for a use-case group. So a wallet supporting all of them will register all of them and cause the exact same problems (to be fair you might get a slightly better UX if you have credentials from multiple continents).

Just look e.g. at the mdoc vs. sdjwt usecase. Why should I use two wallets for sdjwt vs mdoc? That doesn't really make sense. So a wallet would register both anyways, hence causing the issues you mentioned.

I think in most cases you'll have one wallet for most use-cases anyway (at least for the sake of starting the verification on the same device), so optimizing for that case makes sense in my opinion. It does not prevent the user from copying the qrcode payload, and start the flow from any wallet he wishes to use.

[jogu]

Just look e.g. at the mdoc vs. sdjwt usecase. Why should I use two wallets for sdjwt vs mdoc? That doesn't really make sense. So a wallet would register both anyways, hence causing the issues you mentioned.

You don't have to use two different wallets, but splitting the custom urls means you can. It's highly likely (sadly) that the number of wallets that can(*) hold both (say) a California driving license and a EU PIID is either zero or very close to zero.

And to be clear, this situation is hugely problematical anyway, but forcing everything through a single custom url scheme would I believe make it even worse. At least segmenting things so that "mdoc-openidvp:" means "a wallet that supports ISO 18013-7 annex b" gives the user (on iOS) a better chance of ending up in a wallet that does at least support x509_san_dns and the holding of ISO mDLs.

(*) by "can" I mean "are technically capable of holding and meets both the technical and non-technical requirements from the issuer for the wallet to be allowed to hold that credential".

[ubamrein]

You don't have to use two different wallets, but splitting the custom urls means you can.

Well not really, when both wallets understand both protocols (as they probably want/must at least in the EU), you end up with the same problem. Sure on Android you might be able to assign a wallet for mdoc and one for sdjwt (if you wish), but on iOS it won't help you.

It's highly likely (sadly) that the number of wallets that can(*) hold both (say) a California driving license and a EU PIID is either zero or very close to zero.

But they don't use OpenID4VP do they? And I mean "can" yes, maybe a European wallet will not meet the requirements to hold American mDL, but the custom url-scheme is about openid and mdl, which is country agnostic (in the sense that any wallet in the EU will eventually need to support mDoc (mDL) and SD-JWT), so we won't solve the problem with that.

Regarding the international interoperability, I agree, so maybe we can/should start a registry with url-schemes based on "ID influence" (policies?), like I've seen some custom-url-schemes using "eu" as a prefix. That would be more reasonable, as a policy maker could define (and write down) a url scheme, which describes conformance to a certain policy (certification of some kind?).

Then it is not about the technical part (which I am complaining here), but about the policy part (which I think more closely describes what you mean with "can").

At least segmenting things so that "mdoc-openidvp:" means "a wallet that supports ISO 18013-7 annex b" gives the user (on iOS) a better chance of ending up in a wallet that does at least support x509_san_dns and the holding of ISO mDLs.

As I said, if I follow the European course correctly, this will be the case for any wallet in the EU, which means we solve nothing, as any country in the EU needs to provide such a wallet, and probably there also will be some private wallets that want to tackle the European market (and hence have to support both).

And to be clear, this situation is hugely problematical anyway.

I totally agree on that point :)

[jogu]

You don't have to use two different wallets, but splitting the custom urls means you can.

Well not really, when both wallets understand both protocols (as they probably want/must at least in the EU), you end up with the same problem. Sure on Android you might be able to assign a wallet for mdoc and one for sdjwt (if you wish), but on iOS it won't help you.

Agreed. Really the browser Digital Credentials API is the only thing we have that's actually a well formed solution for all cases.

It's highly likely (sadly) that the number of wallets that can(*) hold both (say) a California driving license and a EU PIID is either zero or very close to zero.

But they don't use OpenID4VP do they?

We'd expect anyone exposing mdls via custom url schemes to move towards the ISO 18013 part 7 annex b protocol that's based on OpenID4VP.

And I mean "can" yes, maybe a European wallet will not meet the requirements to hold American mDL, but the custom url-scheme is about openid and mdl, which is country agnostic (in the sense that any wallet in the EU will eventually need to support mDoc (mDL) and SD-JWT), so we won't solve the problem with that.

Yes, that case would remain problematic particularly on iOS. On Android the user would at least get a choice of two wallets that can both hold mdls and are able to understand the query, which is arguably better than (say) getting a choice of 4 wallets (only two of which might work) if all wallets used openid4vp:// for everything.

Regarding the international interoperability, I agree, so maybe we can/should start a registry with url-schemes based on "ID influence" (policies?), like I've seen some custom-url-schemes using "eu" as a prefix. That would be more reasonable, as a policy maker could define (and write down) a url scheme, which describes conformance to a certain policy (certification of some kind?).

I think there's one or two possible improvements but it all needs very careful thought as any solution other than the Digital Credentials API we're trading off one problem for a different problem, so we first need to agree which problem is the highest priority.

[awoie]

Currently, the wallet's authorization endpoint (e.g., mdoc-openid4vp:// in the case of URL schemes) denotes the wallet metadata. This poses a challenge because, as you pointed out, it is protocol-specific rather than wallet provider-specific. To ensure interoperability across all wallets registering the same scheme, we introduced a baseline mechanism that works consistently. However, wallets relying solely on URL schemes lack a (dynamic) method for obtaining wallet provider-specific metadata.

An alternative approach is to use HTTP-claimed URLs for specific wallet providers, enabling wallet provider-specific metadata. Since these HTTP-claimed URLs are tied to particular wallet providers, they can also support dynamic metadata resolution using .well-known. OAuth already provides a mechanism for this through .well-known/oauth-authorization-server (RFC 8414), but IMHO defining a dedicated mechanism for wallets and OID4VP would likely be more appropriate. This could be introduced in a future extension of OID4VP in a backward-compatible manner.

In the EU, implementing this would require a NASCAR-style selection process, similar to existing eIDAS solutions. For example, when I use my Austrian eID to access my German retirement account, I must first select my country, which then redirects me to the Austrian eID scheme. IMHO, this method could be adapted to support wallet providers as well.

That said, OID4VP does not require modifications to support either of these approaches—it is already compatible. However, future versions of OID4VP could introduce dynamic metadata discovery in a fully backward-compatible way.

[charsleysa]

I'm very much in favor of keeping to a single scheme (e.g. openid4vp:) rather than splitting into many schemes by format.

By splitting into multiple schemes by format you are effectively removing the ability for multiple credentials of different formats to be requested in a single DCQL query. It should be entirely valid for a query to be able to say, give me either X credential in format A or Y credential in format B.

Splitting into different schemes will just ensure fragmentation of functionality rather than providing the opportunity for wider support. With a single scheme, a Relying Party could easily add support for a new credential format without any UX changes. Older wallets would still be able to process the request with the old format while newer wallets would be able to support both the new and old format.

[jogu]

Can I suggest we stop advocating for particular solutions and start discussing what UX we want to achieve?

We'll never agree on solutions if we can't agree on the requirements.

As an example:

On Android, do we want to offer users the chance to select a wallet that we know definitely can't cope (for technical or for regulatory reasons) with the request the RP is making?

On iOS, do we want to effectively restrict the user to having only one wallet installed?

[charsleysa]

In regards to UX, I would say that an RP should be able to specify in a single request what credentials they'd like, regardless of format, without needing to send the user through a series of questions first to determine which credential they have.

I would think the user would like be able to determine which wallet (if they have multiple) they have a credential that is most likely to satisfy the process they are involved in with the RP.

However, if regulations and/or technical standards are prohibiting that option then I would say having per-format schemas would still have the same problems as @jogu mentioned.

In that case, a more specific scheme (e.g. eu-pid-openid4vp:, us-mdl-openid4vp:) would result in better UX on the app side as it would reduce the probability of collision so multiple apps focusing on different use cases can be installed alongside each other. The downside is that the RP would have to question the user for which credential they would like to use before creating the request.

Effectively, we are trading off between better UX on the wallet side and better UX on the RP side.

[ubamrein]

I mean having multiple wallets I'd say is something, which hopefully does not happen too often? Especially on iOS as it cannot be handled anyways, so I'd assume people try to avoid it.

However, if regulations and/or technical standards are prohibiting that option then I would say having per-format schemas would still have the same problems as @jogu mentioned.

The idea is that by providing different url schemes, you could filter out wallets that only support one specific use-case. Say you have a MDL-wallet for the US, it won't show on any sdjwt requests in the EU as the url scheme is different. Especially on iOS this can lead to a (slight) better UX.

Effectively, we are trading off between better UX on the wallet side and better UX on the RP side.

I think having one common URL-scheme would not only increase UX on RP side, but also make it easier on the wallet side to match the QR-code data, and check if it is a VP request (and hence provide better UX by providing better error-messages), for cross-device flows.

Sure, technically one could try to match the query parameters, or the host parameters or so to check if it is a VP request, but then they are kind of generic names that probably appear in a lot of use cases (e.g. client_id).

This means it is kind of difficult to show a error box during QR-Code scanning (when scanning is initiated from within the wallet), as one can only know after trying to request data, if it is actually a VP request.