DIDComm based Protocol for AATH to Agent Backchannel Comms

[nodlesh]

Goal: Develop a DIDComm-based (DRPC) back-channel communication protocol to facilitate testing for any Aries agent including headless mobile.

Description:
We aim to create a communication framework using DIDComm (Decentralized Identity Communication) and DRPC (Decentralized Remote Procedure Call) to enable back-channel interactions in AATH with Aries Agents. This will support the seamless, headless testing of Aries agents, allowing for automated and efficient testing processes without the need for a user interface.

This proposal would impact the Aries Frameworks. There would be a relatively simple protocol with a handful of APIs to allow AATH to control an agent through this protocol as it does now through the backchannel API. Each Aries Framework would have to implement this protocol to participate in the interop test suite. The protocol could even become part of AIP #.# or whatever means we have to determine that protocols should be implemented at a given level.

The backchannel logic for each framework would be moved inside the framework, and developed in the frameworks repo. The hope is that the backchannel logic would be maintained as protocols get added or changed, and that the testing of these protocols with other frameworks will be front and centre to development of these frameworks.
The above perceived benefit may not be the case. The Backchannel is a controller and there is no reason this needs to move inside the frameworks. So the Backchannel is probably still external, maybe in its own repo, in a plug-in or stay in AATH?

When working with a mobile agent (mobile wallet) The wallet and AATH would need a connection, then once connected, the mobile agent can go into "headless mode" and allow AATH to send instructions to the wallet to communicate over didcomm to issuers, verifiers, and other wallets/holders.

Some initial draft thoughts on what it might look like:
https://hackmd.io/@wrf54Y6BSmWpzuBx9yJg_Q/S1Ih_h_rR

Summary of Questions, Concerns & Comments:

1. Connection between AATH and the Agent with a DIDComm Connection? before DRPC can happen? How?
2. AATH would have to initiate the connection.
3. The Test Protocol could be a plugin?
4. Is there another use case for having DRPC calls through this protocol besides testing?
5. The Headless Mobile use case should be enough of a reason to move forward. However, as Daniel Bluhm mentions below, "The main value is mobile agent backchannel and I think this can and should be done independent of the backchannel interfaces of other agent implementations."
6. AATH using DIDComm V2 for connectionless operations. DID as a toggle and allow-list for DRPC protocol.

Current Proposed:

[nodlesh]

Adding some Good conversation in the chat from ACAPUG on July 23, 2024

11:13:20 From Daniel Bluhm to Everyone:
Jotting down some thoughts:
- Backchannel is heavier?
- Security? Backchannel accidentally left in production builds
- Mobile agent could have the backchannel operate over DRPC still without moving all agents under test to DRPC
- When we're testing connection, it can be painful for the backchannel itself to depend on connections
11:15:02 From Akiff Manji to Everyone:
That's why I like the idea of it being a plugin
11:15:07 From Colton Wolkins to Everyone:
Replying to "Jotting down some ..."

If DIDComm V2 is used, it's connectionless so you could get away with a whitelist a particular DID instead of relying on connections

11:15:33 From Daniel Bluhm to Everyone:
Replying to "Jotting down some th..."

But then we need the agents to support DCv2 🙃

11:15:44 From Colton Wolkins to Everyone:
Replying to "Jotting down some ..."

Let's push for it!

11:16:03 From Colton Wolkins to Everyone:
Reacted to "But then we need t..." with 😂
11:16:30 From Daniel Bluhm to Everyone:
Replying to "Jotting down some th..."

There's still an element of the tests testing themselves: no connections required in DCv2 but there are still other elements of DIDComm that would be tested, e.g. packing, unpacking, DID resolution, etc

