---
title: "Agent Ecosystem Protocol Binding (AEPB): Interop and Lifecycle"
abbrev: "AEPB"
category: std
docname: draft-aepb-agent-ecosystem-protocol-binding-01
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:
  RFC8594:
  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, formal binding requirements, translation gateway
architecture, 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,
  lifecycle status, and ECT assurance level.

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

Protocol Binding:
: The mapping between the AEPB ecosystem semantics and a specific
  agent protocol.  Each binding has a stable identifier string.

Binding Identifier:
: A short string identifying a specific protocol binding
  version (e.g., `a2a-v1`, `mcp-v1`).

# Capability Advertisement {#capability}

## Capability Document Format

Each AEPB-compliant agent MUST serve a capability document at
`/.well-known/aepb` per {{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",
  "ect_namespaces": ["atd", "hitl", "apae"],
  "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 `ect_namespaces` field MUST list all ECT extension namespaces
(ATD, HITL, APAE) that this agent emits and can process.  Peers
use this to determine whether ecosystem semantics are compatible.

The `lifecycle` object (see {{lifecycle}}) provides versioning and
deprecation metadata.

## DNS-SD Advertisement

Agents SHOULD advertise via DNS SVCB records (`_aepb._tcp`) as
an alternative to well-known URI discovery.  The SVCB record
MUST include a `hint` parameter pointing to the well-known URI.

## Capability Document Caching

Capability documents MAY be cached per HTTP cache-control
semantics per {{RFC9110}}.  The default max-age is 3600 seconds.
Agents MUST set `Expires` or `Cache-Control: max-age` on
capability document responses.

# 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 HTTP/1.1
~~~

   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 MUST return error
   `no_translation_path` and MUST NOT proceed.

Negotiation is stateless and cacheable (Cache-Control, default
3600s).

## Protocol Downgrade Prevention

Protocol negotiation MUST NOT result in selection of a binding
below the minimum configured in ACP-DAG-HITL node constraints:

~~~json
{
  "constraints": {
    "aepb.min_protocol_security": "tls-1.3"
  }
}
~~~

Agents MUST reject capability documents that advertise only
protocols below their configured minimum security requirement.
Specifically, all protocols MUST use TLS 1.3 {{RFC8446}}; no
plaintext bindings are permitted in production deployments.

# Conforming Protocol Binding Requirements {#binding-requirements}

A protocol binding MUST satisfy the following requirements to be
registered in the AEPB Protocol Binding Registry.

## ECT Carriage

A conforming binding MUST provide a mechanism to carry ECTs
alongside protocol messages.  For HTTP-based protocols, this
MUST be the `Execution-Context` header as defined in
{{I-D.nennemann-wimse-ect}}.  For non-HTTP protocols, the
binding specification MUST define an equivalent envelope field.

## Task Invocation with Parent Reference

A conforming binding MUST support task invocation messages that
include a reference to the parent ECT `jti`.  This allows the
receiving agent to link the new task into the ECT DAG.

## Checkpoint and Rollback Signal Carriage

A conforming binding MUST support conveying ATD rollback requests
and results.  For HTTP-based bindings, the `/.well-known/atd/rollback`
endpoint MUST be accessible independent of the main protocol
endpoint.

## HITL Callback Registration

A conforming binding MUST support HITL approval callback
registration.  When a task involves a planned approval gate, the
initiating agent MUST be able to register a callback URI that
receives the `hitl:approval_granted` or `hitl:approval_denied`
ECT when the human responds.  For HTTP bindings, this is a
standard webhook registration.

## Summary Table

| Requirement | Minimum | Rationale |
|-------------|---------|-----------|
| ECT carriage | `Execution-Context` header or equivalent | DAG continuity |
| Parent ECT reference | In task invocation | DAG linkage |
| Rollback signal | `/.well-known/atd/rollback` accessible | Error recovery |
| HITL callback | Webhook or equivalent | Async approval |
| Transport security | TLS 1.3 | Integrity and confidentiality |
{: #fig-requirements title="Protocol Binding Conformance Requirements"}

# Translation Gateway Architecture {#translation}

## Gateway as DAG Node

Every translation hop produces an ECT:

- `exec_act`: `"aepb:translate"`
- `par`: the source agent's ECT

~~~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 in the ECT DAG:

~~~
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, maintaining DAG continuity.

## Multi-Hop Translation

When a single gateway cannot handle a translation pair, messages
may traverse multiple gateways.  Each hop produces an
`aepb:translate` ECT, all linked in the same DAG:

~~~
Agent-A ECT
    │
    ▼
Gateway-1 ECT (a2a-v1 → mcp-v1)
    │
    ▼
Gateway-2 ECT (mcp-v1 → slim-v1)
    │
    ▼
Agent-B ECT
~~~
{: #fig-multihop title="Multi-Hop Translation DAG"}

The maximum number of translation hops is configured as a
node constraint:

~~~json
{
  "constraints": {
    "aepb.max_translation_hops": 2
  }
}
~~~

Agents receiving a message MUST count `aepb:translate` ECTs in
the `par` ancestry and MUST reject messages exceeding
`aepb.max_translation_hops`.  The default maximum is 3.

## Gateway Requirements

A gateway MUST:

1. Serve a capability document at `/.well-known/aepb/gateway`
   listing supported translation pairs.
2. Accept messages via HTTP POST at its translate endpoint.
3. Produce an `aepb:translate` ECT per {{translation}} 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 per-source-agent rate limiting.
7. Verify gateway ECTs at L2 or higher (signed JWT minimum).

A gateway MUST NOT modify payload semantics beyond what is
required for protocol translation.

## Translation Failure Handling

When a gateway fails to translate a message, it MUST emit an
error ECT:

~~~json
{
  "exec_act": "aepb:translate_error",
  "par": ["source-agent-ect-uuid"],
  "ext": {
    "aepb.source_protocol": "a2a-v1",
    "aepb.dest_protocol": "slim-v1",
    "aepb.error": "semantic_loss",
    "aepb.description": "Source message contains field 'action.stream' with no slim-v1 equivalent"
  }
}
~~~
{: #fig-translate-error title="Translation Error ECT"}

Error values: `semantic_loss` (untranslatable field), `timeout`,
`policy_violation` (exceeds hop limit), `internal_error`.

On translation failure:
- The ATD circuit breaker for the gateway agent SHOULD be
  updated.
- If `atd.cascade: false`, the calling agent returns
  `no_translation_path` to its upstream caller.
- If `atd.cascade: true`, the ATD rollback protocol applies
  to the entire workflow subgraph.

## 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"}

# 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.  The agent MUST include a
  `Deprecation` header per {{RFC8594}} in all responses.
  Clients SHOULD migrate to `successor` if provided.

draining:
: Agent is rejecting new workflows but completing in-progress
  ones.  New delegation requests MUST return HTTP 503 with
  `Retry-After` header and, if set, `Location` pointing to
  `successor`.

retired:
: Agent is offline.  Capability document MUST return HTTP 410
  Gone with `Link: <successor>; rel="successor-version"`.

## Lifecycle State Transitions

~~~
         deprecate              drain
active ──────────► deprecated ────────► draining ──► retired
  ▲                    │                    │
  │                    │ immediate drain    │
  └────────────────────┴────────────────────┘
                   (operator discretion)
~~~
{: #fig-lifecycle-fsm title="Lifecycle State Machine"}

All transitions MUST be recorded as ECTs:

~~~json
{
  "exec_act": "aepb:lifecycle_change",
  "ext": {
    "aepb.agent_id": "spiffe://example.com/agent/pricing",
    "aepb.from_state": "active",
    "aepb.to_state": "deprecated",
    "aepb.reason": "Replaced by pricing-v3"
  }
}
~~~
{: #fig-lifecycle-ect title="Lifecycle Change ECT"}

## 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.  Clients MUST verify that the successor's assurance
level is equal to or greater than the predecessor's.

# Security Considerations

## Capability Document Integrity

Capability documents are served over HTTPS with TLS 1.3.
Agents SHOULD verify TLS certificates before trusting capability
documents.  For high-assurance deployments, capability documents
SHOULD be signed as JWTs ({{RFC7519}}) so their integrity can
be verified independently of transport security.

## Gateway Trust

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 (unknown `aepb.gateway_id`).
- Content tampering (`inp_hash`/`out_hash` mismatch).
- Routing loops (repeated gateway IDs in DAG ancestry).

Gateways MUST authenticate using WIMSE/SPIFFE identities at
ECT assurance L2+.

## Protocol Downgrade Attacks

An attacker may attempt to force negotiation to a weaker
protocol.  Mitigation:

- Agents MUST enforce `aepb.min_protocol_security` constraint.
- TLS 1.3 is the minimum transport; lower versions MUST be
  rejected.
- Protocol negotiation results MUST be logged as part of the
  workflow ECT DAG.

## Translation Amplification

A single cross-protocol request could trigger a chain of N
translations, each consuming resources.  Mitigation:

- `aepb.max_translation_hops` (default 3) prevents unbounded
  chains.
- Per-source rate limiting at each gateway prevents a single
  agent from flooding the translation infrastructure.

## Lifecycle Denial of Service

Transitioning an agent to `draining` or `retired` disrupts
its callers.  Only the agent operator (verified via ACP-DAG-HITL
identity binding) SHOULD be able to trigger lifecycle
transitions.  Lifecycle-change ECTs MUST be signed at L2+.

# IANA Considerations

## AEPB Protocol Binding Registry

This document requests the creation of the "AEPB Protocol Binding
Registry" under IANA.  Registration policy: Specification Required.

Required fields: Binding Identifier, Protocol Name, Specification
Reference, Minimum ECT Assurance Level, HITL Callback Support.

Initial entries:

| Identifier | Protocol | Spec Reference | Min Assurance | HITL Callback |
|------------|----------|---------------|--------------|---------------|
| `a2a-v1` | A2A | (TBD) | L1 | Webhook |
| `mcp-v1` | Model Context Protocol | (TBD) | L1 | Webhook |
| `slim-v1` | SLIM | (TBD) | L1 | Webhook |
| `uacp-v1` | uACP | (TBD) | L1 | Webhook |
| `ainp-v1` | AINP | (TBD) | L1 | Webhook |
{: #fig-registry title="Initial Protocol Binding Registry Entries"}

## Well-Known URIs

This document requests registration per {{RFC8615}}:

| URI Suffix | Purpose |
|------------|---------|
| `aepb` | Agent capability document |
| `aepb/gateway` | Translation gateway capability |
{: #fig-wellknown title="Well-Known URI Registrations"}

## `exec_act` Values

This document requests registration in the AEM Ecosystem
Extension Registry:

| Value | Description | Reference |
|-------|-------------|-----------|
| `aepb:translate` | Protocol translation hop | This document |
| `aepb:translate_error` | Translation failure | This document |
| `aepb:shutdown` | Agent graceful shutdown complete | This document |
| `aepb:lifecycle_change` | Lifecycle state transition | This document |
{: #fig-iana-actions title="AEPB exec_act Registrations"}

--- 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.
The lifecycle model is inspired by Kubernetes graceful shutdown
semantics and the `Deprecation` header {{RFC8594}}.