No connection re-use with OpenAPI Demo via Docker Faber-Alice Out of Band Invitations (OOB)

[watkinspd]

Two potential issues:

1: Unable to re-use connections with OOB in Faber-Alice OpenAPI demo.
I am excercising the Aries OpenAPI Demo using the following guide:
https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/AriesOpenAPIDemo.md

I am running the demo via Docker Desktop MacOS. I am trying to use Faber-Alice to test Out of Band Invitations (OOB). I am generating OOB invitations on Faber and receiving them on Alice.

I am able to make and use connections if I specify
"use_public_did": false
in
/out-of-band/create-invitation
I verified this by sending messages over the resulting connections from both Faber and Alice.

However I am unable to generate or accept OOB invitations that result in the re-use of established connections. Each attempted re-use of an invitation, or use of a new invitation results a in a new connection.

If I change my approach to specify
"use_public_did": true
in
/out-of-band/create-invitation
I get
400: Public invitations are not enabled

I reviewed

https://github.com/hyperledger/aries-rfcs/blob/main/features/0434-outofband/README.md

The tutorial does not explicitly describe the requirements for connections to be re-used so I am unsure why my efforts are not working. My hope would be that connection re-use can be done using the OpenAPI Faber-Alice demo via docker.

2: Faber-Alice OpenAPI demo - always setting "their_label": "alice.agent" on Faber side.
I have noticed that the connections on the Faber side always have
"their_label": "alice.agent"
when using
/out-of-band/receive-invitation
regardless of the alias or label that is used in the OOB invitation on the Alice side.

[swcurran]

@ianco -- can you please take a look? Perhaps we need some docs on how to reuse connections in Alice/Faber?

[ianco]

To get the reuse I believe (off the top of my head) you need to startup aca-py with the --public-did parameter (or something like that), which we don't do for the demo agents.

Would you like me to add this parameter? Or add a new param to alice/faber for example ./run_demo faber --allow-public-did?

[swcurran]

First step is to help Peter achieve what he is trying to do. Once that is working and you have a good handle on how the reuse can be achieved, please think about how to convey it to others. Note sure how best to do that -- perhaps a doc, but I was thinking perhaps Alice-Faber. Since I don't know exactly how it works, I'm not sure.

[ianco]

Regarding #2, the label is always set by the agent, so for example faber will always set the label on their side of the connection and alice will set the label on her side. I believe the label is shared with the other agent on the connection, so if I am alice I will see a their_label on the connection which is whatever faber set their label to (and vice versa).

The alias on the other hand is used to label the connection on the side of whoever holds the connection and is not shared with the other agent. The idea is that each agent will have a label that is used consistently (e.g. Faber.agent) so anyone who connects to faber will see this in their_label, however they can set whatever alias they like (similar to how you can set an alias on your contact list on your phone). This gives the agent some control over how their "address book" looks, but they can still see the label as advertised by the other agent.

[ianco]

Regarding #1, this requires the aca-py agent to start up with the --public-invites parameter. I'll add this to the alice/faber demo agents, however in the meantime you can add this parameter to your local demo code here: https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/runners/support/agent.py#L335

[ianco]

@swcurran protocol question - if Faber sets use_public_did on their invite, and then Alice sets use_existing_connection when she receives the invite, then Alice will reuse her existing connection (upon the second invite).

However how does Faber know? As far as I can tell Alice correctly picks up the existing connection, but Faber has an outstanding invite that doesn't seem to get any response back ...

[swcurran]

The message from Alice has a pthid from the invitation that she received. So Faber can tell both the connection on which the message was received (has to, to be able to read it) and, via the pthid, the invitation to which it is connected. From there, @shaangill025 recently added some functionality to remove the hanging invite, and the controller should know what to do once the connecting process has completed, again, using the pthid. PR #1521 and #1525 addressed the hanging connection records from the unused invitations.

Make sense?

[ianco]

@swcurran yes thanks, I'll dig into the demo code to see what's going on

[ianco]

Hmmm I think there's a bug in aca-py. I can see Alice sending the "connection reuse" message and Faber receives it, however I don't think there's a webhook for a re-used connection, so the Faber controller doesn't ever find out that the connection was reused.

Same on the Alice side - Alice gets the "reuse accepted ack" message but there is no webhook.

[shaangill025]

Hmmm I think there's a bug in aca-py. I can see Alice sending the "connection reuse" message and Faber receives it, however I don't think there's a webhook for a re-used connection, so the Faber controller doesn't ever find out that the connection was reused.

Same on the Alice side - Alice gets the "reuse accepted ack" message but there is no webhook.

Currently, there is no webhook emitted for connection reuse on either side, I can add this in right away if the following is acceptable.
Basically, I will have to call profile.notify with acapy::webhook::connection_reuse and acapy::webhook:connection_reuse_accepted topics on invitee and inviter side resp and payload will be something similar:

{
   "thread_id": "{reuse_msg_id}",
   "comment": "Connection {conn_id} is being reused for invitation {invi_msg_id}"
}

[ianco]

Hi @shaangill025 , that would be great! I was just digging into the code, but it sounds like you know what needs to be done so would probably be quicker for you. I suggest that the web hook payload should contain each attribute individually, in addition to what is in the comment:

{
   "thread_id": "{reuse_msg_id}",
   "connection_id": "{conn_id}",
   "state": "<? accepted or rejected?>",
   "comment": "Connection {conn_id} is being reused for invitation {invi_msg_id}"
}

[swcurran]

This was addressed in #1581