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.