11:16:47 From Colton Wolkins to Everyone:
Reacted to "There's still an e..." with ➕
11:16:48 From Colton Wolkins to Everyone:
Reacted to "There's still an e..." with 💯
11:17:26 From Daniel Bluhm to Everyone:
We've done this before in ACA-Py, it was the aries toolbox plugin and admin protocol associated with it
11:18:23 From Daniel Bluhm to Everyone:
Maintaining two separate "Admin API" interfaces is a pain; for it to be feasible, ACA-Py would need to have a layer behind the REST Admin API that would be reusued by both interfaces
11:18:55 From Patrick St.Louis to Everyone:
Reacted to "Jotting down some th..." with 👍
11:18:59 From Daniel Bluhm to Everyone:
I wouldn't mind that refactoring taking place but it would be a very significant undertaking
11:19:34 From Emiliano Suñé to Everyone:
Replying to "Jotting down some th..."

Might be tricky to use an allow-list with agents that are spooled-up at test runtime and do not persist wallet storage?

11:20:27 From Patrick St.Louis to Everyone:
@daniel Bluhm said:
Mobile agent could have the backchannel operate over DRPC still without moving all agents under test to DRPC

I think this is something to investigate as it will reduce the ongoing maintenance while addressing the initial concern (testing mobile)

11:23:51 From Colton Wolkins to Everyone:
Replying to "Jotting down some ..."

My thought there was that, when they are spooled up, a did (possibly did:key or did:peer) would be passed in during startup. By passing the DID, that would act as both a toggle for the DRPC protocol as well as setting the allow-list for the DRPC protocol.

Not 100% on how feasible it is, I was just spitballing ideas.

11:26:35 From Daniel Bluhm to Everyone:
Replying to "@daniel Bluhm said:
..."

Extending on my initial thought, I see little value in adding DRPC layer to agents like ACA-Py or even Credo. The maintenance issue for Credo backchannel isn't helped by DRPC.

The main value is mobile agent backchannel and I think this can and should be done independent of the backchannel interfaces of other agent implementations.

11:26:43 From Patrick St.Louis to Everyone:
Reacted to "Extending on my init..." with 👍
11:26:54 From Patrick St.Louis to Everyone:
Replying to "@daniel Bluhm said:
..."

+1

11:30:35 From Colton Wolkins to Everyone:
Reacted to "My thought there w..." with ➕
11:30:47 From Colton Wolkins to Everyone:
Removed a ➕ from "My thought there w..."
11:30:52 From Colton Wolkins to Everyone:
Reacted to "Extending on my in..." with ➕
11:35:43 From Jamie Hale to Everyone:
Even if it has some of the same issues and is a lot of work. The mobile headless testing would be worth it imo.
11:36:15 From John Nathaniel Jr to Everyone:
Reacted to "Even if it has som..." with 👍
11:38:45 From Daniel Bluhm to Everyone:
I agree, I think it's a decent approach for mobile testing without reinventing the wheel of server to mobile communication we already invented with DIDComm. I think we should keep this separate from the backchannels of other agents, though, keeping complexity where it's needed and necessary and not introducing it where it's not needed
11:43:56 From Emiliano Suñé to Everyone:
Reacted to "Even if it has some ..." with 👍🏻
11:43:59 From Daniel Bluhm to Everyone:
Yeah, what you said is accurate

[nodlesh]

Link to the July 23, 2024 ACAPUG recording where this was discussed is here, https://wiki.hyperledger.org/display/ARIES/2024-07-23+Aries+Cloud+Agent+-+Python+Users+Group+Community+Meeting

[swcurran]

I think that establishing the connection would be done something like the following:

• The AATH Engine starts up and publishes a multiuse invitation — or perhaps just publishing a DID that contains the DIDComm endpoint for the engine.
• The various backchannels start up, receiving as a parameter the invitation or the DID for the Engine.
• Each backchannel uses the invitation/DID to request a connection with the engine, specifying (probably via the label) what role they will place (ACME, Bob, Faber, Mallory).
• The Engine accepts all of the invitations as they are received, noting which connection corresponds to which role.
• The Engine starts the tests when it has exactly one connection for each role. If it gets multiple connections for the same role, or times out waiting for all the roles to be filled, it sends a Problem Report message to each connection and terminates.

Note that this setup does not take into account the current feature of being able to restart a test agent with a different configuration when needed. This is a common thing done in ACA-Py tests — restarting the agents with different startup parameters between tests.

[swcurran]

