Closed jakubkoci closed 3 years ago
@TimoGlastra @JamesKEbert Is there any specification about how a mediation recipient should make a connection with a mediator? I'm asking mainly about the part about how the recipient is supposed to get the connection invitation, the rest is connection protocol of course.
Not an exact specification. Couple of routes we could take:
--mediator-invitation
to connect and request mediation afterwardsdid:sov
or did:web:example.com
to resolve the service endpoint and send a request afterwards.
{ "mediatorDid": "did:sov:xxxxx" }
I think it would be cool to have the mediator expose a did:web
containing the service endpoint (sort of like trinsic: https://trinsic.id/.well-known/did.json, but they don't use it for their mediation endpoint).
So as a starter maybe just use an invitation config parameter? ACA-Py adds the endpoint to the public did sov after startup. So we should be able to connect using just a DID. However to be able to resolve the endpoint from a did we need to do some extra work. Mainly resolving the did from ledger, retrieving the ATTRIB, so we can read the endpoint. Basically constructing a did document from the did:sov as https://dev.uniresolver.io/ does.
I think it would be cool to have the mediator expose a
did:web
containing the service endpoint (sort of like trinsic: trinsic.id/.well-known/did.json, but they don't use it for their mediation endpoint).
ACA-Py has a PR open for did:web: https://github.com/hyperledger/aries-cloudagent-python/pull/1143
Interesting, I hadn't considered using an implicit invitation with a public DID.
As of right now the primary method in ACA-Py AFAIK has been generating a multi-use invitation to kickstart the process. This could be a single-use of course as well, but multi-use has been the most well used.
My thought process for the methods in which you could make the connection and request mediation with the mediator would be:
So, I think this lines up with @TimoGlastra's thoughts above (let me know if I'm wrong).
Thanks, guys for your ideas. I'm not sure if I understand "use an invitation config parameter" correctly. Would it work for the edge agent running in a mobile app? I like the idea with did:web and .well-know/did.json
.
I created a new issue #371 because it's unrelated to WebSockets. We can continue there and I'm closing this one. The rest of the work mentioned in the description of the issue is also being worked on in a separate issue #268.
I needed to do the following changes (solved by #231):
Addreturn_route
parameter to outbound when there is no inbound connection (there is no service with endpoint other thandidcomm:transport/queue
)Addkeylist-update-response
message and handler, just with naive implementation.ExtractoutboundTransporter
as direct dependency in Agent’sconstructor
.Next steps on the way to support WebSockets transport I would like to do:
Extract also(solved by #245)inboundTransporter
from Agent’sconstructor
. (I can perhaps do it as part of this PR, but the changes started growing and I wanted to share what I have now.)Take outbound endpoint fromDidDoc
.Add WebSocket transporters.Add TransportService to keep info about current transport channels.Next steps I see we will need to do someday in near future but not necessarily before or right after adding the WebSockets (solved by #231):
Update download messages functionality to processbatch
message and to removesendAndReceiveMessage
that is still implemented in the old way relaying on synchronicity of HTTP request-response.