316 lines
9.1 KiB
Markdown
316 lines
9.1 KiB
Markdown
---
|
|
title: "Agent Ecosystem Protocol Binding (AEPB): Interop and Lifecycle"
|
|
abbrev: "AEPB"
|
|
category: std
|
|
docname: draft-aepb-agent-ecosystem-protocol-binding-00
|
|
submissiontype: IETF
|
|
number:
|
|
date:
|
|
v: 3
|
|
area: "ART"
|
|
workgroup: "DISPATCH"
|
|
keyword:
|
|
- agent interoperability
|
|
- protocol translation
|
|
- lifecycle
|
|
- agentic workflows
|
|
|
|
author:
|
|
-
|
|
fullname: TBD
|
|
organization: Independent
|
|
email: placeholder@example.com
|
|
|
|
normative:
|
|
RFC2119:
|
|
RFC8174:
|
|
RFC8446:
|
|
RFC8615:
|
|
RFC9110:
|
|
I-D.nennemann-wimse-ect:
|
|
title: "Execution Context Tokens for Distributed Agentic Workflows"
|
|
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
|
|
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/
|
|
|
|
informative:
|
|
|
|
--- abstract
|
|
|
|
This document defines the Agent Ecosystem Protocol Binding (AEPB),
|
|
the interoperability and lifecycle layer of the agent ecosystem.
|
|
With over 90 competing A2A protocol drafts and no interoperability
|
|
standard, AEPB defines capability advertisement, protocol
|
|
negotiation, translation gateways, and agent lifecycle management
|
|
(versioning, graceful shutdown, retirement). Translation hops
|
|
produce ECT nodes, preserving DAG continuity across protocol
|
|
boundaries. Protocol constraints are expressed as ACP-DAG-HITL
|
|
node constraints.
|
|
|
|
--- middle
|
|
|
|
# Introduction
|
|
|
|
The IETF AI/agent landscape includes over 90 drafts proposing
|
|
agent-to-agent communication protocols. No standard exists for
|
|
agents using different protocols to exchange messages, and no
|
|
standard exists for how agents evolve, get replaced, or retire
|
|
without disrupting dependent services.
|
|
|
|
AEPB addresses both gaps with 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, fall back to translation gateways, and manage their
|
|
lifecycle.
|
|
|
|
AEPB builds on ECT {{I-D.nennemann-wimse-ect}} for audit (every
|
|
translation hop is a DAG node) and ACP-DAG-HITL
|
|
{{I-D.nennemann-agent-dag-hitl-safety}} for policy (protocol
|
|
constraints as node constraints).
|
|
|
|
# Conventions and Definitions
|
|
|
|
{::boilerplate bcp14-tagged}
|
|
|
|
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.
|
|
|
|
Translation Gateway:
|
|
: A service that converts messages between two agent protocols,
|
|
recording each translation as an ECT DAG node.
|
|
|
|
# Capability Advertisement {#capability}
|
|
|
|
Each AEPB-compliant agent MUST serve a capability document at
|
|
`/.well-known/aepb` {{RFC8615}}:
|
|
|
|
~~~json
|
|
{
|
|
"aepb_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/aepb/translate"
|
|
],
|
|
"ect_assurance_level": "L2",
|
|
"lifecycle": {
|
|
"status": "active",
|
|
"version": "2.1.0",
|
|
"deprecated_at": null,
|
|
"sunset_at": null,
|
|
"successor": null
|
|
}
|
|
}
|
|
~~~
|
|
{: #fig-capability title="Capability Document"}
|
|
|
|
The `protocols` array MUST contain at least one entry. `priority`
|
|
is OPTIONAL; lower values indicate higher preference.
|
|
|
|
The `lifecycle` object (see {{lifecycle}}) provides versioning and
|
|
deprecation metadata.
|
|
|
|
Agents SHOULD advertise via DNS SVCB records (`_aepb._tcp`).
|
|
|
|
# Protocol Negotiation {#negotiation}
|
|
|
|
When Agent A wants to communicate with Agent B:
|
|
|
|
1. Agent A fetches B's capability document over HTTPS.
|
|
|
|
2. Agent A computes the intersection of protocol lists. If
|
|
non-empty, the protocol with the lowest combined priority is
|
|
selected. Communication proceeds directly.
|
|
|
|
3. If no common protocol exists, Agent A checks translation
|
|
gateways listed by either agent:
|
|
|
|
~~~
|
|
GET /.well-known/aepb/gateway?from=a2a-v1&to=slim-v1
|
|
~~~
|
|
|
|
The gateway responds 200 if it supports the pair, 404 if not.
|
|
|
|
4. If a suitable gateway is found, Agent A sends its message to
|
|
the gateway, which translates and forwards.
|
|
|
|
5. If no gateway supports the pair, Agent A returns error
|
|
`no_translation_path`.
|
|
|
|
Negotiation is stateless and cacheable (Cache-Control, default
|
|
3600s).
|
|
|
|
# Translation as ECT DAG Nodes {#translation-ect}
|
|
|
|
Every translation hop produces an ECT:
|
|
|
|
- `exec_act`: `"aepb:translate"`
|
|
- `par`: the source agent's ECT
|
|
- `inp_hash`: SHA-256 of source protocol message
|
|
- `out_hash`: SHA-256 of translated message
|
|
|
|
~~~json
|
|
{
|
|
"exec_act": "aepb:translate",
|
|
"par": ["source-agent-ect-uuid"],
|
|
"inp_hash": "sha256-of-source-message",
|
|
"out_hash": "sha256-of-translated-message",
|
|
"ext": {
|
|
"aepb.source_protocol": "a2a-v1",
|
|
"aepb.dest_protocol": "slim-v1",
|
|
"aepb.gateway_id": "spiffe://gw.example.com/aepb",
|
|
"aepb.translation_warnings": []
|
|
}
|
|
}
|
|
~~~
|
|
{: #fig-translate-ect title="Translation ECT"}
|
|
|
|
This creates a three-node subgraph:
|
|
|
|
~~~
|
|
Source ECT → Gateway ECT (aepb:translate) → Dest ECT
|
|
~~~
|
|
|
|
The Execution-Context HTTP header survives protocol translation:
|
|
the gateway includes the translation ECT in the header of the
|
|
forwarded request.
|
|
|
|
## Translation Policy
|
|
|
|
Protocol constraints are ACP-DAG-HITL node constraints:
|
|
|
|
~~~json
|
|
{
|
|
"constraints": {
|
|
"aepb.allowed_source_protocols": ["a2a-v1", "mcp-v1"],
|
|
"aepb.allowed_dest_protocols": ["slim-v1"],
|
|
"aepb.max_translation_hops": 2
|
|
}
|
|
}
|
|
~~~
|
|
{: #fig-policy title="Translation Policy"}
|
|
|
|
Agents receiving a message SHOULD reject it if the ECT DAG
|
|
contains more translation hops than `aepb.max_translation_hops`.
|
|
|
|
# Translation Gateway Requirements {#gateway}
|
|
|
|
A gateway MUST:
|
|
|
|
1. Serve a capability document at `/.well-known/aepb/gateway`.
|
|
2. Accept messages via HTTP POST at its translate endpoint.
|
|
3. Produce an ECT per {{translation-ect}} for every translation.
|
|
4. Preserve message semantics. Fields without a destination
|
|
equivalent are carried in an extension field or dropped with
|
|
a warning in `aepb.translation_warnings`.
|
|
5. Require TLS 1.3 {{RFC8446}} for all connections.
|
|
6. Implement rate limiting per source agent.
|
|
|
|
A gateway MUST NOT modify payload semantics.
|
|
|
|
# Agent Lifecycle Management {#lifecycle}
|
|
|
|
## Lifecycle States
|
|
|
|
An agent's `lifecycle.status` MUST be one of:
|
|
|
|
- `active`: Normal operation. Default state.
|
|
- `deprecated`: Agent is functional but will be retired.
|
|
`deprecated_at` MUST be set. Clients SHOULD migrate to
|
|
`successor` if provided.
|
|
- `draining`: Agent is rejecting new workflows but completing
|
|
in-progress ones. New delegation requests return HTTP 503
|
|
with `Retry-After` header pointing to `successor`.
|
|
- `retired`: Agent is offline. Capability document returns
|
|
HTTP 410 Gone with `successor` for redirect.
|
|
|
|
## Versioning
|
|
|
|
The `lifecycle.version` field uses semantic versioning. Agents
|
|
MUST increment the major version when breaking changes occur
|
|
(incompatible protocol or behavior changes).
|
|
|
|
Capability documents MUST include the version. Agents SHOULD
|
|
include version in ECT `ext` claims (`aepb.agent_version`) so
|
|
the audit trail records which version performed each action.
|
|
|
|
## Graceful Shutdown
|
|
|
|
When an agent transitions to `draining`:
|
|
|
|
1. Update capability document: `status: "draining"`,
|
|
set `sunset_at` timestamp.
|
|
2. Reject new workflow delegations with HTTP 503.
|
|
3. Complete all in-progress workflows.
|
|
4. Emit a final ECT: `exec_act: "aepb:shutdown"`.
|
|
5. Transition to `retired`.
|
|
|
|
Agents SHOULD provide at least 24 hours between `deprecated`
|
|
and `draining` to allow clients to discover the change via
|
|
cached capability documents.
|
|
|
|
## Successor Discovery
|
|
|
|
When `successor` is set, it MUST be the URI of the replacement
|
|
agent's capability document. Clients SHOULD transparently
|
|
redirect to the successor after verifying its capability
|
|
document.
|
|
|
|
# Security Considerations
|
|
|
|
Capability documents are served over HTTPS. Agents SHOULD verify
|
|
TLS certificates before trusting capability documents.
|
|
|
|
Gateways are trusted intermediaries with access to message content.
|
|
For end-to-end confidentiality, agents MAY encrypt message payloads
|
|
with a shared key established out of band.
|
|
|
|
The ECT audit trail enables detection of unauthorized gateways,
|
|
content tampering (mismatched `inp_hash`/`out_hash`), and routing
|
|
loops (repeated gateway IDs in DAG ancestry).
|
|
|
|
Lifecycle transitions (especially `draining` and `retired`) can be
|
|
exploited for denial of service. Only the agent operator (verified
|
|
via identity binding) SHOULD be able to update lifecycle status.
|
|
|
|
# IANA Considerations
|
|
|
|
This document requests:
|
|
|
|
1. A "AEPB Protocol Identifier" registry under Expert Review.
|
|
Initial entries: `a2a-v1`, `mcp-v1`, `slim-v1`, `uacp-v1`,
|
|
`ainp-v1`.
|
|
|
|
2. Well-known URI registrations for `aepb` and `aepb/gateway`
|
|
per {{RFC8615}}.
|
|
|
|
3. Registration of `exec_act` values: `aepb:translate`,
|
|
`aepb:shutdown` in a future ECT action type registry.
|
|
|
|
--- back
|
|
|
|
# Acknowledgments
|
|
{:numbered="false"}
|
|
|
|
AEPB builds on ECT {{I-D.nennemann-wimse-ect}} for translation
|
|
audit trails and ACP-DAG-HITL
|
|
{{I-D.nennemann-agent-dag-hitl-safety}} for protocol policy.
|