DID Exchange - Issue with implicit invitations

[domwoe]

I'm experimenting with the DID Exchange protocol in order to create a connection based on a public DIDs implicit invitation.
A public DID allows to retrieve the necessary keys and service information from a given VDR, i.e. all information that is needed to pack and send the respective request message.

ACA-Py currently provides the following APIs:

create-request allows to create a connection request and returns it, but there seems to be no exposed functionality to actually send the request.

I tried a simple hack adding

 # Send request
        responder = self._session.inject(BaseResponder, required=False)
        if responder:
            await responder.send(request, connection_id=conn_rec.connection_id)

for testing, but fetch_connection_targets fails because there's no invitation attached to the connection.

In addition, I don't understand the use case for receive-request, since I'd say requests should use the DIDcomm channel. Everything else should use the Out of Band API.

[domwoe]

Ok, what does work is using /out-of-band/receive-invitation with a payload like this:

{
  "@id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "handshake_protocols": [
    "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0"
  ],
  "services": [
    "did:web:478eb39f6464.ngrok.io"
  ]
}

So this works similar to the connections API.

[swcurran]

@domwoe while that works, sounds like the create-request approach should work. Do you agree? Or are we good with what you found did work?

I'm kind of with your initial comment -- that if you know a public DID with a DIDComm service block, you should be able to use it without having to use the OOB protocol. However, not sure what complexities that might create within ACA-Py.

[domwoe]

@swcurran Yes, I agree. I don't know the use cases for the create-request and receive-request routes, but a create and send request api would make sense. We could either extend the create-request route or add an additional route.

From an implementation point of view I think there should be an additional condition in BaseConnectionManager.fetch_connection_targets that catches the case where no invitation is present and gets the connection target information from connection.their_did and the resolver.

[swcurran]

@shaangill025 -- please add to your list. Thanks!

[domwoe]

Possible implementation would be here but not sure it's the way to go.

This leaves the current API untouched but adds POST ​/didexchange​/send-request with same parameters as create-request. It sends the request and returns the connection record.