Using `oobUrl` in `didcomm://` deeplink for linking with shortened url

[TimoGlastra]

When using the didcomm:// scheme to link to a didcomm enabled application, you lose the ability to use shortened urls, as you don't know where to resolve the invitation from.

We've encountered with larger OOB invitations that they exceed the character limit iOS allows and thus it's not possible to use a didcomm deeplink for this purpose.

For this reason we've started using a custom oobUrl property on the didcomm:// deeplink that contains a shortened url.

a working link looks like this:

didcomm://?oobUrl=https%3A%2F%2Fparadym.id%2Finvitation%2Fefaf249a-39e5-42ab-9083-0aab96e7c3f1

I think it could be useful to standardize this custom parameter for passing a shortened oob url to a didcomm deeplink for the case described above.

Thoughts?

cc @tommylans

[genaris]

I think this is a good idea, but given that unified DIDComm deeplinking is being marked as STALLED in https://github.com/hyperledger/aries-rfcs/pull/827 it gives me the impression that it was not broadly implemented within Aries community.

Do you know if this is being used in different mobile apps? If that's the case I think the status should be reconsidered.

[swcurran]

Don’t put too much stalk into the STALLED marking of that RFC — I may be out of the loop on that one.

I think @TimoGlastra ’s idea seems kinda clever. I think it still suffers from the “iOS doesn’t do deep links nicely”, but its better than not having no redirect and impossibly large invitations. I do notice that Timo explicitly mentions iOS though, so that is interesting.

[TimoGlastra]

I think it still suffers from the “iOS doesn’t do deep links nicely”

Agreed that's not something that this will solve. But is is nice to add a didcomm deeplinkg to allow opening in other wallets (we by default use universal links to open in specific wallet directly, but this enables "Open in other wallet", although on iOS you can't select which wallet sadly)

[TimoGlastra]

I think RFC 0268 may do too much, and is a bit outdated, so I think it can benefit from either being updated or being replaced with a very simple "DIDComm Deeplinking" RFC that covers a) didcomm://, and b) oobUrl query params (or oob_uri would be more in line with Aries standards)

[jorgefl0]

Plus 1 on the idea of a simple "DIDComm Deeplinking" RFC

[JamesKEbert]

I'm also in favor of introducing a simple DIDComm Deeplinking RFC--would this RFC cover iOS Unviersal Links? I lean towards no--as Universal Links are inherently limited to the app owner's domain (websites that can redirect using a Universal Link requires providing authorized domains with .well-known/apple-app-site-association). I've demonstrated a method (https://github.com/JamesKEbert/aries-invitation-service & sample deployment) for having a community managed service to allow users to choose the app they'd like to use for an iOS device, which is open-source friendly, but this is a fairly significant effort to get launched and running (which I think is beyond the scope of what we need today).

Also @TimoGlastra, have you run into the same length constraints when using an Android intent? intent://invite?oob=${base64Invite}#Intent;action=android.intent.action.VIEW;scheme=didcomm;end

[genaris]

I think RFC 0268 may do too much, and is a bit outdated, so I think it can benefit from either being updated or being replaced with a very simple "DIDComm Deeplinking" RFC that covers a) didcomm://, and b) oobUrl query params (or oob_uri would be more in line with Aries standards)

I've recently discovered that BCGov have implemented something very similar to this: an _url query parameter that contains a Base64URL representation of the actual short URL where the invitation object can be retrieved.

Although it is easy for a wallet to support both, I think it would be nice to standardize this, so we don't end up making multiple approaches that do pretty much the same thing.