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

---
title: "Cross-Protocol Agent Translation (CPAT)"
abbrev: "CPAT"
category: std
docname: draft-cpat-cross-protocol-agent-translation-00
submissiontype: IETF
number:
date:
v: 3
area: "ART"
workgroup: "DISPATCH"
keyword:
  - agent interoperability
  - protocol translation
  - agentic workflows
  - execution context

author:
  -
    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 {#capability-ad}

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

~~~json
{
  "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 {#negotiation}

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 {#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:

~~~json
{
  "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 {#gateway-reqs}

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 {#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:

~~~json
{
  "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}}.