Support VC-API Interaction URL format in QR Code scanning

Original Post, adapted: @ottonomy

https://github.com/openwallet-foundation-labs/learner-credential-wallet/issues/764

“There are more wallets than just LearnCard in the world, but right now, websites offering credentials need to tailor their QR codes and deep links for specific wallets they expect users to have. This either makes it difficult to allow users to have wallet choice (they need to pick which wallet they want and then get a QR code or deep link specific to that wallet) or it makes it so users don't have choice of wallet. Right now to launch LearnCard, a https://learncard.app/request?vc_request_url=... deep link is shown to the user, but even other wallets that are white labels/forks of LearnCard cannot respond to this format. In addition, custom protocols like dcrequest:// can be registered but they have their own drawbacks.

Describe the solution you'd like
There is a new multi-protocol launch format that is part of the VC-API draft (v0.7, but who knows when the version numbers change), the Interaction URL format.

A reader can reasonably determine if a URL is in this format if it has a iuv=1 query parameter. Then it knows that it shouldn't post a presentation directly there, it should simply GET the url with Accept: application/json and then read the protocols offered. If there is a "vcapi" key, then it can proceed to post to the VC-API exchange at that URL (an empty post body will yield a verifiablePresentationRequest that the wallet can respond to). There may be other keys for different protocols, such as OpenID for Verifiable Presentations or OpenID for Verifiable Credential Issuance (though it is at the moment ambiguous as to what the key names would be for these protocols with differing guidance appearing various places).

Describe alternatives you've considered
Note that this interaction url JSON multi-protocol object doesn't 100% solve the problem of same-device handoff. I've considered what to do for that case, where a user scans this URL with their phone camera (which offers them a chance to open their browser) or if they are on the same device as their wallet and want to click a link to initiate the exchange . If a browser opens this url and makes a request with Accept: text/html,*/*,etc, HTML content could be returned where more specific methods of launching a wallet could be provided, such as a CHAPI or DC API interface, or a deep link into a specific wallet product or protocol-specific link. So this approach can be used in parallel with a little bit more advanced UX to handle same-device handoff, and I could imagine a microsite that could handle the HTML side of that for many issuers, where upon seeing the HTML accept header, the issuer just forwards over to the shared public good service that would itself read the interaction URL data and then provide the above full interface for shuttling the user into a same-device wallet if they desire.

Additional context
I was exploring these ideas further in a guide for organizations interested in getting their products to work with each other more cleanly. Comments welcome.”