TA2A - supporting A2A over TSP

[wenjing]

A2A is a google supported agent-to-agent protocol: https://github.com/a2aproject/A2A.
It has similarities with MCP and differences. On trust related features, A2A also relies on standard OpenAPI (e.g. HTTPS, TLS, PKI) methods. Therefore TSP may enhance A2A in a similar way as we enhance MCP (as in TMCP). Also similar to MCP, A2A uses JSON-RPC as its message passing pattern.

We propose to (1) use VID anchored identifier, a wallet and credentials for agent identity. (2) use TSP for transport.

The work therefore is similar to TMCP: make modifications to A2A client and server so that it uses a wallet with VIDs, make TSP/HTTP a new transport in addition to its current HTTP. This work should be suitable as a PR to A2A.

A2A also uses a AgentCard JSON doc as information for the agent. We propose also the enhance the AgentCard so that clients/users can verify that the AgentCard is authentic and bound to the VID. This can be done by adding VID to the AgentCard and signing by issuers, essentially making it into a verifiable credential. The AgentCard URL can also be added to a DID doc for binding. The credential checking step can be implemented in a A2A JSON-RPC call (aka credential presentation).

Similar to TMCP, we would want to put all sensitive data like API KEYs to the wallet securestore as well.

[wenjing]

[wenjing]

For more background, this video explains the goals and the approach of tmcp and ta2a.
https://youtu.be/cdQJ_LtVnTA?si=5v8yNmshZgr8562G

[michielp1807]

I did not yet get very far into implementing TA2A, but I did check out the A2A library to investigate whether an approach similar to that of TMCP should be possible for TA2A. I do think this is possible, but unfortunately we don't have enough time to do this within the remaining scheduled time.

Below are some technical notes which might be useful for implementing TA2A:

• A2A currently supports 3 different transports according to the docs (JSON-RPC 2.0 similar to MCP, gRPC using Google's own RPC format, and HTTP+JSON/REST using plain GET, POST, PUT, and DELETE HTTP requests), but the A2A protocol also allows custom transport extensions
• The server-side logic is a bit separated per transport type. There are separate functions for hosting e.g. a JSON-RPC server vs hosting a REST server. E.g. this hello world example server uses A2A's A2AStarletteApplication, which hosts a JSON-RPC server. On client-side, it seems the transport types are more streamlined.
• To implement TA2A, I would suggest creating a class that implements RequestHandler for the server-side (e.g. TA2ARequestHandler), and creating a class that implements ClientTransport for the client-side (e.g. TA2AClientTransport). These classes should then take care of opening and sealing all the messages using TSP. The TSP-specific logic can likely be implemented once for both server-side and client-side, similar to tmcp.py for our TMCP implementation.
• The a2a-samples repository has a nice demo with a chat bot that can interact with multiple agents. Unfortunately, this demo seems to interact with A2A servers through by manually sending POST requests instead of using an A2A client from the SDK. This makes it more difficult to use this demo setup for TA2A.
• The hello world example server does come with a test_client.py script that can be used to test the server. This test client uses a legacy A2AClient, which internally initializes a JsonRpcTransport (which is a ClientTransport). This could be used to test a TA2A implementation by either giving it the TA2AClientTransport or by initializing the client with the new ClientFactory.

Overall, I suspect implementing TA2A might be slightly cleaner compared to TMCP because the TA2A library is set up in a more modular way, which means we likely will be able to avoid having to modify the internal logic. I do think that the scope of TA2A is a bit bigger than TMCP, because A2A has many more kinds of transports and messages to support.