what does it mean to support a custom URL scheme

[Sakurann]

My interpretation of the mdoc issuance profile as proposed in this PR is that it mandates support of custom scheme haip:// for credential issuance, this has a few issues:

• There is no normative language for what it means to support a custom scheme. Does it mean you have to be reachable, register etc. As an example, what does requirement mean in the context of a wearable.
• This means that all mdocs issued using vci are all required to support/register the same custom scheme. While the goal is understandable, it's not clear to me if this requirement is actually helpful for interoperability.
• Schemes have known security issues depending on how they are used, mandating support for them independent of whether protecting measures are in place is awkward.

Originally posted by @martijnharing in #228 (comment)

[Sakurann]

• on the first point, i think the intention has been for the wallet to be able to understand a request that uses haip:// custom url scheme, if that request reaches the wallet. the last part is important, since, because of the dependencies on how mobile OS handles custom url schemes, there is no guarantee that a request that uses haip:// custom url scheme will actually reach the wallet
• on the second and third points, don't necessarily disagree, but i think this is the bare minimum/best effort that we can do for vanilla openid4vp. related to the third point, we can add a section in haip that talks about the limitations of custom url schemes, like the one w3c dc api work has: https://github.com/w3c-fedid/digital-credentials/blob/main/custom-schemes.md

[jogu]

FYI Removing HAIP custom scheme was discussed previously: #190

[Sakurann]

what @awoie said in #244

Remove the haip:// custom URI scheme in HAIP and require platform-native mechanisms (Universal Links on iOS, App Links on Android):

• Custom schemes create MITM risks (any app can register the scheme). PKCE mitigates some impact for VCI, but it's still not a good security baseline.
• They lead to broken UX on some platforms.
• Universal/App Links tie invocation to HTTPS origins and integrate better with Web PKI trust providing stronger security.
• Additionally, the haip:// scheme is not a suitable indicator that the HAIP profile is expected. For example, DC API does not require schemes at all, and if such an indication is needed, it should be defined through an alternative mechanism.

[jogu]

Following on from Oliver's comment - I think it would make sense to at least add a sentence or two mentioning the use of claimed https urls as they're probably a suitable alternative to haip:// at least in some ecosystems.

[awoie]

Following on from Oliver's comment - I think it would make sense to at least add a sentence or two mentioning the use of claimed https urls as they're probably a suitable alternative to haip:// at least in some ecosystems.

I believe many ecosystems would prefer to avoid implementing custom schemes altogether. One additional advantage of universal links and app links is that they allow users to receive feedback when a flow ends because no wallet is available that can handle the request. For example, by being redirected to the wallet provider's website instead of encountering a dead end. For such ecosystems, it should be possible to remain HAIP-compliant without implementing the haip:// scheme for VP AND VCI. For this reason, haip:// should be a MAY rather than a MUST at least for issuers and verifiers.

[GarethCOliver]

If we want RPs to be able to reasonably move to DC API as a solution we should mandate Wallets support it, if available.

DC API can query if a protocol is supported or not. However they can not perform 'pre-flight' checks, so if there is a wallet that has credentials but does not integrate with DC API there is no good way to provide a good user experience (you'd have to launch DC API, show a dead end screen, go back, show some sort of CTA for custom schemes. Or show two unintelligible CTAs).

This then also reasonably allows either custom schemes or deep links.

R:e directed to wallet website: isn't this a privacy problem? This is one of the reasons during previous discussions app links were problematic, because the wallet server always learns the request.

[paulbastian]

I believe not mandating custom schemes is a disadvantage for small wallet providers. Keeping it in motivates us to push for a proper DC API implementation across all platforms :)

[GarethCOliver]

Doesn't mandating using the DC API when it supports OpenId4VP strongly encourage DC API implementations across all platforms?

That way there will be traffic waiting to go from verifiers 'for free' as soon as platforms enable it, which provide a clean, interoperable upgrade path (vs having to move every verifier to do a new code flow).

Something like:

'Wallets must support custom_schemes, and DC API when available'. Would allow 'prefer DC API, fallback to custom schemes'.

[jogu]

Discussed on today's WG call - suggestion from Hicham to use text like this which we seemed to get consensus on:

If the Wallet can be invoked using the haip:// custom scheme then the wallet MUST process the credential offer according to HAIP.

updated on sept-09 wg call.
the plan was to also add sentence about claimed url schemes:

Implementations MAY support other ways to invoke the Wallets such as claimed urls as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes`.