openwallet-foundation
Support receiving out of band invitations with public dids for the didexchange protocol
#930 adds support for receiving out of band invitations with public dids, but only supports processing it for 0160 connections. We should still add support to do this with the didexchange protocol
Maybe related to this: how about the "implicit invitations" in DID Exchange protocol? From the RFC my understanding is that the protocol can be started either by an OOB invitation or the resolution of a Public DID.
Currently, DidExchangeProtocol.createRequest requires an outOfBandRecord among its options, which makes me think that it's only intended for the explicit invitations. That means this is not supported, or should it be supported by previously creating a 'local' OutOfBandInvitation containing public DID as service field and calling oob.receiveInvitation? (however I don't think the responder would accept it given that pthid will point to an unknown thread).
For context: the flow I'm trying to solve is the one where I receive a proof request specifying a credential definition id and, as I don't have a matching credential, I want to connect with the issuer (in Indy I can get its public DID just by inspecting the credential definition id) to ask for the issuance. Should I solve it with an connection-less flow? In such case, will I be able to create this 'implicit OOB invitation' containing the public DID?
That's an interesting way to get the credential you need!
I think yes, currently the flow doesn't take into account the implicit flow. What would be the easiest approach I think is to keep the DidExchangeProtocol.createRequest to need a out of band record, that we can create on the module layer beforehand. Another approach would be to create a DidExchangeProtocol.createRequestFromDid and ConnectionService.createRequestFromDid and expose it through a ConnectionsApi.sendRequestToDid or something similar (don't like sendRequestToDid too much).
I think it would work fine with the pthid:
When a request responds to an implicit invitation, its ~thread.pthid MUST contain a DID URL that resolves to the specific service on a DID document that contains the invitation.
We should modify the request to include the public did with service as the pthid, like so: https://github.com/hyperledger/aries-rfcs/blob/main/features/0023-did-exchange/README.md#example-referencing-an-implicit-invitation
The connectionless flow should also work I assume and is probably easier to implement, so I think it's a bit dependant on which flow works best for your use case. At the moment we don't support proposals for connectionless credential issuance though
Thanks for the explanation and suggestions @TimoGlastra ! I think it would be nice to support these implicit invitations from the module level in order to make it more evident for users how to handle both invitation types. I'll dig a bit more about the possibilities and open a PR including these public DID handling in DIDExchange protocol.