Hyperledger Aries Cloud Agent Python (ACA-Py) is a foundation for building decentralized identity applications and services running in non-mobile environments.
An ACA-Py agent has been given a DIDDoc from a mobile agent that has both a recipientKey and a routingKey. When a message is sent by the ACA-Py agent to the mobile agent via that route, the message is properly wrapped as a forward to the routing agent, who then gets the forwarded message to the mobile agent. All good.
However, when the mobile agent sends a message directly to the ACA-Py agent and includes a transport return route decorator, the ACA-Py agent prepares the message as a forward for the routing agent, but sends the message directly to the mobile agent via the HTTP response. That doesn't work - the mobile agent cannot process the forward.
Please fix ACA-Py. One of two things needs to change:
Ignore the return route when there is a routing agent needed, or
Don't wrap the message with any forwards if the return route is to be used.
Obviously 2 is the much better answer, although the 1st one could work for the short term.
This is an issue for many mobile agent to enterprise agent scenarios, so please look into this pretty quickly.
This issue was found by @mickrau.
An ACA-Py agent has been given a DIDDoc from a mobile agent that has both a recipientKey and a routingKey. When a message is sent by the ACA-Py agent to the mobile agent via that route, the message is properly wrapped as a forward to the routing agent, who then gets the forwarded message to the mobile agent. All good.
However, when the mobile agent sends a message directly to the ACA-Py agent and includes a transport return route decorator, the ACA-Py agent prepares the message as a forward for the routing agent, but sends the message directly to the mobile agent via the HTTP response. That doesn't work - the mobile agent cannot process the forward.
Please fix ACA-Py. One of two things needs to change:
Obviously 2 is the much better answer, although the 1st one could work for the short term.
This is an issue for many mobile agent to enterprise agent scenarios, so please look into this pretty quickly.