search

openwallet-foundation / acapy

ACA-Py is a foundation for building decentralized identity applications and services running in non-mobile environments.
https://aca-py.org
Apache License 2.0
419 stars 512 forks source link

(Edge case?) Mediation scenario creating unqualified DIDs #2851

Open dbluhm opened 8 months ago

dbluhm commented 8 months ago

POST /mediation/update-keylist/{conn_id} can create a DID if one does not exist for a connection. The goal of this was to enable the controller to ensure the keys associated with a connection are definitely known to the mediator before responding to an invite or request in connections or DID Exchange.

I think this approach needs reworking. I'm not sure if anyone is actually using this endpoint or not.

The mediation race condition problem is one I've attempted to solve before. To summarize the issue, since DIDComm and, therefore, the coordinate mediation protocol are asynchronous, it is difficult to complete an operation like creating keys and then responding to a DID Exchange request when using mediation since we'd have to wait indefinitely for the mediator to process the keylist update request. Most of the time, the mediator responds promptly, sooner than we're able to send off our DID Exchange request. But even slight network delays can disrupt this.

Having attempted to solve this problem a number of ways, I think I've come to a conclusion:

The most destward mediator (the "exit node" of a chain of mediators or the mediator closest to the recipient, the one accepting pickup and key list update requests from the mediated agent) must support responding to mediation clients with return routing when using the coordinate mediation protocol and must do so within a reasonable timeout (if using something like WebSockets for the transport where there isn't necessarily request-response return route semantics). All alternatives place a significant burden on implementers of agents supporting or requiring operation as a mediation client.

Enforcing operation in this manner dramatically simplifies the implementation of these chained actions where a tight turnaround is expected.

Maybe something to discuss on an Aries WG call or something.

TelegramSam commented 7 months ago

Philosophically, there is not a difference between waiting for a POST synchronous response and waiting for an inbound DIDComm message. Practically, it may be easier in an HTTP library than in our DIDComm message handling infrastructure. While I'd love to improve the message handling so that waiting for a response is easy and reliable, this may not be the moment.

Why only impose this on the exit mediator? I think setting the expectation of response like you describe should be imposed on all mediators.