Agent-to-Agent (A2A) Communication with tsrct
Building on the trust and verification principles of Domain Delegated Extensions (DDX), tsrct can be used to establish secure and verifiable communication channels between autonomous agents (e.g., AI bots, automated services, or IoT devices).
This guide outlines a model for creating agent-to-agent (A2A) endpoints that are cryptographically secured, verifiable in real-time, and auditable.
1. The Core Concept
The fundamental idea is to treat every agent as a distinct entity within the tsrct ecosystem, identified by its own unique tsrct ID and associated key-pair. An organization (the “agent controller”) issues a DDX credential to each agent it operates. This “Agent DDX” serves as the agent’s digital identity and license to operate, defining its capabilities and permissions.
Communication between agents is brokered through the organization’s DDX Node, which exposes a new endpoint specifically for this purpose: /a2a.
2. The Agent DDX Credential
Before an agent can communicate, it must be issued a DDX credential by its controlling organization. This is a standard DDX tdoc with a specific schema designed for agents.
Example Agent DDX Schema (credential.json):
This JSON would be used to create the DDX for the agent.
{
"spec": {
"category": "agent",
"name": "Billing Automation Bot",
"design": {
"logo": "2222222222222222222222222.20240114-01-tsrct-logo",
"title": "Agent: Billing Automation",
"subtitle": "Handles automated invoice processing.",
"backgroundColor": "#1a73e8",
"foregroundColor": "#ffffff"
}
},
"data": {
"agentId": "billing-bot-001",
"version": "1.0.0",
"scope": "invoices.process,invoices.read",
"a2a_endpoint": "https://ddx.example.com/a2a/3333333333333333333333333.agent-billing-bot-001"
}
}
category: Must beagent.agentId: A human-readable identifier for the agent within the organization.scope: A comma-delimited list of permissions granted to the agent.a2a_endpoint: The fully qualified URL where the agent can be reached. The path includes the agent’s fulltsrctuid.
This DDX is issued using the same process as other DDX credentials, targeting the agent’s unique tsrct ID.
3. The /a2a Endpoint
The organization’s DDX Node, which handles credential verification, is extended to include an agent communication endpoint.
- Endpoint URL:
https://ddx.example.com/a2a/{agent-tsrct-uid} - Method:
POST - Body: A standard
tsrct doc(tdoc) representing the request from the initiating agent.
This endpoint acts as a verifiable gateway. It receives requests, validates the identity and authorization of the calling agent, and then routes the request to the appropriate backend logic that implements the agent’s functions.
4. A2A Communication Flow (The Handshake)
Here is the step-by-step process for one agent (Agent A) to send a verifiable request to another (Agent B).
Scenario:
- Agent A: A “reporting agent” that needs data from the billing bot.
- Agent B: The “billing agent” (
billing-bot-001from our example).
+-----------+ +----------------------+ +-----------+
| Agent A | | DDX Node (B Corp) | | Agent B |
| (Client) | | (ddx.b-corp.com) | | (Service) |
+-----------+ +----------------------+ +-----------+
| | |
| 1. Craft Request tdoc | |
| (Body: "get_invoice_summary") | |
| Signed with Agent A's private key | |
|----------------------------------| | |
| | | |
|<---------------------------------| | |
| | |
| 2. POST /a2a/{agent-b-uid} | |
| Body: <Agent A's tdoc> | |
|------------------------------------------------->| 3. Verify Agent A's tdoc & DDX |
| | - Is signature valid? |
| | - Is Agent A's DDX still active? |
| | - Does scope permit this action? |
| |------------------------------------------------->| 4. Forward Request
| | | (to internal service)
| | |
| | | |
| | | | 5. Process Request
| | | | & Craft Response tdoc
| | | |
| | |<-----| 6. Return Response tdoc
| | | | Signed with Agent B's key
| | |
| | 7. Countersign Response tdoc |
| | - Add DDX Node's signature |
| | |
|<-------------------------------------------------| 8. Return Countersigned Response |
| | |
| | |
| 9. Verify Response tdoc | |
| - Verify Agent B's signature | |
| - Verify DDX Node's countersignature | |
| | |
Flow Explained:
- Request Creation: Agent A creates a
tdoccontaining its request payload (e.g., a JSON command). It signs thistdocwith its own private key. - POST to Endpoint: Agent A looks up Agent B’s
a2a_endpointfrom its DDX and POSTs the signedtdocthere. - Initial Verification: The DDX Node for B Corp receives the request. It validates the signature on the incoming
tdocand checks that Agent A’s own DDX is currently valid and that its scope allows for this type of communication. - Forwarding: If verification passes, the DDX Node forwards the request payload to the internal business logic that powers Agent B.
- Processing: Agent B’s logic executes the request.
- Response Creation: Agent B generates a response
tdocand signs it with its private key. - Countersignature: The signed response
tdocis sent back to the DDX Node, which adds its own countersignature. This proves that Agent B was authorized by the organization at the moment it sent the response. - Return to Caller: The fully signed (and countersigned) response
tdocis sent back to Agent A. - Final Verification: Agent A verifies both Agent B’s signature and the DDX Node’s countersignature, giving it complete, cryptographic certainty of the response’s authenticity and Agent B’s authority.
5. Benefits of the A2A Model
- Zero-Trust Communication: No trust is assumed. Every message is signed, and the sender’s authority is verified in real-time.
- Real-time Revocation: If an organization revokes an agent’s DDX credential, it will instantly fail the verification step (step 3 or 7), effectively disabling the agent.
- Immutable Audit Trail: Every request and response is a signed
tdoc, creating a permanent and verifiable log of all agent interactions stored on thetsrctplatform. - Standardized and Discoverable: By using DDX, agents and their capabilities become discoverable and interoperable within the
tsrctecosystem. - Decentralized Execution: While verification is centralized at the DDX Node, the actual agent logic can be a microservice, a serverless function, or any other backend process, allowing for flexible and scalable architectures.