c/ietf-draft-analyzer

Fork 0

Files

Christian Nennemann 2506b6325a

CI / test (3.11) (push) Failing after 1m37s

Details

CI / test (3.12) (push) Failing after 57s

Details

feat: add draft data, gap analysis report, and workspace config

2026-04-06 18:47:15 +02:00

17 KiB

Raw Blame History

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 Document Format

Each AEPB-compliant agent MUST serve a capability document at /.well-known/aepb per {{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",
  "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

When Agent A wants to communicate with Agent B:

Agent A fetches B's capability document over HTTPS.
Agent A computes the intersection of protocol lists. If non-empty, the protocol with the lowest combined priority is selected. Communication proceeds directly.
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.

If a suitable gateway is found, Agent A sends its message to the gateway, which translates and forwards.
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:

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

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

Gateway as DAG Node

Every translation hop produces an ECT:

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

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

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

Serve a capability document at /.well-known/aepb/gateway listing supported translation pairs.
Accept messages via HTTP POST at its translate endpoint.
Produce an aepb:translate ECT per {{translation}} for every translation.
Preserve message semantics. Fields without a destination equivalent are carried in an extension field or dropped with a warning in aepb.translation_warnings.
Require TLS 1.3 {{RFC8446}} for all connections.
Implement per-source-agent rate limiting.
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:

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

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

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

Update capability document: status: "draining", set sunset_at timestamp.
Reject new workflow delegations with HTTP 503.
Complete all in-progress workflows.
Emit a final ECT: exec_act: "aepb:shutdown".
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}}.

17 KiB Raw Blame History