ietf-draft-analyzer/workspace/drafts/new-drafts/draft-cpat-cross-protocol-agent-translation-00.md

fullname: Generated by IETF Draft Analyzer
organization: Independent
email: placeholder@example.com

normative: RFC7519: RFC7515: RFC9110: RFC8615: I-D.nennemann-wimse-ect: title: "Execution Context Tokens for Distributed Agentic Workflows" target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/

informative: I-D.nennemann-agent-dag-hitl-safety: title: "Agent Context Policy Token: DAG Delegation with Human Override" target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/

--- abstract

This document defines the Cross-Protocol Agent Translation (CPAT) framework, a mechanism enabling AI agents using different communication protocols to interoperate. With over 90 competing agent-to-agent protocol drafts and no interoperability standard, protocol fragmentation is the primary barrier to multi-vendor agent ecosystems. CPAT defines capability advertisement, protocol negotiation, and translation gateways. Translation hops are recorded as Execution Context Token (ECT) DAG nodes, giving every cross-protocol interaction a cryptographic audit trail without inventing a parallel tracing mechanism.

--- middle

Introduction

The IETF AI/agent landscape includes over 90 drafts proposing agent-to-agent communication protocols, yet no standard exists for agents using different protocols to exchange messages.

CPAT takes a pragmatic approach: rather than mandating a single protocol, it defines the minimum machinery for agents to discover each other's protocol support, agree on a common format, and fall back to translation gateways when no common protocol exists.

CPAT builds on Execution Context Tokens {{I-D.nennemann-wimse-ect}} as its audit and tracing backbone. Every translation hop produces an ECT, linking into the workflow DAG alongside the source and destination agents. This eliminates the need for a separate tracing or provenance mechanism -- the ECT DAG already provides it.

Design principles:

1. Reuse existing standards (HTTP, JSON, TLS, ECT) wherever possible.
2. Keep the core mechanism small enough to implement in a day.
3. Do not require agents to support any protocol beyond their own plus CPAT negotiation.

Conventions and Definitions

{::boilerplate bcp14-tagged}

The following terms are used in this document:

Agent Protocol:

A communication protocol used by an AI agent for peer-to-peer message exchange (e.g., A2A, MCP, SLIM, uACP).

Capability Document:

A JSON object describing the protocols an agent supports, served at a well-known URI.

Translation Gateway:

A service that converts messages between two agent protocols, recording each translation as an ECT DAG node.

Problem Statement

Consider three agents: Agent A speaks Protocol X, Agent B speaks Protocol Y, and Agent C speaks both X and Z. Today there is no standard way for A to discover that B uses a different protocol, negotiate a common format, or route through a translator.

Existing work on Agent Name Service (ANS) and agent discovery addresses finding agents but not protocol compatibility. CPAT fills the gap between discovery and communication.

Protocol Capability Advertisement

Each CPAT-compliant agent MUST serve a capability document at the well-known URI /.well-known/cpat {{RFC8615}}. The document is a JSON object:

{
  "cpat_version": "1.0",
  "agent_id": "spiffe://example.com/agent/pricing",
  "protocols": [
    {
      "id": "a2a-v1",
      "version": "1.0",
      "endpoint": "https://agent.example.com/a2a",
      "priority": 10
    },
    {
      "id": "mcp-v1",
      "version": "2025-03-26",
      "endpoint": "https://agent.example.com/mcp",
      "priority": 20
    }
  ],
  "translation_gateways": [
    "https://gateway.example.com/cpat/translate"
  ],
  "ect_assurance_level": "L2"
}

