Public Invite URLs are malformed

[dbluhm]

When --public-invites is enabled, using the admin interface to retrieve an invite URL returns a string that looks something like the following:

?c_i=<base64_encoded_invite>

The encoded invite is correct; it only includes the type and the did which should be used to resolve endpoint information and keys etc. However, since the endpoint is not specified on invite creation, it appears that the invite object doesn't know what to put when serialized as a URL resulting in something that isn't actually a URL.

[andrewwhitehead]

I feel like this should be addressed in the DID exchange RFC, maybe a standard base URL can be used that resolves to a page with instructions?

[swcurran]

@dbluhm - please review @andrewwhitehead's note - does that resolve the issue. Is there more that needs to be done to this issue other than perhaps to raise it as a concern in the aries-rfcs repo? Or is there something that ACA-Py is missing?

Thanks

[dbluhm]

I still consider this a bug but we do need more definition in the RFC before there's an obvious fix. I'll raise an issue there and reference this issue.

[dbluhm]

The following is what the DID Exchange Protocol RFC has to say about the invitation URL (same wording also in the connection protocol RFC):

https://<domain>/<path>?c_i=<invitationstring>

<domain> and <path> should be kept as short as possible, and the full URL should return human readable instructions when loaded in a browser. This is intended to aid new users. The c_i query parameter is required and is reserved to contain the invitation string. Additional path elements or query parameters are allowed, and can be leveraged to provide coupons or other promise of payment for new users.

On closer inspection, though open-ended, the DID Exchange protocol does cover this topic enough that I didn't feel I had enough to open an issue against the RFC(s). I think using the domain of the currently running agent is the most appropriate fix right now in the absence of a standard base URL for resolving instructions.

[swcurran]

So @andrewwhitehead, for BC issuers, would we have this go to (for now) a vonx.io page that is rendered with instructions, a QR code version of the invitation, and the text invitation that can be copied and pasted? E.g. https://toip.vonx.io with a null path.

I presume the URL needs to be a parameter passed into the agent when it is started, right?

[andrewwhitehead]

@swcurran Yes, we can add a startup parameter to provide a custom invitation base URL (--invite-base-url ?). The page would likely need to do some vetting to avoid presenting unofficial invitations with a BC masthead, too bad they aren't signed. There's 3 layouts to define: when an accepted invitation is passed in, when an unaccepted one is passed in, and when there's no c_i parameter at all (this one might have links to publicly available agents). It should be doable in HTML and JS only.

[swcurran]

Sounds good. I don't get the three cases, but probably haven't thought enough about them. What is the difference between and accepted and unaccepted invitation? How would the service presenting the data know the difference? Second, even if a public DID is to be used, wouldn't there need to be presentation of that DID as part of an invitation? I thought is was the same format but with the DID replacing the inline DIDDoc contents. Answers not needed unless you think they would be helpful to someone else :-). Otherwise, we can chat about this sometime.

I'd say just go ahead with the implementation when it fits in your work.