For "URL" based credential handlers, deliver multiprotocols wallet interaction URL next to protocols

[dlongley]

We should phase out the use of protocols embedded as JSON to deliver CHAPI requests to "URL" based credential handlers -- and instead pass a wallet interaction "protocols" URL, that when retrieved via HTTP GET w/"accept: application/json" (from the requesting origin), will deliver the protocols object.

This approach provides better origin security and reduces the initial URL (query param) size sent to the credential handler's deep link, allowing for larger URLs to be included in the protocols object.

This might be done by having a new credential handler mechanism (name TBD, but perhaps interact) instead of just augmenting "URL".

Alternatively, if interact is provided in protocols to the credential handler API and that protocol is supported by the credential handler (per its manifest.json registration metadata), just that URL could be included in protocols, solving the problem without any other changes. For example:

{
  "protocols": {
    "vcapi": "<some url>",
    "OID4VCI": "<some url>",
    "OID4VP": "<some url>",
    "anything": "<some url>",
    // only protocol "known" to the mediator
    "interact": "<some url>"
}

With the above object and a credential handler that has announced it understands "interact", the mediator will only send (to the handler, if chosen), even if the handler also announces it understands (some of) the other protocols:

{
  "protocols": {
    "interact": "<some url>"
}

[kezike]

@dlongley In the current version of CHAPI (AFAIK), the CHAPI request comes in as a URL with a query parameter named request. That query parameter is a URL encoding of a stringified JSON, which contains two keys: credentialRequestOrigin (untrusted origin URL) and protocols (map from protocol ID to URL that will be used to initiate an exchange for the protocol).

In the new version proposed here, are you recommending that the initial URL that comes in would still contain the request query parameter, but instead of containing the complex encoded object, it would just contain a URL encoding of a new workflow URL (presumably the new <fullExchangeId>/protocols VC-API endpoint defined here)?

Also, would you recommend that wallets keep support for the older URL format for backwards compatibility?

[dlongley]

In the new version proposed here, are you recommending that the initial URL that comes in would still contain the request query parameter, but instead of containing the complex encoded object, it would just contain a URL encoding of a new workflow URL (presumably the new /protocols VC-API endpoint defined w3c-ccg/vc-api#421)?

This is a detail we'll need to sort out. Either way, the new mechanism would only be triggered / used with credential handlers that announce support for the "interact" protocol (or whatever we name this).

Also, would you recommend that wallets keep support for the older URL format for backwards compatibility?

I don't think this would be necessary for wallets (credential handlers) to do. The credential mediator will continue backwards compatibility for some time for credential handlers that announce support for the older mechanism, however, a credential handler that announces support for the new "interact" protocol would automatically be opting into receiving the new format (whatever that ends up being). No credential handler should announce support for this until it's supported by the credential mediator, but once it is, there should no reason why the wallet would need to worry about receiving the old format, i.e., no need to support it from that point forward.