{: #fig-capability title="Capability Document Example"}

The protocols array MUST contain at least one entry. Each entry MUST include id (a registered protocol identifier), version, and endpoint. The priority field is OPTIONAL; lower values indicate higher preference.

The ect_assurance_level field declares the minimum ECT assurance level the agent requires for interactions. This enables gateways to produce ECTs at the correct level.

Agents SHOULD also advertise their capability document URI in DNS SVCB records. The DNS record type _cpat._tcp SHOULD be used.

Negotiation Handshake

When Agent A wants to communicate with Agent B:

Step 1:

Agent A fetches Agent B's capability document from B's well-known CPAT URI over HTTPS.

Step 2:

Agent A computes the intersection of its own protocol list with Agent B's. If the intersection is non-empty, the protocol with the lowest combined priority score is selected. Communication proceeds directly using that protocol.

Step 3:

If no common protocol exists, Agent A checks whether any translation gateway listed by either agent supports both protocols. Agent A queries the gateway:

GET /.well-known/cpat/gateway?from=a2a-v1&to=slim-v1

The gateway responds with 200 OK if it supports the pair, or 404 if not.

Step 4:

If a suitable gateway is found, Agent A sends its message to the gateway, which translates and forwards it to Agent B. The gateway records the translation as an ECT (see {{ect-integration}}).

Step 5:

If no gateway supports the required pair, Agent A returns an error to its caller with error code no_translation_path.

The entire negotiation is stateless and cacheable. Agents SHOULD cache capability documents for the duration indicated by HTTP Cache-Control headers, defaulting to 3600 seconds.

ECT Integration

Every translation hop produces an ECT {{I-D.nennemann-wimse-ect}} that links into the workflow DAG. This provides cryptographic proof of protocol translation without a separate tracing mechanism.

Translation ECT Claims

A gateway producing a translation ECT MUST set:

• exec_act: "cpat:translate"
• par: array containing the jti of the source agent's ECT
• wid: the workflow identifier from the source ECT (preserving workflow continuity across protocol boundaries)

The ext claim carries CPAT-specific metadata:

{
  "ext": {
    "cpat.source_protocol": "a2a-v1",
    "cpat.dest_protocol": "slim-v1",
    "cpat.gateway_id": "spiffe://gw.example.com/cpat",
    "cpat.translation_warnings": []
  }
}

{: #fig-translation-ect title="Translation ECT Extension Claims"}

The inp_hash claim MUST contain the SHA-256 hash of the source protocol message. The out_hash claim MUST contain the SHA-256 hash of the translated message. This allows verifiers to confirm that a specific input produced a specific output without accessing the message content.

Assurance Level Inheritance

The gateway MUST produce ECTs at the higher of:

• The source agent's declared ect_assurance_level
• The destination agent's declared ect_assurance_level

At L3, the translation ECT MUST be recorded in the audit ledger before the translated message is forwarded to the destination agent.

DAG Continuity

The translation creates a three-node subgraph in the workflow DAG:

Source Agent ECT (exec_act: "send_task")
      |
      v  [par reference]
Gateway ECT (exec_act: "cpat:translate")
      |
      v  [par reference]
Dest Agent ECT (exec_act: "receive_task")

{: #fig-dag-continuity title="Translation DAG Subgraph"}

The Execution-Context HTTP header {{I-D.nennemann-wimse-ect}} survives protocol translation: the gateway includes the translation ECT in the Execution-Context header of the forwarded request to the destination agent.

Translation Gateway Requirements

A CPAT translation gateway MUST:

1. Serve a capability document listing all supported protocol pairs at /.well-known/cpat/gateway.

2. Accept messages via HTTP POST at its translate endpoint.

3. Produce an ECT for every translation per {{ect-integration}}.

4. Preserve message semantics: the intent, core payload content, and metadata MUST survive translation. Fields with no equivalent in the destination protocol SHOULD be carried in a protocol-specific extension field or dropped with a warning recorded in cpat.translation_warnings.

5. Return the translated message in the response body, or forward it directly to the destination agent.

A gateway MUST NOT modify payload semantics during translation.

Gateways MUST require TLS 1.3 for all connections and SHOULD implement rate limiting per source agent.

Policy Integration

When used with the Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}}, CPAT-related policies can be expressed as DAG node constraints:

{
  "dag": {
    "nodes": [
      {
        "id": "n-translate",
        "type": "cpat:translate",
        "agent": "spiffe://gw.example.com/cpat",
        "constraints": {
          "allowed_source_protocols": ["a2a-v1", "mcp-v1"],
          "allowed_dest_protocols": ["slim-v1"],
          "max_translation_hops": 2
        }
      }
    ]
  }
}

{: #fig-policy title="CPAT Policy as DAG Node Constraints"}

The max_translation_hops constraint prevents messages from being translated through an excessive number of gateways. Agents receiving a message SHOULD reject it if the ECT DAG contains more translation hops than allowed by policy.

Security Considerations

Capability documents are served over HTTPS, ensuring transport security. Agents SHOULD verify TLS certificates before trusting capability documents.

Gateways are trusted intermediaries with access to message content during translation. For end-to-end confidentiality, agents MAY encrypt the message payload using a shared key established out of band; the gateway translates only the protocol framing, not the encrypted content.

The ECT audit trail ({{ect-integration}}) enables detection of:

• Unauthorized gateways (unexpected cpat.gateway_id in the DAG)
• Content tampering (mismatched inp_hash/out_hash relative to message content)
• Routing loops (repeated gateway IDs in the DAG ancestry)

At L3, the audit ledger provides tamper-evident proof of all translations for regulatory compliance.

IANA Considerations

This document requests the following IANA registrations:

1. A "CPAT Protocol Identifier" registry under Expert Review policy. Initial entries: "a2a-v1", "mcp-v1", "slim-v1", "uacp-v1", "ainp-v1".

2. A well-known URI registration for "cpat" per {{RFC8615}}.

3. Registration of the exec_act value "cpat:translate" in a future ECT action type registry.

--- back

Acknowledgments

{:numbered="false"}

This document builds on the Execution Context Token specification {{I-D.nennemann-wimse-ect}} and the Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}}.