I think the only thing this gets us is the ability to directly connect to a wallet to play a headless role in the testing. It doesn’t move any of the backchannel features into the frameworks — they remain in the backchannel controller. It’s a pretty big change to the architecture and the existing backchannel for a relatively small addition to the capability. A good addition, but all the changes needed in the existing backchannels don’t result in any benefits — and perhaps some loss of functionality.

What about doing this? Add a “wallet-backchannel” that:

• receives HTTP commands from the engine, like any other backchannel.
• publishes an invitation or DID for the wallet to use.
• the test wallet is informed of the invitation/DID and connects to the wallet-backchannel via DIDComm
• the backchannel sends DRPC requests to the wallet — as planned above.
• the wallet implements an internal controller that carries out the DRPC requests in a headless way.

I think we get the same result and have to do the same thing in the wallet, but we don’t change the architecture, and we don’t have to update the ACA-Py, Credo and Aries VCX backchannels.

[nodlesh]

Just wanted to note that doing anything mentioned in this issue doesn't totally eliminate the need to put the wallet into a state to be able to accept a connection. App startup, initialization, and user onboarding may still need to happen using UI automation. This means that to run this fully automated and/or in test/build pipelines would require some of the infrastructure of the Aries Mobile Test Harness/Mobile Wallet Test Harness.

[JamesKEbert]

I haven't been involved in too many of the conversations on this proposed protocol, but I wanted to provide some feedback on this--I think it would be cool, but I have some concerns:

1. Having our testing framework rely on the technology we're testing could prove potentially troublesome. For instance, if there are issues with connections, then it's possible that testing fails for all tests, when that's not really accurate to the situation. But, I think this could potentially be outweighed by the benefits of enabling testing in mobile contexts.
2. I am concerned about the usage of DRPC in this context. From my perspective, it would be better to create a new protocol or set of protocols to handle this, rather than create a new DRPC service that gets piped over DIDComm. This could be something that looks like the existing aries-toolbox admin api protocols:

• https://github.com/hyperledger-archives/aries-toolbox/blob/main/docs/README.md
• https://github.com/hyperledger-archives/aries-toolbox/blob/main/docs/admin-basicmessage/0.1/README.md
• https://github.com/hyperledger-archives/aries-toolbox/tree/main/docs/admin-connections/0.1/README.md
• (Many more defined protocols)

[nodlesh]

1. Having our testing framework rely on the technology we're testing could prove potentially troublesome. For instance, if there are issues with connections, then it's possible that testing fails for all tests, when that's not really accurate to the situation. But, I think this could potentially be outweighed by the benefits of enabling testing in mobile contexts.

Yes, I agree in principle to this, and I also mentioned something akin to this in the ACAPug meeting when we talked about this solution. However upon further reflection, the testing principle at play here is the fact that we don't want the system under test to do any validation of the system under test(itself). In this case, we may use the system under test to establish a connection to service the actual testing on mobile, so no testing or validation is done unless this connection is established. In other words it is part of the test setup procedure(test fixture) before any validation happens and if this setup procedure fails then we don't run tests or do any validation.

[swcurran]

After the discussion on the call, I don’t think this makes sense as a change for all Test Agents/Backchannels. In listening to the discussion at the ACA-Pug meeting, I don’t think this approach gives much value for other than the mobile agent test case. For that, I think that enhancing the existing mobile backchannel should be considered as the easiest way to do periodic runs. For automated runs, so sort of headless wallet mechanism would be needed.

Or, we could go down this root for a mobile wallet. Create a backchannel for a specific wallet (e.g. Bifold/BC Wallet — that is perhaps general enough for other wallets) that uses DIDComm and DRPC to control the wallet. The backchannel would use the same HTTP interface between the test engine and the backchannel as all backchannels, but the backchannel and the Bifold (or whatever)instance would use DIDComm to tell the instance what to do. Not easy though:

• I’m not sure how/where an instance of Bifold/BC Wallet would be deployed suitable for use with AATH
• How a connection would be established between the backchannel and the wallet to allow the backchannel to control the wallet.
• How the backchannel can drive the interface, and if AATH-specific code would be required in the Bifold wallet instance.