feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -0,0 +1,354 @@
|
||||
---
|
||||
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}}.
|
||||
Reference in New Issue
Block a user