feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
315
workspace/drafts/new-drafts/draft-d-aepb-protocol-binding-00.md
Normal file
315
workspace/drafts/new-drafts/draft-d-aepb-protocol-binding-00.md
Normal file
@@ -0,0 +1,315 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user