Multiuse invitations and Qualified DIDs

[dbluhm]

Affected versions: 0.12.1, 1.0.0rc4, nightly-2024-07-19

There seems to be an issue in determining the correct inbound connection when using multi-use invitations and didexchange 1.1 with qualified DIDs.

Reproducible example can be found here: https://github.com/Indicio-tech/acapy-minimal-example/blob/test/multiuse-oob/examples/multiuse-oob/example.py

Small amount of context: ACA-Py uses a connection record to represent multi-use invitations.

If a connection is made with a multi-use invitation and then a message is sent to the resulting connection, the response to that message will be handled as though it had been sent by the multi-use invitation connection. In the example, this is demonstrated by sending a feature discovery message; ACA-Py's handler for the disclose message checks the connection_ready condition on the context and finds it as false, which is accurate because the multi-use invitation conn record is still in state invitation. The connection record as extracted from the logs of the call to the DiscloseHandler:

ConnRecord
(_id='1cd87e77-9a4a-49c7-93d0-3d972a0f1849', _last_state='invitation', _new_with_id=False, state='invitation', created_at='2024-07-19T16:27:10.277265Z', updated_at='2024-07-19T16:27:10.27726
5Z', my_did=None, their_did=None, their_label=None, their_role='invitee', invitation_key='De2YsJc9m3Lr9XeErdbjjMCSGFk9YwRBmw9V8q1Md3nd', invitation_msg_id='d39fca16-eaaa-40e7-b447-b56d8c085d
12', request_id=None, error_msg=None, inbound_connection_id=None, accept='manual', invitation_mode='multi', alias=None, their_public_did=None, connection_protocol='didexchange/1.1')

[jamshale]

In the minimum example you posted it's using the discovery v1 protocol. I did just add the connection_ready check on this handler. So, this might be why this test started failing.

However, I made some observations.

• I can replicate this with the discovery v2 protocol which already had the connection_ready check. So, I think the problem already existed. Adding the check to the discovery v1 protocol just allowed this to get caught by your test.
• Only the did-exchange/1.1 protocol has this issue. did-exchange/1.0 passes the connection_ready check with both discovery protocols.
• Oddly, If I restart the agent which created the multi-use invitation, then the connection is now in a connection_ready state and the discovery protocols succeed without issue.

Not sure if this helps at all? Seems like there's definitely an existing issue with the connection_ready status and multi-use invitations using did-exchange/1.1, that already existed, and adding this check recently got it caught by this test.

[dbluhm]

This lines up with what I was finding on Friday, thanks for your additional observations! I think I've narrowed down what's going on. In didex 1.1 when using did:peer:4, we shorten the DID to its short form in a few spots, particularly in inbound connection resolution in the base connection manager. However, the DID stored on the connection record isn't shortened until response/complete phase. So when we are receiving a connection complete response, we fail to look up the connection record by DID and instead it falls through and gets looked up by invitation message ID (parent thread ID) and we end up with the connection record for the multiuse invitation.

The verkey to connection lookup is then cached, which is why we get the invitation connection again on subsequent message handlers and why restarting the agent fixes the issue.