shortened oob invitation and the didcomm:// protocol scheme

[TimoGlastra]

When creating an oob invitation that can be opened directly on the device where the invitation url received (i.e. a web page on my mobile device) there is an option to use deeplinking to open the oob invitation directly in a wallet.

In Aries we currently use the didcomm:// prefix to link directly to the wallet and include the ?=d_m (or oob or c_i) parameter. Wallets that support it can extract the invitation from it and process the message.

I've recently encountered an issue where even deeplinking would require an url shortener service because the payload of the url is too long. I'm not sure what the exact limit is, but if you're offering a credential as part of the oob invitation you can quite quickly reach this limit. The problem here is that the domain is didcomm:// and therefore a shortened oob url could never be resolved.

I see the following comment in the spec:

To do: We need to rationalize this approach https:// approach with the use of a special protocol (e.g. didcomm://) that will enable handling of the URL on mobile devices to automatically invoke an installed app on both Android and iOS. A user must be able to process the out-of-band message on the device of the agent (e.g. when the mobile device can’t scan the QR code because it is on a web page on device).

I think it would be good to take this into account when defining how deeplinking should work. Maybe something like an _ooburl= would work in the case of using didcomm:// so the oob invitation can still be resolved.

[OR13]

cc @awoie who just answered a question about this on the ccg list.

To make this work with iOS don't you need to use an https link?

[TimoGlastra]

To make this work with iOS don't you need to use an https link?

No on iOS it uses the first app that registered the didcomm:// scheme. Android give you a choice which app to open.

However apple is pushing a lot more for the https:// based universal links (so redirect to the app if it is registered, otherwise open it in the browser). So not so sure how long they will keep supporting it.

[apelt]

https:// has one big advantage over didcomm:// - if your mobile app is not installed and user scans QR code with custom scanner or clicks hypertext, the link will be opened automatically in default browser of your mobile device, where you can show your website with info to the user and a link to download your app. So as a mobile app developer I would go with https://

[dhh1128]

Further comments from @TimoGlastra :

if we have a shortened oob invitation like this:

https://example.com/path?_oobid=5f0e3ffb-3f92-4648-9868-0d6f8889e6f3

Then the deeplink variant could look like this:

didcomm://oob-invitation?_ooburl=https%3A%2F%2Fexample.com%2Fpath%3F_oobid%3D5f0e3ffb-3f92-4648-9868-0d6f8889e6f3

The oob-invitation part is random here. I don't think it matters (unless we want to reserve different paths for different deeplinking actions / not clash with native deeplinking behaviour), as all information is presented in the invitation

[dhh1128]

I am supportive of Timo's suggestion. However, I don't think it requires that we add an example or normative language in the spec, because the spec doesn't define the didcomm:// protocol scheme. I've added a commit that specifies that the didcomm:// protocol scheme exists, and what its purpose is -- thus creating a space for the DIF community and/or the Aries community to adopt Timo's recommendation.

[TelegramSam]

With the merged commit, I believe this becomes a deferred issue.