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

2026-04-06 18:47:15 +02:00
parent 4f310407b0
commit 2506b6325a
189 changed files with 62649 additions and 0 deletions
--- a/workspace/drafts/new-drafts/draft-d-aepb-protocol-binding-01.md
+++ b/workspace/drafts/new-drafts/draft-d-aepb-protocol-binding-01.md
@@ -0,0 +1,577 @@
+---
+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}}.