ietf-draft-analyzer/workspace/drafts/new-drafts/draft-d-aepb-protocol-binding-00.md

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

Each AEPB-compliant agent MUST serve a capability document at /.well-known/aepb {{RFC8615}}:

{
  "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

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

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

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

{
  "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

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 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.