Consider using _ooburl parameter for shortened invitations instead of _oobid

[TimoGlastra]

After implementing OID4VC we noticed one pattern of url encoding that has simplified our handling or URLs in the wallet and server side, also taking into account rendering an HTML invitation page when you don't have the wallet installed, supporting iOS/Android universal links, and native deeplinks.

Instead of including an id reference to the invitation in a shortened url, you include a link to the oob invitation in the url as a query parameter.

An example would be: https://didcomm.org/invitation?_ooburl=<encodedShortenedRawUrl>. Once fetched it would return the json of the invitation.

Some benefits we've noticed on this pattern:

• The invitation HTML page (if you don't have a wallet installed) doesn't have to be hosted on the same page/domain as the invitation JSON data).
  • This is specific to our infrastructure, and may not be a good argument. But having the links separate makes it much easier to embed a QR on a webpage using an iframe, and still have the underlying ooburl point to our servers.
• The pattern works for both deeplinks (e.g. didcom://?_ooburl=) as well as https/universal links (e.g. https://didcommm.org?_ooburl=). (see also shortened oob invitation and the didcomm:// protocol scheme #351)
• A wallet/QR scanner can recognize it is a DIDComm invitation (this is already true in DIDComm v2 compared to OOB v1)
• There's no ambiquity in whether you're interested in fetching the invitation JSON. When you fetch the ooburl parameter, it will always return the JSON of the invitation. Currently when you use shortned urls (or non-shortned urls) you'd want to show a HTML page when the user is not in a wallet context. This requires parsing the user agent to dynamically return different content. For DIDComm v1 OOB there was the option to include an Accept header of application/json to specifically request the JSON of the invitation, but I can't find something related to this in the DIDComm v2 spec.

As this will have big impact on the didcomm spec, I don't expect this to result in any changes, just some learnings we've had and why we prefer the url pattern over an id in the url pattern.

[jorgefl0]

As a DIDComm implementer, I like this recommendation and agree that it simplifies handling of OOB invitations.