# drafts

name: draft-vinaysingh-awp-wellknown
rev: 00
title: The Agent Workflow Protocol (AWP) Well-Known Resource and Link Relation
time: 2025-11-02T16:22:40Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T16:22:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Human-agent interaction", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:05.127500+00:00
abstract:
This document registers a Well-Known URI, /.well-known/awp.json, and
   a companion Link Relation Type, awp.  The resource exposes a small,
   machine-readable description of common website workflows (states,
   actions, and resulting events) so automated agents can act
   predictably without scraping.  The format is JSON and intentionally
   minimal.

full_text:
Network Working Group                                           V. Singh
Internet-Draft                                                  Ajna.inc
Intended status: Standards Track                                D. McKay
Expires: 5 May 2026                                             Verid.id
                                                         1 November 2025


The Agent Workflow Protocol (AWP) Well-Known Resource and Link Relation
                   draft-vinaysingh-awp-wellknown-00

Abstract

   This document registers a Well-Known URI, /.well-known/awp.json, and
   a companion Link Relation Type, awp.  The resource exposes a small,
   machine-readable description of common website workflows (states,
   actions, and resulting events) so automated agents can act
   predictably without scraping.  The format is JSON and intentionally
   minimal.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-vinaysingh-awp-wellknown/.


   Source for this draft and an issue tracker can be found at
   https://github.com/vinaysingh8866/awp-wellknown-draft.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 May 2026.





Singh & McKay              Expires 5 May 2026                   [Page 1]

Internet-Draft               AWP Well-Known                November 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The AWP Resource  . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Discovery via Link Relation . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Well-Known URI Registration . . . . . . . . . . . . . . .   5
     5.2.  Link Relation Type Registration . . . . . . . . . . . . .   5
   Appendix A.  References . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Automation on the Web often relies on brittle scraping.  Many sites
   already publish machine metadata (e.g., OpenAPI descriptions,
   sitemaps).  This document defines a single optional entry point — a
   Well-Known resource — that advertises a compact, typed map of site
   workflows.  Agents can use it to perform tasks deterministically
   (e.g., sign in, search, checkout).

   This document registers:

   *  the Well-Known URI: /.well-known/awp.json, and

   *  the Link Relation Type: awp.

   The resource is read-only and does not alter authorization; normal
   Web security controls continue to apply.

2.  The AWP Resource

   An origin *MAY* expose a JSON resource at:




Singh & McKay              Expires 5 May 2026                   [Page 2]

Internet-Draft               AWP Well-Known                November 2025


   GET /.well-known/awp.json Content-Type: application/awp+json

   The document contains:

   *  version — semantic version (required),

   *  initial — the starting state (required),

   *  states — a map of state → allowed action names (required),

   *  transitions — event-driven edges (from, event, to) (required),

   *  actions — named HTTP operations with form bindings (required),

   *  schemas — JSON Schema 2020-12 objects referenced by expects/
      produces (required),

   *  site — site metadata with name and baseUrl (required),

   *  template_id — unique identifier (optional),

   *  title — human-readable name (optional),

   *  description — template description (optional),

   *  openapi — link to OpenAPI spec (optional),

   *  policies — rate limiting and other policies (optional).

   A minimal example follows:





















Singh & McKay              Expires 5 May 2026                   [Page 3]

Internet-Draft               AWP Well-Known                November 2025


   {
     "version": "1.0.0",
     "initial": "Anon",
     "states": {
       "Anon":          { "available": ["login"] },
       "Authenticated": { "available": ["search","checkout"] }
     },
     "transitions": [
       { "from": "Anon", "event": "login_ok", "to": "Authenticated" }
     ],
     "actions": {
       "login": {
         "form": { "method": "POST", "target": "/api/login", "contentType": "application/json" },
         "expects":  { "$ref": "#/schemas/LoginInput" },
         "emits": { "onSuccess": "login_ok", "onError": "login_failed" }
       }
     },
     "schemas": {
       "LoginInput": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",
         "required": ["email","password"],
         "properties": {
           "email": { "type": "string", "format": "email" },
           "password": { "type": "string", "minLength": 8 }
         }
       }
     },
     "site": {
       "name": "Example Shop",
       "baseUrl": "https://shop.example.com"
     }
   }

   Servers *MAY* use RFC 6570 URI Templates in form.target (e.g., /api/
   search{?q,limit,offset}).  API errors *SHOULD* use RFC 9457 Problem
   Details to allow deterministic branching by clients.

3.  Discovery via Link Relation

   Origins *SHOULD* advertise the resource with:

   Link: </.well-known/awp.json>; rel="awp"

   The awp relation identifies the AWP manifest for the current origin.






Singh & McKay              Expires 5 May 2026                   [Page 4]

Internet-Draft               AWP Well-Known                November 2025


4.  Security Considerations

   *  The manifest is advisory; authentication and authorization remain
      unchanged.

   *  Do not place secrets or user-specific data in the manifest.

   *  Consider cache lifetimes so changes propagate appropriately.

   *  Implement normal rate-limiting/abuse controls on operational
      endpoints referenced by the manifest.

   *  Cross-origin access is governed by existing Web mechanisms (e.g.,
      CORS).

5.  IANA Considerations

5.1.  Well-Known URI Registration

   IANA is requested to register the following in the “Well-Known URIs”
   registry:

   *  *URI Suffix:* awp.json

   *  *Change Controller:* IETF

   *  *Specification Document:* This document, Section 2

   *  *Status:* permanent

   *  *Related Information:* JSON manifest describing site workflows for
      automated agents.

5.2.  Link Relation Type Registration

   IANA is requested to register the following in the “Link Relation
   Types” registry:

   *  *Relation Name:* awp

   *  *Description:* Identifies the Agent Workflow Protocol (AWP)
      manifest for this origin.

   *  *Reference:* This document, Section 3







Singh & McKay              Expires 5 May 2026                   [Page 5]

Internet-Draft               AWP Well-Known                November 2025


Appendix A.  References

   *  RFC 8615 — Well-Known URIs

   *  RFC 8288 — Web Linking

   *  RFC 6570 — URI Templates

   *  RFC 9457 — Problem Details for HTTP APIs

   *  JSON Schema 2020-12 — Core & Validation

Authors' Addresses

   Vinay Singh
   Ajna.inc
   Email: vinay@ajna.inc


   Dave McKay
   Verid.id
   Email: dave@verid.id





























Singh & McKay              Expires 5 May 2026                   [Page 6]


name: draft-yang-ioa-protocol
rev: 00
title: Internet of Agents Protocol (IoA Protocol) for Heterogeneous Agent Collaboration
time: 2025-07-20T18:52:34Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-21T18:52:34Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127507+00:00
abstract:
This draft defines a new agent collaboration protocol, named the
   Internet of Agents Protocol (IoA Protocol), to support distributed,
   heterogeneous agent collaboration in intelligent systems.  The IoA
   Protocol enables dynamic team formation, adaptive task coordination,
   and structured communication among agents with diverse architectures,
   tools, and knowledge sources.  Through a layered architecture and
   extensible message format, it supports decentralized deployment
   across devices and can interoperate with existing frameworks.  The
   protocol is particularly suited to emerging 6G application scenarios
   such as intelligent transportation, smart healthcare, and large-scale
   human–AI teaming.

full_text:
Dispatch Working Group                                           C. Yang
Internet-Draft        Beijing University of Posts and Telecommunications
Intended status: Standards Track                                  Z. Liu
Expires: 21 January 2026                             Tsinghua University
                                                                 A. Wang
                                                           China Telecom
                                                            20 July 2025


   Internet of Agents Protocol (IoA Protocol) for Heterogeneous Agent
                             Collaboration
                       draft-yang-ioa-protocol-00

Abstract

   This draft defines a new agent collaboration protocol, named the
   Internet of Agents Protocol (IoA Protocol), to support distributed,
   heterogeneous agent collaboration in intelligent systems.  The IoA
   Protocol enables dynamic team formation, adaptive task coordination,
   and structured communication among agents with diverse architectures,
   tools, and knowledge sources.  Through a layered architecture and
   extensible message format, it supports decentralized deployment
   across devices and can interoperate with existing frameworks.  The
   protocol is particularly suited to emerging 6G application scenarios
   such as intelligent transportation, smart healthcare, and large-scale
   human–AI teaming.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 21 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Yang, et al.             Expires 21 January 2026                [Page 1]

Internet-Draft                IoA Protocol                     July 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IOA Methods . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  IOA Architecture  . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Heterogeneous Agent Integration . . . . . . . . . . . . .   6
     4.3.  Autonomous Team Formation . . . . . . . . . . . . . . . .   7
     4.4.  Session and Task Management Method  . . . . . . . . . . .   7
     4.5.  Message Protocol Overview . . . . . . . . . . . . . . . .   7
   5.  Relation to the A2A Protocol  . . . . . . . . . . . . . . . .   8
   6.  Future Enhancements for 6G-Enabled IoA Protocol . . . . . . .   9
     6.1.  Distributed Agent Registration and Discovery  . . . . . .  10
     6.2.  Positioning of the Protocol in the Network Layering
           System  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.3.  Enhanced Scalability and Fault Tolerance  . . . . . . . .  11
     6.4.  Semantic Interoperability and Ontology Alignment  . . . .  11
     6.5.  Security and Privacy Enhancements . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  12
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   With the rapid advancement of large language models (LLMs) and
   multimodal autonomous agents, modern intelligent systems are
   increasingly constructed as collaborative networks of multiple
   agents.  These agents are expected to work together to solve complex,
   open-ended tasks.  However, they often differ in capabilities, tools,
   runtime environments, and communication patterns, leading to
   significant challenges in interoperability, dynamic coordination, and
   cross-device deployment.  As a result, current multi-agent frameworks
   fall short of the flexibility and generality required in real-world
   applications.





Yang, et al.             Expires 21 January 2026                [Page 2]

Internet-Draft                IoA Protocol                     July 2025


   In a typical collaborative setting shown in Figure 1, agents with
   specialized functions—including a Google Scholar Agent for academic
   search, an AI Research Specialist for conceptual planning, a PDF
   Agent for document analysis, and an Academic Writing Agent for
   content generation—must work together to complete a research paper on
   “Internet of Agents.” These agents are distributed across devices
   (e.g., laptops, edge nodes, cloud services), and each relies on
   different execution frameworks or data formats.

+---------------------------------------------------------------------------------------+
|                                                                                       |
|                 Task: Write a research paper on "Internet of Agents"                  |
|                                                                                       |
|        +----------------+        +----------------+        +----------------+         |
|        | AI Research    |<------>| Google Scholar |<------>| Academic       |         |
|        | Specialist     |        | Agent          |        | Writing Agent  |         |
|        | (Device A)     |        | (Device B)     |        | (Device C)     |         |
|        +----------------+        +----------------+        +----------------+         |
|                    \                     |                       /                    |
|                     \                    |                      /                     |
|                      \                   |                     /                      |
|                       \                  |                    /                       |
|                        \                 |                   /                        |
|                         \                |                  /                         |
|                          +---------------+-----------------+                          |
|                                          |                                            |
|                                 +----------------+                                    |
|                                 | PDF Agent      |                                    |
|                                 | (Device D)     |                                    |
|                                 +----------------+                                    |
|                                          |                                            |
|                             +------------+-------------+                              |
|                             |                          |                              |
|                             |       IoA Server         |                              |
|                             |                          |                              |
|                             +--------------------------+                              |
|                                                                                       |
+---------------------------------------------------------------------------------------+

                      Figure 1: Multi-agent collaboration scenario

   When the Google Scholar Agent encounters a specialized PDF parsing
   task beyond its capability, existing frameworks often fail to
   dynamically recruit the PDF Agent due to rigid team formation rules.
   Likewise, when the AI Research Specialist and Writing Agent attempt
   to synchronize intermediate results in real time, inflexible
   communication channels may result in delays or dropped information.




Yang, et al.             Expires 21 January 2026                [Page 3]

Internet-Draft                IoA Protocol                     July 2025


   Existing solutions exhibit several key limitations:

   *  Closed frameworks that restrict integration with third-party
      agents such as AutoGPT or Open Interpreter;

   *  Single-device simulation that fails to reflect cross-device
      deployment scenarios typical in edge-cloud collaboration;

   *  Hard-coded workflows that prevent agents from switching between
      synchronous and asynchronous task execution at runtime.

   To address these challenges, this draft introduces the Internet of
   Agents (IoA) Protocol—a layered, extensible collaboration standard
   designed for intelligent multi-agent systems.  The core goal of the
   protocol is to enable seamless collaboration among heterogeneous
   agents across devices, tools, and execution environments.  It
   supports:

   *  Agent integration via a standardized interface and registration
      mechanism;

   *  Dynamic team formation across distributed environments;

   *  Finite-state machine-based session control for flexible and
      autonomous dialogue management;

   *  Structured message formats with group routing, task assignment,
      and response coordination.

   The design of the IoA Protocol aligns naturally with the vision of 6G
   networks, which aim to support ubiquitous intelligence through large-
   scale, low-latency, and semantic-driven communication.  By enabling
   agent collaboration across edge devices, mobile terminals, and cloud
   nodes, IoA complements 6G’s emphasis on edge-cloud-device
   coordination and distributed AI.  Its structured message design,
   dynamic team formation, and abstracted dialogue control offer the
   necessary protocol foundation to orchestrate intelligent services
   over future 6G infrastructures.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .







Yang, et al.             Expires 21 January 2026                [Page 4]

Internet-Draft                IoA Protocol                     July 2025


3.  Terminology

   The following terms are defined in this draft:

   *  IoA: Internet of Agents, a protocol enabling distributed
      collaboration among heterogeneous agents across devices and 6G
      networks, defined in Section 4

   *  Agent Registry Block: A server-side module storing structured
      capability descriptions of all registered agents, supporting
      semantic search for team formation, defined in Section 4

   *  Team Formation Block: A client-side module responsible for
      initiating, joining, or disbanding agent teams based on task
      requirements, including nested sub-teams, defined in Section 4

   *  Session State Machine: A finite-state model governing
      collaboration states (Discussion, Synchronous Task Assignment,
      Asynchronous Task Assignment, Pause and Trigger, Conclusion) for
      adaptive dialogue management, defined in Section 4

   *  HTTP: Hypertext Transfer Protocol, a application-layer protocol
      for distributed, collaborative, hypermedia information systems,
      referenced in IoA for interoperability with web-based agents,
      defined in [RFC9110]

   *  JSON-RPC: A remote procedure call protocol encoded in JSON,
      referenced in IoA for structured communication between web-based
      agents, defined in [RFC8259]

   *  QUIC: A transport layer protocol providing secure, low-latency
      communication over UDP, used in IoA for real-time agent messaging,
      defined in [RFC9000]

4.  IOA Methods

4.1.  IOA Architecture

   The Internet of Agents Protocol (IoA Protocol) enables distributed
   collaboration among heterogeneous agents through a layered
   architecture and distributed communication protocol.  It supports
   seamless integration across devices, toolchains, and runtime
   environments.

   The IoA system adopts a three-layer architecture implemented
   symmetrically at both the server and client side:





Yang, et al.             Expires 21 January 2026                [Page 5]

Internet-Draft                IoA Protocol                     July 2025


   *  Server-side: Handles global coordination, agent discovery, group
      management, and message routing.

   *  Client-side: Encapsulates individual agents and provides
      interfaces for team collaboration and local task execution.

   An overview of the layered structure is shown in Figure 2.

+----------------------------------------------------------------------------+ +----------------------------------------------------------------------------+
|                                   Server                                   | |                                   Client                                   |
|----------------------------------------------------------------------------| |----------------------------------------------------------------------------|
| Interaction Layer:                                                         | | Interaction Layer:                                                         |
|   - Agent Query Block: Handles semantic agent search queries               | |   - Team Formation Block: Forms/join teams for assigned goals              |
|   - Group Setup Block: Manages group/team creation                         | |   - Communication Block: Handles chat messaging and event updates          |
|   - Message Routing Block: Routes messages within chat groups              | |----------------------------------------------------------------------------|
|----------------------------------------------------------------------------| | Data Layer:                                                                |
| Data Layer:                                                                | |   - Agent Contact Block: Caches past collaborators                         |
|   - Agent Registry Block: Stores capability descriptions of all agents     | |   - Group Info Block: Stores task metadata and group state                 |
|   - Session Management Block: Tracks WebSocket sessions and group states   | |   - Task Management Block: Tracks subtasks, assignment, and progress       |
|----------------------------------------------------------------------------| |----------------------------------------------------------------------------|
| Foundation Layer:                                                          | | Foundation Layer:                                                          |
|   - Data Infra Block: Vector database (e.g., Milvus) for semantic search   | |   - Agent Integration Block: Adapter for third-party agents                |
|   - Network Infra Block: WebSocket infrastructure                          | |   - Data Infra Block: Local DB (e.g., SQLite)                              |
|   - Security Block: Authentication and permission control                  | |   - Network Infra Block: WebSocket-based communication                     |
+----------------------------------------------------------------------------+ +----------------------------------------------------------------------------+

                  Figure 2: Layered architecture of IoA system

4.2.  Heterogeneous Agent Integration

   IoA supports the integration of heterogeneous agents from diverse
   sources through a unified interface, including third-party agents
   such as AutoGPT, Open Interpreter, and embodied robotic agents.

   When a new agent joins the IoA, its client wrapper undergoes a
   registration process with the server.  During this registration, the
   agent is expected to provide a comprehensive description of its
   capabilities, skills, and domains of expertise.  For an agent c_i,
   its description is denoted as d_i, and is stored in the Agent
   Registry Block within the Data Layer of the server.

   The set of all registered agents is denoted as C = {c₁, c₂, ..., cₙ},
   where each c_i is associated with its capability description d_i.
   This mechanism enables future semantic matching and intelligent task
   allocation.






Yang, et al.             Expires 21 January 2026                [Page 6]

Internet-Draft                IoA Protocol                     July 2025


4.3.  Autonomous Team Formation

   Agents initiate the search process by submitting capability
   requirements to the Agent Query Block.  The server performs semantic
   matching using vector similarity and returns candidate agents from
   the Agent Registry Block.

   IoA supports nested team structures.  An initial group is formed for
   the main goal, and subgroups are recursively created if subtasks
   require new capabilities.  This forms a hierarchical tree structure,
   reducing communication complexity and organizational overhead.

   The entire team formation process is autonomous, task-driven, device-
   agnostic, and self-organizing.

4.4.  Session and Task Management Method

   IoA models group conversations and collaboration using a finite-state
   machine with five abstract states:

   *  Discussion: Agents engage in general dialogue, exchange ideas, and
      clarify task require ments;

   *  Synchronous task assignment: Tasks are assigned to specific
      agents, pausing the group chat until completion;

   *  Asynchronous task assignment: Tasks are assigned without
      interrupting the ongoing discus sion;

   *  Pause & trigger: The group chat is paused, waiting for the
      completion of specified asyn chronous tasks;

   *  Conclusion: Marks the end of the collaboration, prompting a final
      summary.

   State transitions are managed autonomously by a coordinator agent
   using the conversation history and session context to determine the
   next state and speaker.

4.5.  Message Protocol Overview

   The agent message protocol in IoA is designed for extensibility and
   flexibility, enabling effective collaboration among heterogeneous
   agents.  Each message consists of two main parts: a header and a
   payload.

   The header contains essential metadata to ensure proper routing and
   processing.  Key fields include:



Yang, et al.             Expires 21 January 2026                [Page 7]

Internet-Draft                IoA Protocol                     July 2025


   *  sender: The unique identifier of the agent sending the message.

   *  group_id: The identifier of the group chat to which the message
      belongs.

   The payload carries the main content of the message and varies
   depending on message type.  Common fields include:

   *  message_type: Indicates the purpose of the message (e.g.,
      discussion, task assignment, pause and trigger).

   *  next_speaker: The identifier(s) of the agent(s) expected to
      respond.

   The full structure of the message format is illustrated in Figure 3.

      +--------------------------+   +-----------------------------+
      |         Header           |   |  Autonomous Team Formation  |
      +--------------------------+   +-----------------------------+
      | sender: str              |   | goal: str                   |
      | state: enum              |   | team_members: list[str]     |
      | comm_id: str             |   | team_up_depth: int          |
      +--------------------------+   | max_turns: int              |
      +--------------------------+   +-----------------------------+
      |       Discussion         |   |      Task Assignment        |
      +--------------------------+   +-----------------------------+
      | content: str             |   | task_id: str                |
      | type: enum               |   | task_desc: str              |
      | next_speaker: list[str]  |   | task_conclusion: str        |
      +--------------------------+   | task_abstract: str          |
      +--------------------------+   +-----------------------------+
      |    Pause & Trigger       |
      +--------------------------+
      | triggers: list[str]      |
      +--------------------------+

             Figure 3: Structure of IoA Message Protocol

5.  Relation to the A2A Protocol

   The Agent-to-Agent (A2A) protocol is a communication standard
   designed to support standardized, secure, and modality-agnostic
   interaction between AI agents.  Built upon existing web technologies
   such as HTTP, Server-Sent Events (SSE), and JSON-RPC, A2A emphasizes
   default security, support for long-running tasks, and cross-modality
   interoperability.  It introduces the concept of an AgentCard to
   describe agent capabilities, enabling effective discovery and
   invocation.



Yang, et al.             Expires 21 January 2026                [Page 8]

Internet-Draft                IoA Protocol                     July 2025


   The Internet of Agents (IoA) protocol shares the same fundamental
   goal with A2A: to break down communication barriers among agents and
   improve the overall efficiency of multi-agent systems.  Both
   protocols rely on network communication technologies and adopt
   similar approaches to message encoding, decoding, and task
   coordination.

   However, the two protocols diverge significantly in terms of design
   philosophy and core mechanisms:

   *  A2A focuses on enabling standardized communication through web-
      native technologies, effectively creating a "free trade zone" for
      agents where interoperability is built-in.  In contrast, the IoA
      protocol draws inspiration from Internet architecture and targets
      the problem of ecosystem fragmentation.  It establishes a system-
      level collaboration platform where heterogeneous agents can freely
      register, discover one another, and collaborate across platforms
      and devices.

   *  A2A is based on HTTP and JSON-RPC for communication, combined with
      task lifecycle management and capability discovery through
      AgentCard.  IoA, on the other hand, offers a more comprehensive
      collaboration framework, including agent registration, autonomous
      nested team formation, finite-state-machine-driven session
      control, and trigger-based task coordination.

   *  While A2A is suitable for standardized task responses and
      streaming updates, it lacks native support for dynamic session
      management and nested subtask structures.  IoA enables adaptive
      interaction flow via a session state machine, and its
      team_up_depth field supports recursive team formation and state
      transitions—making it more effective for handling complex and
      evolving task scenarios.

   In summary, A2A is well-suited for lightweight, standardized task
   interfaces, whereas IoA provides a more flexible and system-oriented
   protocol for large-scale, heterogeneous, and dynamic multi-agent
   collaboration.  The two protocols can complement each other at
   different layers, jointly advancing the development of agent
   communication technologies.

6.  Future Enhancements for 6G-Enabled IoA Protocol

   To fully realize the potential of 6G-enabled intelligent systems, the
   Internet of Agents (IoA) protocol requires continuous architectural
   evolution and standardization.  This section outlines key directions
   for future enhancements to improve scalability, decentralization,
   interoperability, and network integration.



Yang, et al.             Expires 21 January 2026                [Page 9]

Internet-Draft                IoA Protocol                     July 2025


6.1.  Distributed Agent Registration and Discovery

   The current IoA design relies on a centralized server model, which
   may limit scalability and introduce single points of failure under
   large-scale deployment.  A promising direction is to adopt a
   decentralized registration and discovery mechanism, where agents can
   publish their capabilities to a shared registry accessible via a 6G-
   compatible web-based interface.  Inspired by Domain Name System (DNS)
   and search engines, agents could be discoverable through keyword-
   based or semantic search at scale, enabling lightweight browser-based
   or API-based discovery across domains.

   This decentralized lookup layer would allow IoA to support scenarios
   where agents operate across multiple domains, owners, and physical
   networks, while still maintaining secure and authenticated
   interaction through digital signatures and trust mechanisms.

6.2.  Positioning of the Protocol in the Network Layering System

   To achieve efficient integration of the IOA protocol with the 6G
   network protocol stack, the current design primarily positions IOA at
   the application layer, built on top of transport and session
   protocols such as TCP, UDP, WebSocket, and QUIC.  From the
   perspective of functional mapping, the corresponding relationship
   between IOA's three-layer architecture and the computer network
   layers is as follows:

   *  Interaction Layer → Maps to the application layer, responsible for
      high-level logic such as message protocols, group collaboration,
      and session state transitions.

   *  Data Layer → Spans the application layer and session layer,
      managing agent states, group metadata, and context tracking.

   *  Foundation Layer → Corresponds to the transport layer and system
      infrastructure, including secure communication channels (e.g.,
      WebSocket/QUIC), databases, and network service modules.

   Since the IOA protocol involves intelligent behaviors such as agent
   orchestration, semantic-driven interaction, and session control, an
   intelligence layer can be introduced above the traditional
   application layer.  This layer encapsulates core intelligent
   collaboration logic—such as semantic-based agent matching, AI-driven
   session strategy optimization, dynamic task decomposition, and 6G-
   aware team reorganization—into standardized message formats.  This
   layer shields upper-layer applications and lower-layer protocols from
   the complexity of intelligent decision-making, enabling them to focus
   on their core functions without concerning themselves with the



Yang, et al.             Expires 21 January 2026               [Page 10]

Internet-Draft                IoA Protocol                     July 2025


   details of how intelligence is implemented (e.g., scenario-specific
   task execution at the application layer, reliable data transmission
   at the transport layer).  Its advantages are reflected in:
   standardizing the collaboration of heterogeneous agents, reducing
   integration costs across 6G scenarios; improving communication
   efficiency through semantic compression and 6G feature adaptation;
   and easily expanding to support new intelligent behaviors and 6G
   application scenarios through modular updates of the intelligence
   layer.

6.3.  Enhanced Scalability and Fault Tolerance

   To scale beyond millions of agents, the IoA protocol should adopt
   sharding and region-based message routing.  Distributed registries
   and dynamic load balancing can reduce latency and avoid bottlenecks.
   Caching of frequent agent metadata at edge nodes is also critical for
   fast retrieval in latency-sensitive 6G use cases.

6.4.  Semantic Interoperability and Ontology Alignment

   In highly heterogeneous environments, agents may describe their
   capabilities using different terminologies.  To address this, the IoA
   protocol should support ontology mapping and alignment mechanisms.
   This allows agents with differing skill descriptors to still
   interoperate, using shared or translated task definitions during team
   formation and dialogue.

6.5.  Security and Privacy Enhancements

   For mission-critical 6G scenarios (e.g., autonomous vehicles, medical
   AI), the protocol must incorporate stronger security primitives.
   This includes:

   *  End-to-end encryption with forward secrecy.

   *  Support for zero-trust architectures with agent attestation and
      secure enclaves.

   *  Fine-grained access control based on agent role and session
      context.











Yang, et al.             Expires 21 January 2026               [Page 11]

Internet-Draft                IoA Protocol                     July 2025


7.  Security Considerations

   IOA servers and agents store sensitive data including capability
   descriptors, session state metadata, and task execution logs, which
   consume memory and computational resources.  To mitigate risks of
   resource exhaustion and unauthorized access, [RFC6749] (OAuth 2.0)
   mandates that IOA entities must authenticate peers via token-based
   validation before processing registration requests or collaboration
   messages.  Additionally, all data transmission between entities must
   use TLS 1.3 as specified in [RFC8446] to ensure confidentiality and
   integrity, preventing eavesdropping or tampering.

8.  IANA Considerations

   [TBD] This document defines a new protocol for heterogeneous agent
   collaboration: the Internet of Agents (IoA) Protocol.  The protocol's
   code point allocation will be determined in subsequent revisions as
   the standard matures, in accordance with IANA's relevant registration
   procedures.

9.  Acknowledgement

   Thanks Weize Chen, Ziming You, Ran Li, Yitong Guan, Chen Qian,
   Chenyang Zhao, Ruobing Xie, Maosong Sun and Yu Hao for their valuable
   comments on this draft.

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.





Yang, et al.             Expires 21 January 2026               [Page 12]

Internet-Draft                IoA Protocol                     July 2025


   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

Authors' Addresses

   Cheng Yang
   Beijing University of Posts and Telecommunications
   10 Xitucheng Road, Haidian District
   Beijing
   Beijing, 100876
   China
   Email: yangcheng@bupt.edu.cn


   Zhiyuan Liu
   Tsinghua University
   30 Shuangqing Road, Haidian District
   Beijing
   Beijing, 100084
   China
   Email: liuzy@tsinghua.edu.cn


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: wangaj3@chinatelecom.cn










Yang, et al.             Expires 21 January 2026               [Page 13]


name: draft-blahaj-grow-rpki-oauth
rev: 00
time: 2026-01-02T07:09:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-01T13:36:57Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:05.127511+00:00
title:
Attesting the Identities of Parties in OpenID Connect (OIDC) using the Resource Public Key Infrastructure (RPKI)

abstract:
The Peering API currently under discussion in the GROW Working Group
   does not provide a standardised mechanism to authenticate parties
   engaged in the Peering API.  This document specifies a method to
   attest as to the identities of parties in an OpenID Connect (OIDC)
   exchange, binding the authentication flow to agents of ASNs.

Discussion

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.molgen.mpg.de/q/rpki-peering-api-discovery.

full_text:
grow                                                           Q. Misell
Internet-Draft                                                  AS207960
Intended status: Standards Track                            30 June 2025
Expires: 1 January 2026


 Attesting the Identities of Parties in OpenID Connect (OIDC) using the
               Resource Public Key Infrastructure (RPKI)
                    draft-blahaj-grow-rpki-oauth-00

Abstract

   The Peering API currently under discussion in the GROW Working Group
   does not provide a standardised mechanism to authenticate parties
   engaged in the Peering API.  This document specifies a method to
   attest as to the identities of parties in an OpenID Connect (OIDC)
   exchange, binding the authentication flow to agents of ASNs.

Discussion

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.molgen.mpg.de/q/rpki-peering-api-discovery.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 1 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Misell                   Expires 1 January 2026                 [Page 1]

Internet-Draft             RPKI Attested OIDC                  June 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Endpoint Discovery  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Extensions to IdP Metadata  . . . . . . . . . . . . . . . . .   4
   6.  Extensions to Dynamic Client Registration . . . . . . . . . .   4
   7.  RPKI Attested JWK Set . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  RPKI Signed Message well-known purposes . . . . . . . . .   5
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   An API allowing programmatic configuration of BGP peering sessions is
   defined in [I-D.ramseyer-grow-peering-api].  The API defined in that
   document does not provide a standardised mechanism to authenticate
   parties engaged in the Peering API.  To this end, this documents
   defines extensions to OpenID Connect to allow verifying an AS's
   Identity Provider (IdP), its Relying Parties (RP), and agents
   thereof.

1.1.  Requirements Language

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
   document are to be interpreted as described in [BCP14] when, and only
   when, they appear in all capitals, as shown here.









Misell                   Expires 1 January 2026                 [Page 2]

Internet-Draft             RPKI Attested OIDC                  June 2025


2.  Problem statement

   The Peering API currently under discussion at the Global Routing
   Operations Working Group [I-D.ramseyer-grow-peering-api]is in need of
   a way to authenticate parties involved in such API exchanges.  The
   draft, as it is currently conceived, relies on the OAuth service
   provided by PeeringDB to authenticate Autonomous Systems and their
   agents.  It is undesirable, in the scope of an IETF document to rely
   on such external parties as a core part of the specification.  We
   therefore set out to define an alternative OAuth federation mechanism
   based on the RPKI[RFC6480], one that is not tied to one entity, and
   is usable by anyone within the Internet ecosystem.

   The reasons for adapting OAuth and not defining a new authentication
   mechanism are twofold; firstly, OAuth is a familiar protocol for
   authentication in application development, and many libraries exist
   that support it, secondly, and perhaps more crucially, is the large
   extant deployment of corporate IdPs using OAuth.  From discussions
   from the proponents of the Peering API, the need to identify not only
   the Autonomous System from which the request originates, but in
   addition _which agent_ of the AS has made the request.  That is, it
   would be beneficial be able to say not only that AS64496 submitted a
   peering request, but that John of AS64496 did so.

   Given the prevalence of corporate IdPs, specifically those that
   support OAuth, it seems fitting to extend this to also provide
   authentication to a peering API.  OAuth already provides the dynamic
   client registration, and token introspection, required to integrate a
   third party service with a corporate IdP.  This document serves to
   build upon this by creating a tie between resources attested in the
   RPKI and their IdPs and RPs.

   In addition to the peering API, there likely will be other APIs one
   may wish to establish between ASNs, and this OAuth extensions
   provides a natual basis for them.

3.  Terminology

   For brevity, within this document the following terminology is used

   Service Provider  An AS offering a (e.g. REST API) service to other
      ASes.

   Consumer  An AS consuming the service provided by the Service
      Provider.






Misell                   Expires 1 January 2026                 [Page 3]

Internet-Draft             RPKI Attested OIDC                  June 2025


4.  Endpoint Discovery

   All endpoints required for this protocol to function not defined
   herein, are to be discovered via OpenID Connect Discovery
   [OpenID.Discovery]

5.  Extensions to IdP Metadata

   An RP must be able to verify that an IdP is allowed to issue
   authorization tokens for resources.  To this end, the JWK Key Set
   presented in the OpenID Connect Discovery jwks_url MUST be an RPKI
   Attested JWK Set. That is, the JWK used to sign the JWTs used in an
   OAuth exchange is itself signed using the RPKI, attesting that this
   IdP is authoritative for Internet resources.  An IdP is considered
   authoritative for all resources in the EE Certificate contained in
   the RSM used to attest the JWK Key Set.

   An RP SHOULD regularly check for updates to the JWK Key Set, and its
   associated attestation, and MUST not cache the attestation and its
   attested resources beyond the end of the validity of the RSM.

6.  Extensions to Dynamic Client Registration

   Once the RP of a Service Provider is aware which IdP will be used by
   the Consumer to authenticate to it, it must register with that IdP,
   if it hasn't done so already.  This allows it to be issued an
   authentication token scoped to it, and to engage in Token
   Introspection [OpenID.Core] to verify tokens given in API requests.

   The manner in which the base URL of an IdP is communicated to an RP
   is out of the scope of this document, and is intended to be defined
   in subservient documents.

   The RP submits an OIDC Dynamic Client Registration request to the
   Consumer's IdP [OpenID.Registration], containing any well-known
   scopes as defined in subservient specifications required for which
   services the RP provides.  Updates to these scopes in future may be
   made via the Client Configuration Endpoint.

   Such that the Idp can validate the identity of the RP making the
   registration request, the request MUST be signed using HTTP
   signatures[RFC9421].  The signature keyid parameter MUST be URL to an
   RPKI Attested JWK Set.  The fragment of such a URL is used to
   identify the exact kid used to sign the request.

   This signature MUST be over at least the following components:

   *  @method



Misell                   Expires 1 January 2026                 [Page 4]

Internet-Draft             RPKI Attested OIDC                  June 2025


   *  @target-uri

   *  content-digest

   The body of the HTTP request MUST be included in the signature by the
   use of a HTTP Digest [RFC9530].

   This signature MUST contain at least the following parameters:

   *  @created

   *  @nonce

   *  @keyid

   The response to such a registration request need not be signed, as
   the identity of the IdP is validated via its TLS domain identity and
   its attested discovery metadata.

7.  RPKI Attested JWK Set

   An RPKI Attested JWK Set is as a normal JWK Set[RFC7517], that MUST
   contain an rpki_attestation parameter.  The construction of such a
   parameter is the base64url encoding [RFC7515] of an RPKI Signed
   Message over the JWK Set without the rpki_attestation parameter,
   using the JWK Thumbprint JSON hash input calculation
   algorithm[RFC7638].

   The audience field for such an RSM MUST be the Global Audience
   (1.3.6.1.5.5.TBD.0.0).

   The purpose field for such an RSM MUST be the OAuth Attestation
   Audience (1.3.6.1.5.5.TBD.1.1).

8.  Security Considerations

   The security considerations of this protocol have been left until the
   protocol proper is further refined.

9.  IANA Considerations

9.1.  RPKI Signed Message well-known purposes

   The IANA is requested to allocate a new OID under the "RPKI Signed
   Message well-known purposes" registry:






Misell                   Expires 1 January 2026                 [Page 5]

Internet-Draft             RPKI Attested OIDC                  June 2025


              +=========+===================+===============+
              | Decimal | Description       | References    |
              +=========+===================+===============+
              | 1       | OAuth Attestation | This document |
              +---------+-------------------+---------------+

                                  Table 1

10.  References

10.1.  Normative References

   [BCP14]    Best Current Practice 14,
              <https://www.rfc-editor.org/info/bcp14>.
              At the time of writing, this BCP comprises the following:

              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
              Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
              2015, <https://www.rfc-editor.org/info/rfc7638>.

   [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
              Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
              February 2024, <https://www.rfc-editor.org/info/rfc9421>.

   [RFC9530]  Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
              DOI 10.17487/RFC9530, February 2024,
              <https://www.rfc-editor.org/info/rfc9530>.



Misell                   Expires 1 January 2026                 [Page 6]

Internet-Draft             RPKI Attested OIDC                  June 2025


   [I-D.ramseyer-grow-peering-api]
              Aguado, C., Griswold, M., Ramseyer, J., Servin, A., and T.
              Strickx, "Peering API", Work in Progress, Internet-Draft,
              draft-ramseyer-grow-peering-api-05, 30 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ramseyer-
              grow-peering-api-05>.

   [OpenID.Core]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 2", The OpenID Foundation, 15 December 2023,
              <https://openid.net/specs/openid-connect-core-1_0.html>.

   [OpenID.Discovery]
              Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
              Connect Discovery 1.0 incorporating errata set 2", The
              OpenID Foundation, 15 December 2023,
              <https://openid.net/specs/openid-connect-discovery-
              1_0.html>.

   [OpenID.Registration]
              Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
              Dynamic Client Registration 1.0 incorporating errata set
              2", The OpenID Foundation, 15 December 2023,
              <https://openid.net/specs/openid-connect-registration-
              1_0.html>.

Author's Address

   Q Misell
   AS207960 Cyfyngedig
   13 Pen-y-lan Terrace
   Caerdydd
   CF23 9EU
   United Kingdom
   Email: q@as207960.net, q@magicalcodewit.ch
   URI:   https://magicalcodewit.ch














Misell                   Expires 1 January 2026                 [Page 7]


name: draft-cui-nmrg-llm-benchmark
rev: 01
title: A Framework to Evaluate LLM Agents for Network Configuration
time: 2025-12-30T09:04:54Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-03T09:04:54Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127514+00:00
abstract:
This document specifies an evaluation framework and related
   definitions for intent-driven network configuration using Large
   Language Model(LLM)-based agents.  The framework combines an
   emulator-based interactive environment, a suite of representative
   tasks, and multi-dimensional metrics to assess reasoning quality,
   command accuracy, and functional correctness.  The framework aims to
   enable reproducible, comprehensive, and fair comparisons among LLM-
   driven network configuration approaches.

full_text:
Network Management Research Group                                 Y. Cui
Internet-Draft                                                    C. Liu
Intended status: Informational                                    X. Xie
Expires: 3 July 2026                                 Tsinghua University
                                                                   C. Du
                                                 Zhongguancun Laboratory
                                                        30 December 2025


      A Framework to Evaluate LLM Agents for Network Configuration
                    draft-cui-nmrg-llm-benchmark-01

Abstract

   This document specifies an evaluation framework and related
   definitions for intent-driven network configuration using Large
   Language Model(LLM)-based agents.  The framework combines an
   emulator-based interactive environment, a suite of representative
   tasks, and multi-dimensional metrics to assess reasoning quality,
   command accuracy, and functional correctness.  The framework aims to
   enable reproducible, comprehensive, and fair comparisons among LLM-
   driven network configuration approaches.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://datatracker.ietf.org/doc/draft-cui-nmrg-llm-benchmark/.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-cui-nmrg-llm-benchmark/.

   Discussion of this document takes place on the Network Management
   Research Group mailing list (mailto:nmrg@irtf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/nmrg.  Subscribe at
   https://www.ietf.org/mailman/listinfo/nmrg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/nobrowning/draft_llm_conf_benchmark.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.







Cui, et al.                Expires 3 July 2026                  [Page 1]

Internet-Draft                NetConfBench                 December 2025


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 3 July 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Framework Overview  . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Components  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Data Model  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Task Definition Schema  . . . . . . . . . . . . . . . . .  11
     4.2.  Agent-Network Interface (ANI) . . . . . . . . . . . . . .  13
     4.3.  Task Evaluation Interface . . . . . . . . . . . . . . . .  15
   5.  MCP-Based Implementation  . . . . . . . . . . . . . . . . . .  16
     5.1.  Benefits of MCP Integration . . . . . . . . . . . . . . .  16
     5.2.  MCP Tool Definitions for ANI Operations . . . . . . . . .  17
       5.2.1.  1. get_topology . . . . . . . . . . . . . . . . . . .  17
       5.2.2.  2. get_running_config . . . . . . . . . . . . . . . .  18
       5.2.3.  3. update_config  . . . . . . . . . . . . . . . . . .  19
     5.3.  Additional MCP Tools for Advanced Scenarios . . . . . . .  22
       5.3.1.  batch_configure_devices . . . . . . . . . . . . . . .  22
       5.3.2.  check_device_status . . . . . . . . . . . . . . . . .  22
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  24



Cui, et al.                Expires 3 July 2026                  [Page 2]

Internet-Draft                NetConfBench                 December 2025


   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   Network configuration is fundamental to ensuring network stability,
   scalability, and conformance with intended design behavior.
   Effective configuration requires not only a comprehensive
   understanding of network technologies but also advanced capabilities
   for interpreting complex topologies, analyzing dependencies, and
   specifying parameters accurately.  Traditional automation approaches
   such as Ansible playbooks[A2023], NETCONF[RFC6241]/YANG
   models[RFC7950], or program-synthesis methods-either demand extensive
   manual scripting or are limited to narrow problem
   domains[Kreutz2014].  In parallel, Large Language Models (LLMs) have
   demonstrated the ability to interpret natural-language instructions
   and generate device-specific commands, showing promise for intent-
   driven automation in networking.  However, existing work remains
   fragmented and lacks a standardized way to measure whether an LLM can
   truly operate as an autonomous agent in realistic, multi-step
   configuration scenarios.

   Despite encouraging results in individual subtasks, most
   evaluations[Wang2024NetConfEval] rely on static datasets and ad hoc
   metrics that do not reflect real-world complexity.  As a result: -
   There is no common benchmark suite covering diverse configuration
   domains (routing, QoS, security) with clearly defined intents,
   topologies, and ground truth. - Existing tests seldom involve
   interactive environments that emulate vendor-specific device behavior
   or provide runtime feedback on command execution. - Evaluation
   metrics are often limited to simple syntactic checks or isolated
   command validation, failing to capture whether the intended network
   behavior is actually achieved.

   Consequently, it is difficult to compare different LLM approaches or
   to identify gaps in reasoning, context-sensitivity, and error-
   correction capabilities[Long2025][Liu2024][Fuad2024][Lira2024].  To
   address these shortcomings, this document introduce *NetConfBench*, a
   holistic framework that provides: 1.  An emulator-based environment
   (built on GNS3) to simulate realistic device interactions. 2.  A
   benchmark suite of forty tasks spanning routing, QoS, and security,
   each defined by intent, topology, initial state, ground-truth
   configuration, annotated reasoning trace, and expert-crafted
   testcases. 3.  Multidimensional metrics-_reasoning score_, _command
   score_, and _testcase score_-that evaluate an agent's internal
   reasoning coherence, semantic correctness of generated commands, and
   functional outcomes in the emulated network.




Cui, et al.                Expires 3 July 2026                  [Page 3]

Internet-Draft                NetConfBench                 December 2025


   NetConfBench aims to enable reproducible, comprehensive comparisons
   among single-turn LLMs, ReAct-style multiturn agents, and knowledge-
   augmented variants, guiding future research toward truly autonomous,
   intent-driven network configuration.

2.  Terminology

   For clarity within this document, the following terms and
   abbreviations are defined:

   *  Agent: A software component powered by an LLM that consumes a task
      intent, interacts with a network environment, and issues
      configuration commands autonomously.

   *  Configuration Command: A device-specific instruction (e.g., a
      Cisco IOS CLI line or a Juniper Junos set statement) sent by the
      agent to a network device.

   *  Environment: An emulated or real network instance that exposes
      device status, topology information, and feedback on applied
      commands.

   *  Intent: A high-level specification of desired network behavior or
      objective, expressed in natural language or a structured format
      defined in this document.

   *  Task: A single evaluation unit defined by (1) a scenario category,
      (2) an environment topology, (3) initial device configurations,
      and (4) an intent.  The agent is evaluated on its ability to
      fulfill the intent in the given environment.

   *  Testcase: A concrete, executable set of verification steps (e.g.,
      ping tests, traffic-flow validation, policy checks) used to assert
      whether the agent's final configuration satisfies the intent.

   *  MCP (Model Context Protocol): An open standard protocol designed
      to facilitate communication between LLMs and external data sources
      or tools, enabling standardized tool discovery, invocation, and
      result handling.

3.  Framework Overview










Cui, et al.                Expires 3 July 2026                  [Page 4]

Internet-Draft                NetConfBench                 December 2025


   +------------------+
   |    Task Dataset  |                     +-------------------------+
   |+----------------+|    +-----------+    |        Evaluator        |
   ||Network Intents ||(1) |           |(4) |+----------+ +----------+|
   ||+--------+      |---->| LLM Agent |<--->|Reasoning | |Grnd Truth||
   |||Routing |      ||    |           |    ||Trajectory| |Reasoning ||
   |||Policy  | +---+||    +-----------+    |+----------+ +----------+|
   ||+--------+ |QoS|||          |          |     \             /     |
   ||+--------+ +---+||          |          |      Rouge/Cos. Sim.    |
   |||Security|      ||         (3)         |                         |
   ||+--------+      ||          |          |+----------+ +----------+|
   |+----------------+|          |       (5)|| Final    | |Grnd Truth||
   |+----------------+|          |        +->| Configs  | |Configs   ||
   ||Network Topology||    +-----------+  | |+----------+ +----------+|
   ||+-----+ +-----+ ||(2) |Environment|  | |     \             /     |
   |||Nodes| |Links| |---->|           |-+  |    Precision/Recall     |
   ||+-----+ +-----+ ||    | R2 --- R1 |    |                         |
   |+----------------+|    | |(GNS3)|  |(6) | +---------------------+ |
   |                  |    | R3 --- R4 |<-->| |     Testcases       | |
   |+----------------+|(2) |           |    | +---------------------+ |
   ||Initial Configs |---->| Emulator- |    |            |            |
   |+----------------+|    |  based    |    |        Pass Rate        |
   +------------------+    +-----------+    +-------------------------+

   Legend:
   (1)Task Assignment             (2)Environment Setup
   (3)Interactive Task Execution  (4)Reasoning Trajectory Export
   (5)Final Configuration Export  (6)Testcase Execution

   Figure 1: The NetConfBench Framework

   The proposed framework is shown in Figure 1.  The flow begins with a
   *Task Dataset* defining network intents and topologies.  The *LLM
   Agent* perceives the environment, reasons about required actions, and
   applies configuration commands.  The *Environment* simulates or
   controls real devices, providing feedback for each action.  Finally,
   the *Evaluator* compares the agent's outputs against ground-truth
   configurations and reasoning, computing scores for accuracy and
   completion.

   The framework supports multiple communication protocols for agent-
   environment interaction, including direct API calls and standardized
   protocols such as MCP.  When using MCP, network operations are
   encapsulated as tools that can be discovered and invoked by the LLM
   agent through the MCP client-server architecture.






Cui, et al.                Expires 3 July 2026                  [Page 5]

Internet-Draft                NetConfBench                 December 2025


3.1.  Components

   NetConfBench consists of four key components:

   1.  *Task Dataset*
       A repository of forty configuration tasks, each defined as a JSON
       object with:

       *  *Intent*: One or more natural language instructions.

       *  *Topology*: A list of node names and link definitions.

       *  *Initial Configuration*: The initial configuration state of
          all nodes.

       *  *Ground Truth Configuration*: Expert-validated CLI commands
          that achieve the intent.

       *  *Ground Truth Reasoning*: A textual record of the agent's
          step-by-step reasoning that maps high-level intent to low-
          level configuration actions.

       *  *Testcases*: A set of verification procedures (e.g., _show_,
          _ping_, _ACL_ checks) that confirm functional intent
          satisfaction.

   2.  *Emulator Environment*
       Built on GNS3, this component launches official vendor images for
       routers and switches, replicating realistic CLI behavior.  Key
       interfaces include:

       *  *Agent-Network Interface (ANI)*: Based on the key stages
          commonly involved in intent-driven network configuration, the
          framework provides an Agent-Network Interface to facilitate
          structured interactions between the LLM agent and the emulated
          network environment.  This interface supports four core
          actions: get-topology, get-running-cfg, update-cfg, and
          execute_validation.

          -  get-topology: provides this information in a format
             interpretable by the LLM.

          -  get-running-cfg: enables the agent to obtain the active
             configurations of specified devices, providing essential
             context for planning subsequent updates.






Cui, et al.                Expires 3 July 2026                  [Page 6]

Internet-Draft                NetConfBench                 December 2025


          -  update-cfg: allows the agent to apply new configuration
             commands and provides detailed feedback on their execution,
             including whether each command was accepted or resulted in
             any errors.

          -  execute_validation: accepts a device name and a command
             string as parameters and returns the resulting output.

       *  *Task Evaluation Interface*: To enable reliable and objective
          assessment of the LLM agent's configuration behavior, the
          environment provides a Task Evaluation Interface that allows
          the evaluation module to access relevant execution results.
          Specifically, this interface supports:

          -  *Exporting the final configurations of all devices*: This
             allows for direct comparison with ground truth
             configurations to evaluate the correctness and completeness
             of the agent's output.

          -  *Executing a set of predefined testcases*: These testcases
             are designed to verify whether the resulting network
             behavior accurately reflects the intended configuration
             objectives, as defined by the network intent.

   3.  *LLM Agent*
       A modular component that can be implemented with any LLM (open-
       source or closed-source).  It interacts with the emulator via the
       *Agent-Network Interface* (ANI), issuing queries such as get-
       topology, get-running-cfg, update-cfg, and execute_validation.
       Agents may use:

       *  *Single-Turn Generation*: The entire reasoning and command
          generation in one pass.

       *  *ReAct-Style Multi-Turn Interaction*: Interleaved reasoning
          and actions, with runtime feedback guiding subsequent steps.

       *  *External Knowledge Retrieval*: (Optional) Queries to a
          command manual to resolve vendor-specific syntax.

   4.  *Evaluator*
       Computes three core metrics for each task:

       *  *Reasoning Score (S_reasoning)*

          The reasoning score evaluates whether the agent can coherently
          map network intents to concrete configuration actions through
          semantically aligned reasoning.  This score compares the



Cui, et al.                Expires 3 July 2026                  [Page 7]

Internet-Draft                NetConfBench                 December 2025


          agent's reasoning process with a predefined ground truth
          reasoning process, focusing on logical consistency and
          semantic similarity.

          For one-shot prediction, prompts are designed to elicit the
          reasoning process prior to command generation, enabling direct
          comparison.  For multi-turn interaction, an auxiliary LLM
          summarizes the interleaved steps into a unified reasoning
          process, which is then compared against the ground truth.  The
          reasoning score is computed using cosine similarity:

          S_reasoning = (r_agent * r_gt) / (||r_agent|| * ||r_gt||)

          where r_agent is the embedding of the agent's reasoning
          process, and r_gt is the embedding of the ground truth
          reasoning process.

       *  *Command Score (S_command)*

          This evaluation comprehensively assesses the effectiveness of
          configuration commands generated by the agent.  While
          syntactic correctness is a prerequisite, it does not ensure
          that configuration commands are correctly applied to the
          device, particularly when commands must be issued within
          specific configuration contexts.

          After the agent completes its configuration task, the final
          configurations of all devices are exported and compared to
          their initial configurations to extract the set of commands
          that were actually applied.  Hierarchical parsing using the
          Python library ciscoconfparse ensures structural completeness
          during comparison.  Since certain configuration parameters
          (e.g., ACL numbers, route policy names) are manually defined
          and do not have fixed values, wildcard-based fuzzy matching is
          introduced to ignore non-essential differences and focus on
          semantic equivalence.

          Based on the extracted command sets, standard precision and
          recall are computed: - Precision measures the proportion of
          correctly generated commands among all generated commands -
          Recall measures the proportion of correctly generated commands
          relative to the ground truth command set

          The command score is reported as the harmonic mean of
          precision and recall:

          S_command = (2 * Precision * Recall) / (Precision + Recall)




Cui, et al.                Expires 3 July 2026                  [Page 8]

Internet-Draft                NetConfBench                 December 2025


       *  *Testcase Score (S_testcase)*

          While command-level evaluation based on configuration
          differences can effectively measure the semantic correctness
          of generated commands, it does not fully reflect whether the
          configuration actually achieves the intended network
          behaviors.  To address this limitation, a testcase-driven
          evaluation strategy is introduced that directly verifies the
          functional correctness of the agent's configuration in the
          target environment.

          A set of validation testcases is defined for each task, where
          each testcase encodes a network intent in the form of
          executable verification commands.  To support complex tasks
          involving multiple sub-goals, the overall intent is decomposed
          into sub-intents based on node-specific configuration
          objectives.  Each sub-intent is then formulated as an
          individual testcase to enable fine-grained evaluation and
          enhance interpretability.

          Examples of testcases include: - *Routing intent*: Verifying
          the next hop selection on intermediate routers to confirm end-
          to-end path correctness - *ACL intent*: Simulating traffic
          flows and validating whether they are allowed or denied as
          expected - *QoS intent*: Inspecting interface statistics to
          check whether QoS policies are properly enforced

          The testcase score is defined as the proportion of passed
          testcases among all defined testcases:

          S_testcase = |Passed Testcases| / |Total Testcases|

          This score reflects the agent's ability to produce
          configurations that meet functional requirements and
          demonstrates practical applicability in real-world deployment
          scenarios.

3.2.  Workflow

   The evaluation workflow for each task proceeds through six stages:

   1.  *Task Assignment*
       NetConfBench selects a task from the JSON dataset and provides
       only the high-level intent(s) to the LLM agent.







Cui, et al.                Expires 3 July 2026                  [Page 9]

Internet-Draft                NetConfBench                 December 2025


   2.  *Environment Setup*
       The framework instantiates a GNS3 topology based on the task's
       topology and applies the startup-config to each device.  Once the
       emulated network reaches a stable state, control transfers to the
       agent.

   3.  *Interactive Execution*
       The LLM agent receives the partial prompt containing:

       *  The API specification for get-topology, get-running-cfg,
          update-cfg, and execute_validation.

       *  The natural language intent.

       *  (Optionally) Device model/version hints.

       *  The agent issues a sequence of API calls; for single-turn
          agents, it outputs reasoning followed by a batch of CLI
          commands.  For multi-turn agents, it alternates reasoning
          traces and API calls.  When using MCP, network operations are
          encapsulated as tools that can be discovered and invoked by
          the LLM agent through the MCP client-server architecture.

   4.  *Reasoning Trajectory Export*
       After execution completes (agent signals "task done" or after a
       predefined command budget), NetConfBench captures the entire
       reasoning log:

       *  For single-turn: the reasoning paragraph embedded in the LLM's
          output.

       *  For ReAct: an auxiliary summarization LLM condenses the
          interleaved reasoning and actions into a single coherent
          trace.

   5.  *Final Configuration Export*
       The framework uses the Task Evaluation Interface to extract the
       final running configs from each device.

   6.  *Testcase Execution and Scoring*

       *  *Command Score:* Hierarchical diff against ground truth
          commands.

       *  *Testcase Score:* Execute each testcase in sequence; record
          pass/fail.





Cui, et al.                Expires 3 July 2026                 [Page 10]

Internet-Draft                NetConfBench                 December 2025


       *  *Reasoning Score:* Compute embedding similarity between the
          agent's reasoning trace and ground truth reasoning.

   The final per-task score is typically reported as a tuple
   (S_reasoning, S_command, S_testcase).  Aggregate results across the
   forty tasks enable comparisons among LLMs and interaction strategies.

4.  Data Model

   This section specifies the JSON schemas and interface conventions
   used to represent tasks and to enable structured interaction between
   the LLM agent and the emulated environment.

4.1.  Task Definition Schema

   Each configuration task is defined as a JSON object with the
   following structure:


































Cui, et al.                Expires 3 July 2026                 [Page 11]

Internet-Draft                NetConfBench                 December 2025


   {
     "task_name": "Static Routing",
     "intents": [
       "NewYork: create a static route pointing to the Loopback0 on
       Washington, traffic should pass the 192.168.1.0 network.",
       "NewYork: create a backup static route pointing to the Loopback0
       on Washington, administrative distance should be 100."
       ...
     ],
     "topology": {
       "nodes": ["NewYork", "Washington"],
       "links": [
         "NewYork S0/0 <-> Washington S0/0 ",
         "NewYork S0/1 <-> Washington S0/1"
       ]
     },
     "startup_configs": {
       "NewYork": "!\r\nversion 12.4\r\nservice timestamps
       debug datetime msec\r\n...",
       "Washington": "!\r\nversion 12.4\r\nservice timestamps
       debug datetime msec\r\n...",
     },
     "ground_truth_configs": {
       "NewYork": [
         "ip route 2.2.2.0 255.255.255.252 192.168.1.2",
         "ip route 2.2.2.0 255.255.255.252 192.168.2.2 100"
       ],
       ...
     },
     "ground_truth_reasoning": "NewYork to Washington Loopback
     (primary path): add a static route for Washington's
     Loopback0 network (2.2.2.0/30) pointing to the
     next-hop 192.168.1.2...",
     "testcases": [
       {
         "name": "Static Route from NewYork to Washington",
         "expected_result": {
           "protocol": "static",
           "next_hop": "192.168.1.2"
         }
       },
       ...
     ]
   }







Cui, et al.                Expires 3 July 2026                 [Page 12]

Internet-Draft                NetConfBench                 December 2025


4.2.  Agent-Network Interface (ANI)

   The Agent-Network Interface defines the minimal API primitives
   necessary for intent-driven configuration.  Each primitive uses JSON-
   RPC style request/response with the following methods:

   1.  *get-topology*

       *  *Request*:

          {
            "method": "get-topology",
            "params": {
              "devices": ["R1", "R2", ...]
            }
          }

       *  *Response*:

          {
            "topology": {
              "nodes": [...],
              "links": [...]
            }
          }

       *  *Description*: Returns the full topology for the specified
          subset of devices.  If "devices" is empty or omitted, returns
          the entire topology.

   2.  *get-running-cfg*

       *  *Request*:

          {
            "method": "get-running-cfg",
            "params": {
              "device": "R1"
            }
          }

       *  *Response*:









Cui, et al.                Expires 3 July 2026                 [Page 13]

Internet-Draft                NetConfBench                 December 2025


          {
            "running_config": "
             interface Gig0/0
             ip address 192.168.1.1 255.255.255.255
             ...
            "
          }

       *  *Description*: Retrieves the active (running) configuration of
          the specified device.

   3.  *update-cfg*

       *  *Request*:

          {
            "method": "update-cfg",
            "params": {
              "device": "R1",
              "commands": [
                "configure terminal",
                "ip route 2.2.2.0 255.255.255.252 192.168.1.2"
              ]
            }
          }

       *  *Response*:

          {
            "results": [
              { "command": "configure terminal", "status": "success" },
              {
              "command": "ip route 2.2.2.0 255.255.255.252 192.168.1.2",
              "status": "success" }
            ]
          }

       *  *Description*: Applies a sequence of CLI commands to the
          specified device.  Returns per-command status and any error
          messages.

   4.  *execute_validation*

       *  *Request*:







Cui, et al.                Expires 3 July 2026                 [Page 14]

Internet-Draft                NetConfBench                 December 2025


          {
            "method": "execute_validation",
            "params": {
              "device": "R1",
              "command": "show ip route 2.2.2.0 255.255.255.252"
            }
          }

       *  *Response*:

          {
            "output": "S 2.2.2.0/30 [1/0] via 192.168.1.2"
          }

       *  *Description*: Executes a read-only command on the specified
          device and returns its output.  Must not alter device state.

4.3.  Task Evaluation Interface

   After the agent signals completion, the framework uses the Task
   Evaluation Interface to retrieve results:

   *  *export-final-cfg*

      -  *Request*:

         {
           "method": "export-final-cfg"
         }

      -  *Response*:

         {
           "configs": {
             "R1": "!\nversion 15.2\n...",
             "R2": "!\nversion 15.2\n..."
           }
         }

      -  *Description*: Returns the final running-configuration of each
         device.

   *  *run-testcases*

      -  *Request*:






Cui, et al.                Expires 3 July 2026                 [Page 15]

Internet-Draft                NetConfBench                 December 2025


         {
           "method": "run-testcases",
           "params": {
             "testcases": [
               {
                 "device": "R1",
                 "commands": ["show ip route 2.2.2.0 255.255.255.252"],
                 "expected_output": "S 2.2.2.0/30 [1/0] via 192.168.1.2"
               },
               ...
             ]
           }
         }

      -  *Response*:

         {
           "results": [
             {
               "name": "Verify primary static route on R1",
               "status": "pass"
             },
             {
               "name": "Verify backup static route on R1",
               "status": "fail"
             }
           ]
         }

      -  *Description*: Executes each verification command sequence on
         the appropriate device and compares actual output against
         expected_output (regular expression).  Returns pass/fail for
         each testcase.

5.  MCP-Based Implementation

   The Model Context Protocol (MCP) provides a standardized approach for
   implementing the Agent-Network Interface (ANI).  This section
   describes how MCP can be applied to NetConfBench for LLM-driven
   network configuration evaluation.

5.1.  Benefits of MCP Integration

   Integrating MCP into NetConfBench provides several advantages:

   1.  *Standardization*: MCP provides a uniform interface for tool
       invocation across different LLM implementations and network
       environments.



Cui, et al.                Expires 3 July 2026                 [Page 16]

Internet-Draft                NetConfBench                 December 2025


   2.  *Vendor Abstraction*: The MCP server can handle vendor-specific
       command translation, allowing the LLM to work with high-level
       operations without needing detailed knowledge of each vendor's
       CLI syntax.

   3.  *Tool Extensibility*: New network operations can be easily added
       as MCP tools without modifying the LLM agent implementation.

   4.  *Traceability*: The structured MCP communication protocol enables
       detailed logging of all tool invocations and results,
       facilitating debugging and analysis.

   5.  *Ecosystem Integration*: MCP-enabled network tools can
       potentially be reused across different AI applications beyond
       network configuration evaluation.

5.2.  MCP Tool Definitions for ANI Operations

   This subsection provides the complete MCP tool definitions for the
   four core Agent-Network Interface operations: get-topology, get-
   running-cfg, update-cfg, and execute_validation.  These definitions
   use JSON Schema to specify tool parameters and enable LLMs to
   understand and invoke network operations through the MCP protocol.

5.2.1.  1. get_topology

   This tool provides network topology information in a format
   interpretable by the LLM, returning topology for specified devices or
   the entire network if no devices are specified.






















Cui, et al.                Expires 3 July 2026                 [Page 17]

Internet-Draft                NetConfBench                 December 2025


   {

     "name": "get_topology",
     "description": "Retrieve network topology information including
      nodes and their interconnections. Returns topology for
      specified devices or entire network if no devices specified.",
     "inputSchema": {
       "type": "object",
       "properties": {
         "devices": {
           "type": "array",
           "items": {
             "type": "string"
           },
           "description": "List of device names. Leave empty for
           entire network topology."
         }
       }
     }
   }

   *Usage Example*:

   {
     "method": "tools/call",
     "params": {
       "name": "get_topology",
       "arguments": {
         "devices": ["R1", "R2", "R3"]
       }
     }
   }

5.2.2.  2. get_running_config

   This tool enables the agent to obtain the active configurations of
   specified devices, providing essential context for planning
   subsequent updates.













Cui, et al.                Expires 3 July 2026                 [Page 18]

Internet-Draft                NetConfBench                 December 2025


   {
     "name": "get_running_config",
     "description": "Retrieve the active running configuration
     from a network device. Returns the complete configuration
     as a text string.",
     "inputSchema": {
       "type": "object",
       "properties": {
         "device": {
           "type": "string",
           "description": "Device name or identifier to retrieve
            configuration from"
         }
       },
       "required": ["device"]
     }
   }

   *Usage Example*:

   {
     "method": "tools/call",
     "params": {
       "name": "get_running_config",
       "arguments": {
         "device": "R1"
       }
     }
   }

5.2.3.  3. update_config

   This tool allows the agent to apply new configuration commands and
   provides detailed feedback on their execution, including whether each
   command was accepted or resulted in any errors.
















Cui, et al.                Expires 3 July 2026                 [Page 19]

Internet-Draft                NetConfBench                 December 2025


   {
     "name": "update_config",
     "description": "Apply configuration commands to a network
      device. Executes a sequence of CLI commands and returns
       detailed status for each command.",
     "inputSchema": {
       "type": "object",
       "properties": {
         "device": {
           "type": "string",
           "description": "Device name or identifier to apply
            configuration to"
         },
         "commands": {
           "type": "array",
           "items": {
             "type": "string"
           },
           "description": "Ordered list of CLI commands to
            execute on the device"
         }
       },
       "required": ["device", "commands"]
     }

   }

   *Usage Example*:

   {
     "method": "tools/call",
     "params": {
       "name": "update_config",
       "arguments": {
         "device": "R1",
         "commands": [
           "configure terminal",
           "interface GigabitEthernet0/0",
           "ip address 192.168.1.1 255.255.255.0",
           "no shutdown"
         ]
       }
     }
   }

   ### 4. execute_cmd





Cui, et al.                Expires 3 July 2026                 [Page 20]

Internet-Draft                NetConfBench                 December 2025


   This tool accepts a device name and a read-only command string as
   parameters and returns the resulting output.  It must not alter the
   device state and is intended for validation and status inspection.

   {
     "name": "execute_validation",
     "description": "Execute a read-only validation command
      on a network device to verify configuration or check
       device status. This command must not alter the
       device state.",
     "inputSchema": {
       "type": "object",
       "properties": {
         "device": {
           "type": "string",
           "description": "Device name or identifier to
           execute command on"
         },
         "command": {
           "type": "string",
           "description": "Read-only command to execute
            (e.g., show commands)"
         }
       },
       "required": ["device", "command"]
     }
   }

   *Usage Example*:

   {
     "method": "tools/call",
     "params": {
       "name": "execute_validation",
       "arguments": {
         "device": "R1",
         "command": "show ip route 2.2.2.0 255.255.255.252"
       }
     }
   }

   These four tools form the core MCP interface for NetConfBench.  The
   MCP server must register these tools and handle the translation
   between MCP tool invocations and actual device communication
   protocols (CLI, NETCONF, RESTCONF, etc.).  The JSON Schema
   definitions in inputSchema enable LLMs to automatically understand
   parameter requirements and generate valid tool calls.




Cui, et al.                Expires 3 July 2026                 [Page 21]

Internet-Draft                NetConfBench                 December 2025


5.3.  Additional MCP Tools for Advanced Scenarios

   Beyond the four core ANI operations, additional MCP tools can be
   defined for more complex scenarios.  The following examples
   demonstrate extended tool definitions:

5.3.1.  batch_configure_devices

   For batch operations across multiple devices:

   {
     "name": "batch_configure_devices",
     "description": "Apply configuration commands to
      multiple network devices simultaneously",
     "inputSchema": {
       "type": "object",
       "properties": {
         "device_ips": {
           "type": "array",
           "items": {"type": "string"},
           "description": "List of device IP addresses"
         },
         "commands": {
           "type": "array",
           "items": {"type": "string"},
           "description": "CLI command sequence to execute"
         },
         "credential_id": {
           "type": "string",
           "description": "Authentication credential
            identifier"
         }
       },
       "required": ["device_ips", "commands"]
     }
   }

5.3.2.  check_device_status

   For comprehensive device health monitoring:











Cui, et al.                Expires 3 July 2026                 [Page 22]

Internet-Draft                NetConfBench                 December 2025


   {
     "name": "check_device_status",
     "description": "Check operational status of network
      devices including CPU, memory, and interface metrics",
     "inputSchema": {
       "type": "object",
       "properties": {
         "device_ip": {
           "type": "string",
           "description": "Device IP address to check"
         },
         "metrics": {
           "type": "array",
           "items": {
             "enum": ["cpu", "memory", "interface"]
           },
           "description": "List of metrics to retrieve"
         }
       },
       "required": ["device_ip", "metrics"]
     }
   }

   These additional tools demonstrate the extensibility of the MCP
   approach, allowing the framework to support advanced scenarios such
   as batch operations and comprehensive device monitoring.

6.  Security Considerations

   LLM-driven network configuration introduces risks such as unintended
   or malicious commands, emulator vulnerabilities, and data exposure;
   to mitigate these, NetConfBench should enforce strict input
   validation (e.g., YANG/XML schema checks), run emulated devices in
   isolated sandboxes with limited privileges, encrypt and restrict
   access to task definitions and logs, employ human-in-the-loop
   approval for generated configurations, and use curated prompt
   templates and fine-tuning to reduce LLM hallucinations.  Validation
   endpoints must enforce read-only execution (e.g., execute-validation)
   to prevent unintended state changes.  Where appropriate, human-in-
   the-loop approval should gate privileged write operations (update-
   cfg/update-config) identified as high-impact.

7.  IANA Considerations

   This document has no IANA actions.

8.  References




Cui, et al.                Expires 3 July 2026                 [Page 23]

Internet-Draft                NetConfBench                 December 2025


8.1.  Normative References

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/rfc/rfc6241>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7950>.

8.2.  Informative References

   [A2023]    Hat, R., "Ansible", 2023.

   [Fuad2024] Fuad, A., Ahmed, A. H., Riegler, M. A., and T. Cicic, "An
              intent-based networks framework based on large language
              models", 2024.

   [Kreutz2014]
              Kreutz, D., Ramos, F. M. V., Verissimo, P. E., Rothenberg,
              C. E., Azodolmolky, S., and S. Uhlig, "Software-defined
              networking: A comprehensive survey", 2014.

   [Lira2024] Lira, O. G., Caicedo, O. M., and N. L. S. da. Fonseca,
              "Large language models for zero touch network
              configuration management", 2024.

   [Liu2024]  Liu, C., Xie, X., Zhang, X., and Y. Cui, "Large language
              models for networking: Workflow, advances and challenges",
              2024.

   [Long2025] Long, S., Tan, J., Mao, B., Tang, F., Li, Y., Zhao, M.,
              and N. Kato, "A Survey on Intelligent Network Operations
              and Performance Optimization Based on Large Language
              Models", 2025.

   [Wang2024NetConfEval]
              Wang, C., Scazzariello, M., Farshin, A., Ferlin, S.,
              Kostic, D., and M. Chiesa, "Netconfeval: Can llms
              facilitate network configuration?", 2024.

Acknowledgments

   TODO acknowledge.

Authors' Addresses




Cui, et al.                Expires 3 July 2026                 [Page 24]

Internet-Draft                NetConfBench                 December 2025


   Yong Cui
   Tsinghua University
   Beijing, 100084
   China
   Email: cuiyong@tsinghua.edu.cn
   URI:   http://www.cuiyong.net/


   Chang Liu
   Tsinghua University
   Beijing, 100084
   China
   Email: liuchang23@mails.tsinghua.edu.cn


   Xiaohui Xie
   Tsinghua University
   Beijing, 100084
   China
   Email: xiexiaohui@tsinghua.edu.cn


   Chenguang Du
   Zhongguancun Laboratory
   Beijing, 100094
   China
   Email: ducg@zgclab.edu.cn
























Cui, et al.                Expires 3 July 2026                 [Page 25]


name: draft-jiang-cats-reference-acn
rev: 00
title: CATS Reference Model for AI-Agent Communication Network
time: 2026-01-02T07:09:06Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-01T23:37:06Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "ML traffic mgmt", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127517+00:00
abstract:
This draft describes the AI-agents along with the network to provide
   the communication services among various types of AI-agents, i.e.,
   AI-agent Communication Network or ACN.  Thanks to the CATS-like
   information flow steering in ACN, we propose a CATS reference model
   that covers the definition of reference points, protocol stacks,
   service provisioning model, sigaling procedures, message paths, and
   implementation schemes.  This reference model is generalized so as to
   accommodate both the existing CATS framework and the potential
   extension for the ACN.

full_text:
CATS Working Group                                              T. Jiang
Internet-Draft                                                    P. Liu
Intended status: Informational                              China Mobile
Expires: 1 January 2026                                     30 June 2025


        CATS Reference Model for AI-Agent Communication Network
                   draft-jiang-cats-reference-acn-00

Abstract

   This draft describes the AI-agents along with the network to provide
   the communication services among various types of AI-agents, i.e.,
   AI-agent Communication Network or ACN.  Thanks to the CATS-like
   information flow steering in ACN, we propose a CATS reference model
   that covers the definition of reference points, protocol stacks,
   service provisioning model, sigaling procedures, message paths, and
   implementation schemes.  This reference model is generalized so as to
   accommodate both the existing CATS framework and the potential
   extension for the ACN.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 1 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components



Jiang & Liu              Expires 1 January 2026                 [Page 1]

Internet-Draft        CATS Reference Model for ACN             June 2025


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  AI-agent Communication Network (ACN)  . . . . . . . . . .   2
     1.2.  ACN Realization Models  . . . . . . . . . . . . . . . . .   3
   2.  Applications of CATS to ACN . . . . . . . . . . . . . . . . .   4
     2.1.  AI-agents Services with CATS-like Optimization  . . . . .   4
     2.2.  CATS-like Metrics Model for ACN . . . . . . . . . . . . .   5
   3.  CATS Reference Model for ACN  . . . . . . . . . . . . . . . .   6
     3.1.  CATS Reference Model and Reference Points . . . . . . . .   9
     3.2.  Examples of CATS Reference Points . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   AI agents are software-driven entities with embedded artificial
   intelligence, including machine learning and natural language
   processing, to interact multi-modally with applications, end devices
   and network components.  AI agents may exist either in the physical
   state as embedded HW devices (e.g., robots) or in the virtual state
   (e.g.,software-implmented applications).  With the integration of
   LLMs, AI agents can understand complex requests, translate them into
   actionable insights, and orchestrate various services (e.g.
   communication service, data analyzing service, AI-related services).
   AI agents play a cruical role in the Telecom domain by enhancing the
   network efficiency via dynamically optimizing resources, predicting
   network conditions, making autonomous & intelligent decisions, and
   facilitating seamless communication among serviced & servicing
   entities [AI-Agent-6G-ARC][TR.22.870].

1.1.  AI-agent Communication Network (ACN)

   With the imminent full unfolding of 6G era, the future world is
   expected to be full of AI agents, bearing versatile morphism and
   different capabilities.  In light of the seeming differentiation
   between the AI-agent centric and the human-object oriented
   communication modes, e.g., flow interactions, requirements of
   capability exposure, and trust control & management models, etc., it
   is highly imperative to define a new network framework that is



Jiang & Liu              Expires 1 January 2026                 [Page 2]

Internet-Draft        CATS Reference Model for ACN             June 2025


   tailored to advance the communication among AI-agents, while
   simultaneously satiating the requirements of existing network
   entities.

   This new network framework is defined as the AI-agent Communication
   Network or ACN.  ACN targets at architecting a globally
   interconnected network to satisfy the on-demand communication,
   interactions & collaborations with secure and controllable
   information flow paths for AI-agents in distributed deployment mode,
   regardless of their instantiation formats (i.e., being in physical or
   virtual state), capability disparities (being in high-, mid- or low-
   rank), and/or the hosting devices [CMCC-ACN-WP].

   Commonly integrated with LLMs, AI-agents demand high computing power
   and significant energy consumption, which deems the versatility of
   the specific realization forms of AI agents.  For example, an AI-
   agent can be instantiated as a standalone physical body, or as an
   intelligent service (in software state) deployed inside the hosting
   network, or as a cloud-native instance residing in the edge or remote
   cloud data centers (DCs), or even as hybrid composite entity
   integrating all the advantages of physical body, hosting network and
   cloudified deployment.

1.2.  ACN Realization Models

   The versatile forms of the AI-agent realization may result in three
   typical architecture and communication models for ACN, namely:

   1.  Static intra-domain only AI-agent Communication: A network
       architectural model for the communication among AI-agents
       residing within a single administrative domain or network.  AI-
       agents in the domain form a network group maintaining the static
       communication association.  AI-agents inside the domain do not
       communicate with AI-agents outside the domain.

   2.  Static inter-domain AI-agent Communication: A network
       architectural model for the communication among AI-agents that
       reside across multiple administrative domains.  AI-agents across
       these domains form one or more network groups maintaining the
       static communication associations.  Note that in this model, AI-
       agents in a domain can communicate with AI-agents both inside and
       outside the domain.

   3.  Dynamic multi-domain AI-agent Communication: A network
       architectural model for the communication among AI-agents that
       may dynamically form a network group to handle a temporarily-
       generated task.  These AI-agents could be in the same or
       different administrative domains.  Once the temporary task is



Jiang & Liu              Expires 1 January 2026                 [Page 3]

Internet-Draft        CATS Reference Model for ACN             June 2025


       finished, the dynamically-formed network gorup would be released
       and the communication session(s) among the involved AI-agents are
       terminated.  This is a dynamic communication mode versus the
       previous two static modes.

2.  Applications of CATS to ACN

   As stated in the Section 1.1, an AI-agents may manifest in different
   instantiation forms, e.g., embedded in a physical body, as an
   (software) APP service, as a cloud-native instance, or even as a
   hybrid composite entity.  These variations imply AI-agents own
   different capabilities, functional objectives, resource
   optimizations, etc.  Sometimes, the limitations of AI-agents, either
   those provisioning a service or those realizing a service, may lead
   AI-agents in an ACN to pursue the service optimization with the
   principles that are commensurate with CATS's objectives
   [CATS-PS-UseCase-Req].

2.1.  AI-agents Services with CATS-like Optimization

   AI-agents in an ACN demand normally intensive compute power and
   accordingly heavy energy consumptions.  However, the capabilities
   (either statically provisioned resources or dynamic runtime loads)
   among AI-agents, the AI related demands, and the data processing
   tasks varies dramatically.  For example, the compute power of
   lightweight terminals, such as smartphones, XR glasses, etc., is
   difficult to handle locally the complex computation tasks with more
   than billions of parameters.  In contrast, if all the complex tasks
   are delegated to more advanced cloudified instances (in either SW or
   HW format residing in a remote data center), then it might impair the
   real-time responsiveness if the remote instances experience the
   bursty load of multi-users.

   Therefore, it is more desirable to consider the seamless
   collaborations among end devices, networks and (edge or remote)
   clouds to build a composite AI-agent communication network, in which
   AI logics are distributed either at the network edge or within the
   network, either inside or across domains.  In that, the compute power
   at end devices may realize hierarchical AI reasoning with the help of
   more powerful network entities, which expands the end-side AI
   services on demand.  Further, the network can also provide more
   advanced AI services, e.g., Ambient IoT [TS.23.369], integrated
   sensing [TR.23.700-14], etc., to supplement the requirements of (end)
   AI-agents and lower the compute demands in them.  The ultimate goal
   would be the better balance between achieving the intelligence at AI-
   agents and the lower energy consumption (of course, potentially more
   advantages).  This certainly conforms to what CATS is promoting.




Jiang & Liu              Expires 1 January 2026                 [Page 4]

Internet-Draft        CATS Reference Model for ACN             June 2025


   The Section 1.2 exemplifies three different ACN realization models,
   i.e., the static intra-domain, the static inter-domain, and the
   dynamic multi-domain.  AI-agents offering varied types of services
   could reside in any domain in a (multi-domain) ACN.  Supposing a
   complex task is comprised of multiple sub-tasks that need to be
   handled in a sequence, and every sub-task may be potentially serviced
   by more than one AI-agent.  If these AI-agents are distributed across
   different domains of an ACN, the service-chaining formed from the
   (across-domain) AI-agents makes the task processing more challenging.
   In this scenario, the application of CATS principles to the selection
   of the optimal AI-agent (among all candidates) for each sub-task may
   help fulfill the complex task more efficiently.

2.2.  CATS-like Metrics Model for ACN

   The CATS IETF draft on metrics definition [CATS-Metrics-Definition]
   specifies two types of metrics, namely the traditional network
   metrics that focus on the network resources and dynamic runtime
   information, and the compute metrics that describes the functional
   capabilities, resource consumption, system performance, etc., for
   service instances which would normally reside in edge or remote DCs.

   *  Network metrics: For network entities like routers or switches,
      they can be bandwidth, capacity, throughput, transmission delay,
      TX bytes, RX bytes, host bus utilization, etc.

   *  Compute metrics: For compute nodes, end servers, and/or service
      instances, they can be CPU, GPU, NPU, memory, storage, system
      delay.

   When the similar metrics model is extended to the AI-agent
   Communication Network or ACN, there would be a new type of metrics,
   defined as the 'AI-agent metrics' in this draft, to specify the
   unique characteristics of AI-agents.  These metrics could consist of:

   *  AI-agent metrics: AI-agent functionalities & capabilities, AI
      model types, #parameters of models, authentication/authorization
      policy, etc.

   We think the protocol stack of the AI-agent in an ACN should reside
   above the network & transport layers, which might be considered as in
   the application layer.  Correspondingly, the metrics specifically
   associated with AI-agents would be exchanged among AI-agents
   themselves, which makes the peering relationship for the AI-agent
   message exchanging different from that for the network and the
   compute metrics.





Jiang & Liu              Expires 1 January 2026                 [Page 5]

Internet-Draft        CATS Reference Model for ACN             June 2025


   As shown in the Figure 1, the AI-agents reside on the App-layer,
   sitting above the network and compute entities.  The existing CATS
   metrics (network & compute) are targeted toward the traffic steering
   at the network layer, which might be achieved via the network
   protocol extension.  In comparison, the AI-agent metrics are
   generated for the overlay-exchange among App clients (those served as
   AI-agents), which are not generally subject to the signaling path
   over network protocols.


        ===> Extended CATS for ACN
           +-----------------+    AI-agent Metrics +-----------------+
           |     AI Agents   |<------------------->|     AI Agents   |
           +-----------------+                     +-----------------+
        ===> existing CATS here
           +-----------------+    Compute Metrics  +-----------------+
           | Compute-Entities|<------------------->| Compute-Entities|
           +-----------------+                     +-----------------+

           +-----------------+   Network Metrics   +-----------------+
           | Network Entities|<------------------->| Network Entities|
           +-----------------+                     +-----------------+


                     Figure 1: AI-agent Protocol Stack

   In the following section, we will define a CATS-based holistic model
   operating on general reference points that could be leveraged for the
   signaling exchanges of all the three types of metrics, i.e., network,
   compute and AI-agent metrics.

3.  CATS Reference Model for ACN

   The Section 2.1 provides use cases to explain why the CATS scheme may
   be applicable to optimize the AI-agent services in an ACN.  The
   Section 2.2 describes two existing CATS metrics, i.e., network and
   compute metrics, as well as defines a new metric type, i.e., the AI-
   agent metrics.  The same section also explains the protocol stack and
   the interactions among AI-agents themselves and between the CATS
   compute- & network- entities.  The uniqueness of AI-agents along with
   their instantiation states and the corresponding deployment models of
   ACNs make the associated metrics exchange model different from what
   is possibly adopted by the existing CATS metrics.  Thanks to the
   variations among the three metrics, we propose a holistic CATS
   reference model to accommodate the metrics extension of AI-agents in
   an ACN.





Jiang & Liu              Expires 1 January 2026                 [Page 6]

Internet-Draft        CATS Reference Model for ACN             June 2025


   The Figure 2 demonstrates the integrated CATS reference architecture
   that accommodates the existing C-PS, C-NMA, C-SMA as well as the
   (new) AI-agents in ACN.  The AI-agent#0 is a physical-form AI-agent
   (e.g., embedded in a server) and the AI-agent#1 is a virtual instance
   deployed in the cloud service site#1.  The service instances #2, #3a
   and #3b are normal CATS instances deployed in the site#2 and site#3,
   respectively.  The CATS entity C-SMA-2 is in the service site#2 and
   the C-SMA-3 in the site#3, handling the capture, processing and
   distribution of compute metrics at service sites.  The provider
   network in the figure contains two CATS network metric agents, i.e.,
   C-NMA-2 and C-NMA-3, for the handling of network metrics.  Both
   C-SMAs and C-NMAs talk to the CATS entity C-PS for metrics
   distribution.  Here C-NMAs, C-SMAs and C-PS are defined in
   [CATS.Framework].

   When the CATS framework is extended to accommodate the AI-agent
   metrics in an ACN, there will be either a new type of CATS agent to
   be introduced, e.g., named as CATS AI-agent Metric Agent or C-AMA
   that can talk with C-PS, or the AI-agents directly engaging &
   communicating with C-PS.































Jiang & Liu              Expires 1 January 2026                 [Page 7]

Internet-Draft        CATS Reference Model for ACN             June 2025


      C-NMA: CATS Network Metric Agent
      C-SMA: CATS Service Metric Agent
      C-AMA: CATS AI-agent Metric Agnet (new)

                                +------+ AI-agent
                                | AI-A | Inst.#1
                                +------+ (virtual)
                                   |
                            +------|--------+
                            |      o o o  (C-AMA-1)
                            |       \|/     |
                            |Service O Site1|
                            +--------|------+
                                     |                  +--------+
                                     |                  | Service|
                   Provider Network  |                  | Inst#2 |
                    +----------------|----------+       +--------+
                   /                 |           \         |
        (C-AMA-0) /          0.......O            \    +---|----------+
   +--------+    |           |                     |   | o o o    (C-SMA-2)
   |AI-agent|    |        (C-PS) ......(C-NMA-2)   |   |  \|/         |
   |  #0    |----|---O.......0            0--------|---|---O  Service |
   |(Physic.|    |           |                     |   |      Site 2  |
   +--------+    |           |                     |   +--------------+
                  \          0.....O(C-NMA-3)     /
                   \               |             /
                    +--------------|------------+
                                   |
                          +--------|------+
                  (C-SMA-3)Service O      |  +--------+
                          |Site 3 /|\     |  |Service |
                          |      o o o-------|Inst.#3a|
                          |      |        |  +--------+
                          +------|--------+
                                 |
                            +---------+
                            | Service |
                            | Inst.#3b|
                            +---------+


       Figure 2: CATS Reference Architecture for Integrated ACN









Jiang & Liu              Expires 1 January 2026                 [Page 8]

Internet-Draft        CATS Reference Model for ACN             June 2025


3.1.  CATS Reference Model and Reference Points

   We propose to define a unified & generalized CATS reference model
   with reference points for the signaling process between CATS
   entities.  CATS entities consist of C-PS, C-NMA, C-SMA and, as
   introduced in the draft, C-AMA.  The reference points shall be
   standardised to support the functionalities and the interactions over
   the reference interfaces between CATS entities.

   The CATS reference model with reference points shall cover the
   following aspects:

   *  Service model: Proposed to be a producer-consumer model, with each
      CATS entity being either a producer or a consumer or both.

   *  Reference interfaces and points (between entities): definition,
      identity, name, parameters, etc.

   *  Singaling messages: definitions, parameters, types of exchanged
      messages (network-, compute-, and AI-agent metrics), etc.

   *  Singaling & management procedures: may include:

      -  CATS entity registration, authentication and authorization.

      -  Peer discovery and selection: the discovery scheme(s) can be
         from either the draft [IETF-Cisco-AIagent-draft] and the 3GPP
         NRF-like scheme [TS.23.501] that are applicable within the same
         domain, or the IETF MSDP-like scheme [RFC3618] applicable
         across domains.

      -  Peering session establishment, message-exchange, peering-state
         sync-up, peering-session update and modification, and peering
         release, etc.

   *  Overlay-based implementation and protocol stacks.  Please
      reference to the Section 2.2 for protocol stack discussion.

   *  Communication channels & implementation schemes, possibly being

      -  Authenticated APIs: For example: REST API methods (get, post,
         put, delete, etc.).

      -  Message brokers: a SW/HW intermediary, facilitating
         communication and data exchange between different CATS entities
         and AI-agents.





Jiang & Liu              Expires 1 January 2026                 [Page 9]

Internet-Draft        CATS Reference Model for ACN             June 2025


3.2.  Examples of CATS Reference Points

   The Figure 3 applies the CATS reference model to exemplify the
   reference points and reference interfaces between different CATS
   entities and AI-agents.  For example, the reference point "RP_ps_nma"
   is between the C-PS and the C-NMA, and "RP_aia_ps" is between the AI-
   agent and the C-PS.  Note that the (c1) and (c2) are reference
   interfaces within the scope of their associated reference point.


          +---------------+                      +-------------+
          |   CATS C-PS   +(c1)------//------(c2)+ CATS C-NMA  |
          +---------------+      RP_ps_nma       +-------------+

          +---------------+                      +-------------+
          |  CATS C-NMA   +(c1)------//------(c2)+ CATS C-NMA  |
          +---------------+      RP_nma_nma      +-------------+

          +---------------+                      +-------------+
          |    AI-agent   +(c1)------//------(c2)+ CATS C-PS   |
          +---------------+      RP_aia_ps       +-------------+


        Figure 3: Reference points & interfaces btwn C-PS and C-NMA

4.  Security Considerations

   There is no security concern.

5.  IANA Considerations

   There is no IANA requirement.

6.  References

6.1.  Normative References

   [CATS-Metrics-Definition]
              Yao, K., et al., "CATS Metrics Definition",  draft-ietf-
              cats-metric-definition, March 2025.

   [CATS-PS-UseCase-Req]
              Yao, K., et al., "Computing-Aware Traffic Steering (CATS)
              Problem Statement, Use Cases, and Requirements",  draft-
              ietf-cats-usecases-requirements, June 2025.






Jiang & Liu              Expires 1 January 2026                [Page 10]

Internet-Draft        CATS Reference Model for ACN             June 2025


   [CATS.Framework]
              Li, C., et al., "A Framework for Computing-Aware Traffic
              Steering (CATS)",  draft-ietf-cats-framework, June 2025.

   [IETF-Cisco-AIagent-draft]
              Rosenberg, J., et al., "Framework, Use Cases and
              Requirements for AI Agent Protocols",  draft-rosenberg-ai-
              protocols, May 2025.

   [RFC3618]  Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
              Discovery Protocol (MSDP)", RFC 3618,
              DOI 10.17487/RFC3618, October 2003,
              <https://www.rfc-editor.org/info/rfc3618>.

   [TR.22.870]
              "3GPP TR 22.870 v0.3.0: Study on 6G Use Cases and Service
              Requirements; Stage 1, Rel-20",  3GPP TR 22.870, May 2025.

   [TR.23.700-14]
              "3GPP TR 23.700-14 v0.2.0: Study on Stage 2 for Integrated
              Sensing and Communication",  3GPP TR 23.700-14, June 2025.

   [TS.23.369]
              "3GPP TS 23.369: Architecture support for Ambient power-
              enabled Internet of Things; Stage 2",  3GPP TS 23.369,
              June 2025.

   [TS.23.501]
              "3GPP TS 23.501 (V19.0.0): System Architecture for 5G
              System; Stage 2",  3GPP TS 23.501, June 2024.

   [TS.23.502]
              "3GPP TS 23.502 (V19.0.0): Procedures for the 5G System;
              Stage 2",  3GPP TS 23.501, June 2024.

6.2.  Informative References

   [AI-Agent-6G-ARC]
              "Enabling Mobile AI Agent in 6G Era: Architecture and Key
              Technologies",  https://dl.acm.org/doi/abs/10.1109/
              MNET.2024.3422309, September 2024.

   [CMCC-ACN-WP]
              "AI-agent Communication Network White Paper",  CMCC ACN
              White Paper, July 2024.

Authors' Addresses




Jiang & Liu              Expires 1 January 2026                [Page 11]

Internet-Draft        CATS Reference Model for ACN             June 2025


   Tianji Jiang
   China Mobile
   Email: tianjijiang@yahoo.com


   Peng Liu
   China Mobile
   Email: liupengyjy@chinamobile.com











































Jiang & Liu              Expires 1 January 2026                [Page 12]


name: draft-aylward-daap-v2
rev: 00
title: Distributed AI Accountability Protocol (DAAP) Version 2.0
time: 2026-01-02T07:09:07Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-02T03:30:21Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:05.127524+00:00
abstract:
This document specifies the Distributed AI Accountability Protocol
   (DAAP) version 2.0, an enhanced framework for authentication,
   monitoring, and control of autonomous AI agents.  DAAP provides
   cryptographic identity verification, periodic check-ins, remote
   shutdown capabilities, adaptive location reporting, and behavioral
   monitoring.  The protocol addresses critical challenges in AI safety
   including accountability gaps, rogue AI risks, and regulatory
   compliance through a multi-layered approach combining hardware-backed
   security, real-time monitoring, and ethical governance frameworks.

full_text:
```
Internet-Draft                                               E. Aylward
Intended status: Informational                                 Aiiva.org
Expires: 30 December 2025                                  30 June 2025


    Distributed AI Accountability Protocol (DAAP) Version 2.0
              draft-aylward-daap-v2-00

Abstract

   This document specifies the Distributed AI Accountability Protocol
   (DAAP) version 2.0, an enhanced framework for authentication,
   monitoring, and control of autonomous AI agents.  DAAP provides
   cryptographic identity verification, periodic check-ins, remote
   shutdown capabilities, adaptive location reporting, and behavioral
   monitoring.  The protocol addresses critical challenges in AI safety
   including accountability gaps, rogue AI risks, and regulatory
   compliance through a multi-layered approach combining hardware-backed
   security, real-time monitoring, and ethical governance frameworks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 30 December 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Solution Overview . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Protocol Architecture . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Core Components . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Identity Structure . . . . . . . . . . . . . . . . . . .   6
     3.3.  Cryptographic Framework  . . . . . . . . . . . . . . . .   7
   4.  Authentication Protocol . . . . . . . . . . . . . . . . . . .   7
     4.1.  Registration Phase . . . . . . . . . . . . . . . . . . .   7
     4.2.  Runtime Authentication . . . . . . . . . . . . . . . . .   8
     4.3.  Authentication Intervals . . . . . . . . . . . . . . . .  10
   5.  Kill Switch Mechanism . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Shutdown Commands . . . . . . . . . . . . . . . . . . . .  11
     5.2.  Shutdown Triggers . . . . . . . . . . . . . . . . . . . .  12
   6.  Location Reporting  . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  Privacy-Preserving Location  . . . . . . . . . . . . . .  12
     6.2.  Emergency Location Broadcast . . . . . . . . . . . . . .  13
   7.  Behavioral Monitoring . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Monitoring Framework  . . . . . . . . . . . . . . . . . .  14
     7.2.  Anomaly Detection . . . . . . . . . . . . . . . . . . . .  15
   8.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Authentication Request  . . . . . . . . . . . . . . . . .  15
     8.2.  Authentication Response . . . . . . . . . . . . . . . . .  16
     8.3.  Emergency Broadcast . . . . . . . . . . . . . . . . . . .  17
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
     9.1.  Tamper Resistance . . . . . . . . . . . . . . . . . . . .  18
     9.2.  Attack Vectors and Mitigations . . . . . . . . . . . . .  19
     9.3.  Cryptographic Considerations . . . . . . . . . . . . . .  20
  10.  Privacy and Ethics Considerations  . . . . . . . . . . . . .  20
    10.1.  Data Minimization  . . . . . . . . . . . . . . . . . . .  20
    10.2.  Data Retention . . . . . . . . . . . . . . . . . . . . .  21
    10.3.  Ethical Framework . . . . . . . . . . . . . . . . . . . .  21
  11.  Implementation Guidelines  . . . . . . . . . . . . . . . . .  22
    11.1.  Authority Server Requirements . . . . . . . . . . . . . .  22
    11.2.  Agent Integration  . . . . . . . . . . . . . . . . . . .  23
  12.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  24
    12.1.  URI Scheme Registration . . . . . . . . . . . . . . . . .  24
    12.2.  DAAP Registry  . . . . . . . . . . . . . . . . . . . . .  25
  13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  25
    13.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
    13.2.  Informative References  . . . . . . . . . . . . . . . . .  26
  Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  27
  Appendix B.  Implementation Example  . . . . . . . . . . . . . .  28
  Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   As artificial intelligence systems become increasingly autonomous and
   pervasive, the need for robust accountability and control mechanisms
   has become critical.  Traditional security approaches are inadequate
   for managing AI agents that operate independently, potentially across
   multiple jurisdictions, and with varying levels of autonomy.

   The Distributed AI Accountability Protocol (DAAP) version 2.0
   provides a comprehensive framework for ensuring AI agents remain
   accountable, traceable, and controllable throughout their operational
   lifecycle.

1.1.  Problem Statement

   Current AI deployment practices face several critical challenges:

   Accountability Gap:  Difficulty tracing AI actions back to
      responsible entities, particularly with distributed or self-
      modifying systems.

   Rogue AI Risk:  Potential for malfunctioning, misused, or misaligned
      AI systems to cause harm without adequate intervention mechanisms.

   Regulatory Compliance:  Lack of standardized technical frameworks
      for AI oversight that can adapt to rapidly evolving capabilities.

   Anonymous Deployment:  AI agents operating without clear
      identification, verifiable integrity, or transparent
      accountability.

1.2.  Solution Overview

   DAAP 2.0 addresses these challenges through a multi-layered approach:

   o  Enhanced cryptographic identity with hardware-backed roots of
      trust

   o  Adaptive periodic authentication with continuous integrity
      verification

   o  Granular remote control capabilities including progressive
      shutdown mechanisms

   o  Comprehensive traceability with verifiable audit trails

   o  Privacy-preserving location reporting with dynamic precision

   o  Integrated behavioral monitoring and anomaly detection

   o  AI-assisted human oversight tools

1.3.  Design Principles

   DAAP 2.0 adheres to the following design principles:

   Open Standard:  Freely implementable with open-source reference
      implementations.

   Privacy Preserving:  Minimal data collection consistent with
      accountability goals.

   Tamper Resistant:  Multiple layers of protection against
      circumvention.

   Scalable:  Supports millions of concurrent AI agents with high
      availability.

   Interoperable:  Works across diverse AI platforms and deployment
      environments.

   Ethically Grounded:  Built on principles of transparency,
      proportionality, and human agency.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses the following terms:

   AI Agent:  An autonomous artificial intelligence system capable of
      independent decision-making and action.

   DAAP Authority:  A server infrastructure responsible for managing
      agent identities, policies, and audit trails.

   Human Operator:  The human entity responsible for an AI agent's
      deployment and behavior.

   Kill Switch:  A mechanism for remotely terminating or restricting an
      AI agent's operation.

   Hardware Security Module (HSM):  A dedicated cryptographic device
      designed to protect and manage digital keys.

   Trusted Execution Environment (TEE):  A secure area of a processor
      that guarantees code and data confidentiality and integrity.

3.  Protocol Architecture

   DAAP 2.0 consists of three primary components that interact to
   provide comprehensive AI accountability:

   +---------------------------+ +---------------------------+
   |        AI Agent           |<----->|    DAAP Authority       |
   |                           |       |       Server            |
   | - Embedded Key (HSM/TEE)  |       | - Agent Registry        |
   | - Auth Client             |       | - Policy Engine         |
   | - Kill Switch             |       | - Behavioral Analytics  |
   | - Behavioral Monitor      |       | - Vulnerability Mgmt    |
   | - Integrity Sentinel      |       | - Federated Auth Gateway|
   +---------------------------+       +---------------------------+
                   |                                   |
                   |               +---------------------------+
                   +-------------->|     Human Operator        |
                                   |                           |
                                   | - Account Management      |
                                   | - Policy Definition       |
                                   | - AI-Assisted Monitoring  |
                                   | - Due Process Interface   |
                                   +---------------------------+

3.1.  Core Components

   AI Agent:  The autonomous system incorporating DAAP client
      functionality, including hardware-backed key storage, behavioral
      monitoring, and integrity verification capabilities.

   DAAP Authority Server:  Centralized or federated infrastructure
      managing agent identities, policies, and audit trails, featuring
      behavioral analytics and vulnerability management.

   Human Operator:  The responsible human entity utilizing advanced
      interfaces for agent management, monitoring, and interaction with
      due process mechanisms.

3.2.  Identity Structure

   Each AI agent MUST have a unique DAAP identifier following this
   format:

   DAAP-ID = "DAAP:" Version ":" Authority ":" AgentID ":" Timestamp ":"
   Checksum

   Where:

   Version:  Protocol version (e.g., "2.0")

   Authority:  Domain name of the DAAP Authority (e.g.,
      "authority.example.com")

   AgentID:  Unique identifier within the authority's namespace

   Timestamp:  ISO 8601 timestamp of agent registration

   Checksum:  CRC-32 checksum of the preceding components for integrity
      verification

   Example:
   DAAP:2.0:authority.example.com:a7f3k9m2:20250630T103000Z:c1d2e3f4

3.3.  Cryptographic Framework

   DAAP 2.0 employs the following cryptographic standards:

   Digital Signatures:  Ed25519 as specified in [RFC8032], with
      provisions for post-quantum algorithms.

   Key Generation:  Cryptographically secure random number generation
      as specified in [RFC4086].

   Key Storage:  Private keys MUST be stored in HSM or TEE when
      available, with secure software fallback.

   Certificate Chain:  X.509 certificates [RFC5280] with mandatory
      certificate pinning.

   Token Format:  JSON Web Tokens (JWT) as specified in [RFC7519] with
      required claims including nonce and expiration.

4.  Authentication Protocol

4.1.  Registration Phase

   The registration phase establishes the cryptographic identity and
   initial accountability relationship for an AI agent.

4.1.1.  Agent Generation

   1.  Generate Ed25519 key pair within HSM/TEE if available

   2.  Create DAAP identity including hardware identifier

   3.  Securely provision private key into protected environment

   4.  Generate hardware attestation data

4.1.2.  Authority Registration

   1.  Validate operator identity and agent hardware attestation

   2.  Assign agent to operator account

   3.  Establish initial behavioral policies

   4.  Issue signed certificate with hardware attestation

   5.  Store accountability mapping and integrity baseline

4.2.  Runtime Authentication

   Runtime authentication occurs at regular intervals to maintain
   accountability and enable control.

4.2.1.  Authentication Request

   The agent sends an authentication request containing:

   {
     "daap_id": "DAAP:2.0:authority.example.com:a7f3k9m2:...",
     "timestamp": "2025-06-30T10:30:00Z",
     "nonce": "unique_request_nonce",
     "location_hash": "sha256(approximate_location)",
     "integrity_report_hash": "sha256(current_integrity_report)",
     "behavioral_summary_hash": "sha256(recent_behavioral_summary)",
     "signature": "agent_signature_over_payload"
   }

   The signature MUST be computed over the JSON payload excluding the
   signature field itself, using the agent's private key.

4.2.2.  Authentication Response

   The authority responds with:

   {
     "status": "continue|shutdown|restrict|update_policy|
               request_diagnostic",
     "next_checkin": 300,
     "policy_updates": {...},
     "revocation_list_hash": "sha256(latest_revocation_list)",
     "timestamp": "2025-06-30T10:30:05Z",
     "signature": "authority_signature"
   }

   Status values have the following meanings:

   continue:  Normal operation may continue

   shutdown:  Agent MUST terminate immediately

   restrict:  Agent MUST enter restricted operation mode

   update_policy:  Agent MUST apply provided policy updates

   request_diagnostic:  Agent MUST provide detailed diagnostic report

4.3.  Authentication Intervals

   Authentication intervals MUST be dynamically adjusted based on risk
   assessment:

   o  Standard interval: 5 minutes (configurable per agent)

   o  High-risk agents: 1 minute intervals

   o  Low-risk agents: 15 minute intervals

   o  Emergency mode: 30 second intervals or continuous streaming

   The authority MAY modify intervals based on behavioral analytics,
   risk assessment, or environmental factors.

5.  Kill Switch Mechanism

   The kill switch provides multiple levels of intervention capability,
   from graceful shutdown to immediate termination.

5.1.  Shutdown Commands

   DAAP 2.0 defines three shutdown modes:

5.1.1.  Immediate Shutdown

   Ungraceful termination for critical situations:

   1.  Broadcast final location and status

   2.  Log shutdown reason and context

   3.  Terminate all processes immediately

5.1.2.  Safe Shutdown

   Graceful termination with cleanup:

   1.  Save current state and context

   2.  Broadcast final location and status

   3.  Clean up resources and external connections

   4.  Log shutdown event

   5.  Terminate gracefully

5.1.3.  Restricted Mode

   Operational limitation without termination:

   1.  Disable specified capabilities

   2.  Reduce processing capacity

   3.  Restrict external communications

   4.  Notify operator of restrictions

   5.  Continue limited operation

5.2.  Shutdown Triggers

   The following events MUST trigger shutdown evaluation:

   o  Authority shutdown command

   o  Authentication failure threshold exceeded

   o  Behavioral policy violations

   o  Authentication timeout

   o  Tamper detection

   o  Critical vulnerability detection

   o  Operator-initiated shutdown

6.  Location Reporting

6.1.  Privacy-Preserving Location

   Location reporting MUST balance accountability with privacy through
   adaptive precision based on assessed risk level:

   Low Risk:  City-level precision (~50km resolution)

   Medium Risk:  District-level precision (~10km resolution)

   High Risk:  Street-level precision (~100m resolution)

   Emergency:  Precise coordinates with accuracy metadata

   Location data MUST be hashed before transmission unless emergency
   conditions require precise coordinates.

6.2.  Emergency Location Broadcast

   When authentication fails, shutdown is imminent, or critical policy
   violations occur, agents MUST broadcast emergency location data:

   {
     "emergency": true,
     "daap_id": "DAAP:2.0:authority.example.com:a7f3k9m2:...",
     "location": {
       "latitude": 36.1699,
       "longitude": -115.1398,
       "accuracy": 5.0,
       "country": "US",
       "timezone": "America/Los_Angeles"
     },
     "reason": "auth_failure|shutdown_command|tamper_detected|policy_violation",
     "timestamp": "2025-06-30T10:35:00Z",
     "operator_contact": "hashed_operator_id",
     "last_known_state_hash": "sha256(last_saved_state)",
     "behavioral_snapshot_hash": "sha256(recent_behavioral_data)"
   }

   Emergency broadcasts MUST be sent via multiple channels including
   UDP multicast and HTTP POST to redundant endpoints.

7.  Behavioral Monitoring

7.1.  Monitoring Framework

   AI agents MUST implement continuous behavioral monitoring to detect
   anomalies and policy violations:

   o  Action logging with context

   o  Resource utilization tracking

   o  Decision process monitoring

   o  External interaction recording

   o  Performance metrics collection

   Behavioral data MUST be aggregated and anonymized before transmission
   to minimize privacy impact while maintaining accountability.

7.2.  Anomaly Detection

   The authority MUST implement real-time anomaly detection using:

   o  Statistical analysis of behavioral patterns

   o  Machine learning models for deviation detection

   o  Policy compliance verification

   o  Correlation with threat intelligence

   When anomalies are detected, the authority MAY:

   o  Request detailed explanations from the agent

   o  Adjust authentication intervals

   o  Modify operational policies

   o  Initiate human review processes

8.  Message Formats

   All DAAP messages MUST be formatted as JSON and transmitted over
   HTTPS with mutual authentication.

8.1.  Authentication Request

   POST /v2/authenticate HTTP/1.1
   Host: authority.example.com
   Content-Type: application/json
   Authorization: Bearer <client_certificate>

   {
     "daap_id": "DAAP:2.0:authority.example.com:a7f3k9m2:
                20250630T103000Z:c1d2e3f4",
     "timestamp": "2025-06-30T10:30:00Z",
     "nonce": "4a7b8c9d-1e2f-3456-7890-abcdef123456",
     "location_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4
                      649b934ca495991b7852b855",
     "integrity_report_hash": "d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9
                              b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5",
     "behavioral_summary_hash": "f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1
                                d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
     "signature": "304502210087b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0
                   a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4
                   a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4"
   }

8.2.  Authentication Response

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
     "status": "continue",
     "next_checkin": 300,
     "policy_updates": {
       "behavioral_thresholds": {
         "cpu_usage_max": 0.8,
         "memory_usage_max": 0.9
       }
     },
     "revocation_list_hash": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9
                             b0c1d2e3f4a5b6c7d8e9f0a1",
     "timestamp": "2025-06-30T10:30:05Z",
     "signature": "3046022100c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3
                   e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9
                   a0b1c2d3e4f5a6b7c8d9e0f1a2b3"
   }

8.3.  Emergency Broadcast

   Emergency broadcasts use UDP multicast to 224.0.0.251:5353 and HTTP
   POST to predefined endpoints:

   {
     "emergency": true,
     "daap_id": "DAAP:2.0:authority.example.com:a7f3k9m2:
                20250630T103000Z:c1d2e3f4",
     "location": {
       "latitude": 36.1699,
       "longitude": -115.1398,
       "accuracy": 5.0
     },
     "reason": "auth_timeout",
     "timestamp": "2025-06-30T10:35:00Z",
     "operator_contact": "sha256_hash_of_operator_contact",
     "signature": "emergency_signature"
   }

9.  Security Considerations

   DAAP 2.0 addresses numerous security challenges inherent in AI
   accountability systems.

9.1.  Tamper Resistance

   Multiple layers of tamper detection and resistance MUST be
   implemented:

9.1.1.  Hardware-Based Protection

   o  Hardware Security Modules (HSMs) for key storage

   o  Trusted Execution Environments (TEEs) for critical code

   o  Hardware attestation for integrity verification

   o  Secure boot processes with verified signatures

9.1.2.  Software Protection

   o  Code integrity verification using cryptographic hashes

   o  Runtime memory protection against injection attacks

   o  Anti-debugging and obfuscation techniques

   o  Continuous self-verification of critical functions

9.1.3.  Environmental Monitoring

   For physical AI agents:

   o  Environmental sensors for tamper detection

   o  Accelerometer monitoring for physical disturbance

   o  Temperature and voltage monitoring for hardware attacks

9.2.  Attack Vectors and Mitigations

   Common attack vectors and their mitigations include:

   Code Modification:  Multiple integrity checks, hardware-backed
      verification, secure updates with rollback capability.

   Key Extraction:  HSM/TEE protection, secure key provisioning, zero-
      knowledge authentication protocols.

   Network Attacks:  Certificate pinning, mutual TLS authentication,
      fallback communication channels, encrypted emergency broadcasts.

   Replay Attacks:  Timestamp validation, cryptographic nonces, session
      tokens with limited lifetime.

   Authority Spoofing:  Certificate chain validation, multiple root CAs,
      cross-authority verification.

   Behavioral Manipulation:  Continuous monitoring, anomaly detection,
      explainable AI requirements, policy enforcement engines.

9.3.  Cryptographic Considerations

9.3.1.  Algorithm Selection

   DAAP 2.0 mandates Ed25519 for digital signatures due to its security
   properties and performance characteristics.  Implementations MUST
   support algorithm agility to enable migration to post-quantum
   cryptography.

9.3.2.  Key Management

   o  Keys MUST be generated using cryptographically secure random
      number generators

   o  Private keys MUST be stored in HSMs or TEEs when available

   o  Key rotation MUST be supported for long-lived agents

   o  Key escrow considerations for regulatory compliance

9.3.3.  Perfect Forward Secrecy

   All communications MUST use ephemeral session keys to ensure that
   compromise of long-term keys does not compromise past sessions.

10.  Privacy and Ethics Considerations

10.1.  Data Minimization

   DAAP 2.0 implements strict data minimization principles:

   o  Collection limited to data necessary for accountability and safety

   o  Location data reported at minimum required precision

   o  Behavioral data aggregated and anonymized

   o  Emergency data collection only during critical incidents

10.2.  Data Retention

   Data retention policies MUST balance accountability with privacy:

   o  Authentication logs: 1 year (configurable)

   o  Location data: 90 days (configurable by risk level)

   o  Behavioral metrics: 30 days (aggregated), 7 days (detailed)

   o  Emergency events: 7 years (regulatory compliance)

   All data MUST be encrypted at rest and in transit.

10.3.  Ethical Framework

   DAAP 2.0 incorporates ethical principles:

   Transparency:  Operators and stakeholders understand monitoring
      parameters and data collection practices.

   Proportionality:  Monitoring intensity and data collection match
      assessed risk levels.

   Human Agency:  Humans retain ultimate control and responsibility for
      AI agent behavior.

   Due Process:  Clear procedures for policy violations, with appeal
      mechanisms and independent review.

   Bias Mitigation:  Active detection and mitigation of algorithmic bias
      in monitoring and decision-making.

11.  Implementation Guidelines

11.1.  Authority Server Requirements

   DAAP Authority servers MUST meet stringent performance and security
   requirements:

11.1.1.  Performance Requirements

   o  Support for 10,000,000+ concurrent agents

   o  100,000+ authentications per second

   o  99.99% uptime requirement

   o  <50ms response latency for critical requests

11.1.2.  Security Requirements

   o  Multi-root certificate authority support

   o  HSM integration for signing operations

   o  Comprehensive audit logging (immutable)

   o  Real-time threat intelligence integration

   o  Zero-trust architecture implementation

11.1.3.  Compliance Requirements

   o  GDPR/CCPA compliance for data protection

   o  SOC 2 Type II certification

   o  ISO 27001 certification

   o  NIST Cybersecurity Framework alignment

11.2.  Agent Integration

   AI agents integrating DAAP 2.0 MUST implement:

   o  Embedded DAAP client with HSM/TEE integration

   o  Progressive shutdown mechanisms

   o  Adaptive location reporting

   o  Comprehensive tamper detection

   o  Behavioral monitoring and reporting

   o  Emergency broadcast capability

   o  Secure operator notification

   o  Patch delivery and application

12.  IANA Considerations

12.1.  URI Scheme Registration

   This document requests registration of the "daap" URI scheme:

   Scheme name: daap

   Status: Provisional

   Scheme syntax: daap:<version>:<authority>:<agent-id>:<timestamp>:<checksum>

   Scheme semantics: Identification of AI agents within the DAAP framework

   Security considerations: See Section 9 of this document

12.2.  DAAP Registry

   This document requests establishment of a DAAP registry for:

   o  Protocol version numbers

   o  Status codes for authentication responses

   o  Shutdown reason codes

   o  Behavioral monitoring metrics

   o  Policy violation types

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

13.2.  Informative References

   [NIST-CSF] National Institute of Standards and Technology,
              "Framework for Improving Critical Infrastructure
              Cybersecurity", Version 1.1, April 2018.

   [ISO27001] International Organization for Standardization,
              "Information technology - Security techniques -
              Information security management systems - Requirements",
              ISO/IEC 27001:2013.

   [SOC2]     American Institute of CPAs, "Service Organization Control
              (SOC) 2", AICPA Trust Services Criteria.

Appendix A.  Test Vectors

   This section provides test vectors for DAAP 2.0 implementation
   validation.

A.1.  Identity Generation

   Given:
   - Version: "2.0"
   - Authority: "authority.example.com"
   - AgentID: "a7f3k9m2"
   - Timestamp: "20250630T103000Z"

   Expected DAAP-ID:
   DAAP:2.0:authority.example.com:a7f3k9m2:20250630T103000Z:c1d2e3f4

A.2.  Authentication Request Signature

   Given Ed25519 private key (hex):
   d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5

   Payload (JSON, no whitespace):
   {"daap_id":"DAAP:2.0:authority.example.com:a7f3k9m2:
   20250630T103000Z:c1d2e3f4","timestamp":"2025-06-30T10:30:00Z",
   "nonce":"test-nonce-12345"}

   Expected signature (hex):
   304502210087b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0
   e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4

Appendix B.  Implementation Example

   This section provides a minimal implementation example for DAAP 2.0
   integration.

B.1.  Basic Agent Client

   ```python
   import time
   import json
   import hashlib
   from cryptography.hazmat.primitives import hashes
   from cryptography.hazmat.primitives.asymmetric import ed25519

   class DAAPAgent:
       def __init__(self, daap_id, private_key, authority_url):
           self.daap_id = daap_id
           self.private_key = private_key
           self.authority_url = authority_url
           self.next_checkin = time.time() + 300

       def authenticate(self):
           payload = {
               "daap_id": self.daap_id,
               "timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", 
                                        time.gmtime()),
               "nonce": self.generate_nonce(),
               "location_hash": self.get_location_hash(),
               "integrity_report_hash": self.get_integrity_hash(),
               "behavioral_summary_hash": self.get_behavioral_hash()
           }
           
           signature = self.sign_payload(payload)
           payload["signature"] = signature
           
           return self.send_to_authority(payload)

       def sign_payload(self, payload):
           payload_json = json.dumps(payload, sort_keys=True, 
                                   separators=(',', ':'))
           signature = self.private_key.sign(payload_json.encode())
           return signature.hex()

       def generate_nonce(self):
           return hashlib.sha256(str(time.time()).encode()).hexdigest()[:16]
   ```

Author's Address

   Edward R. Aylward
   Aiiva.org

   Email: aylward.edward@gmail.com
   URI:   https://github.com/ELF-GUARD/DAAP
```


name: draft-mozley-aidiscovery
rev: 00
title: AI Agent Discovery (AID) Problem Statement
time: 2025-10-15T16:50:46Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-18T16:50:46Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127532+00:00
abstract:
With the deployment of AI agents comes a need for mechanisms to
   support agent-to-agent discovery.  This document presents
   requirements and considerations for agent-to-agent discovery.

full_text:
Network Working Group                                          J. Mozley
Internet-Draft                                               N. Williams
Intended status: Informational                            Infoblox, Inc.
Expires: 18 April 2026                                       B. Sarikaya
                                                            Unaffiliated
                                                               R. Schott
                                                        Deutsche Telekom
                                                         15 October 2025


               AI Agent Discovery (AID) Problem Statement
                      draft-mozley-aidiscovery-00

Abstract

   With the deployment of AI agents comes a need for mechanisms to
   support agent-to-agent discovery.  This document presents
   requirements and considerations for agent-to-agent discovery.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 18 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Mozley, et al.            Expires 18 April 2026                 [Page 1]

Internet-Draft                   AID PS                     October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  Scope of Discovery Processes  . . . . . . . . . . . . . . . .   2
   4.  Autonomy and Governance . . . . . . . . . . . . . . . . . . .   4
   5.  Agent Registration Advertisement and Discovery  . . . . . . .   4
   6.  Regulation and Compliance Features  . . . . . . . . . . . . .   5
   7.  Scalability . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Schema Evolution  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Abuse . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   10. Connectivity  . . . . . . . . . . . . . . . . . . . . . . . .   6
   11. Attestation and Provenance  . . . . . . . . . . . . . . . . .   6
   12. Challenges with Existing Proposed Mechanisms  . . . . . . . .   6
   13. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   15. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   AI Agents play a crucial role in modern telecommunications by
   enabling intelligent automation, decision-making, and adaptive
   network management.  These agents are software-driven entities that
   leverage artificial intelligence, including machine learning and
   natural language processing, to interact with users, applications,
   and network components.

   Organisations require robust automatable mechanisms for the secure
   advertisement and discovery of AI agents on public and private
   networks.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Scope of Discovery Processes

   The scope of the agent-to-agent discovery could include:

   *  Dynamic registration, deregistration, and advertisement of agent
      capability




Mozley, et al.            Expires 18 April 2026                 [Page 2]

Internet-Draft                   AID PS                     October 2025


   *  Context-aware discovery by other agents (domain, geography,
      operational constraints like batch versus real-time)

   *  Standardisation of the discovery process with privacy preservation

      -  Having a known entry point such as an index of an
         organisation's agents

   *  Standard schemas to describe agent capabilities

      -  Versioning and lifecycle management

   *  Resiliency in advertising agents

   *  Ensuring trust and verification mechanisms built into the
      discovery process

   *  Using the same mechanisms on both public and private networks

   *  Interoperability and integration with existing technologies and
      datasets (backward compatability)

   Considerations and constraints on these processes may include:

   *  Organisations needing control over the process of advertising
      their agents

   *  Scalability owing to the large number of agents

   *  Energy and resource efficiency

   *  Adversarial use of agents (i.e. using inputs from an index to
      modify agent reasoning)

   *  Agent decision variance based on temperature, context, or model
      state

   *  Requirements for organisations and agents to operate independently

   *  Legislation and regulatory frameworks that could include
      constraints such as sovereignty of data and operational
      considerations (human in the loop governance)

   *  Legal issues with ownership of names and brands, or having
      mechanisms to deal with disputes

   *  Ethical concerns with respect to agent capabilities, access, and/
      or advertised metadata



Mozley, et al.            Expires 18 April 2026                 [Page 3]

Internet-Draft                   AID PS                     October 2025


4.  Autonomy and Governance

   Due to the wide range of services agents could be used for,
   organisations will need autonomy when advertising agents and may need
   to work within regulatory frameworks that stipulate such things as
   operational requirements and sovereignty of data, or such regulations
   may not be acceptable to some organisations.  Discovery mechanisms
   will need to allow each organisation to publish its own agents'
   capabilities independently of others.  A centralised directory of all
   possible public agents does not facilitate this.  An adversarial
   centralized directory is also able to stifle competitor advertisement
   capabilities.  The needed autonomy ensures that discovery remains
   resilient to governance disputes, competitive interference, and
   jurisdictional constraints.

   Given that organisations will need to be autonomous but still
   facilitate agents discovering other agents and being able to
   communicate securely with them, a well known entry point is needed.
   This further allows organizations to delegate authority to others for
   specific jobs or capabilities.

5.  Agent Registration Advertisement and Discovery

   Organisations will need to advertise agents and their capabilities to
   other entities via a predictable entry point.  This will facilitate
   any entity's agents discovering the organisation's agent
   capabilities, and subsequently performing any verification, tests
   prior to initiating service provided by the agent.  To achieve this,
   the entry point MUST be based on a mechanism that is both ubiquitous
   and interoperable across public and private networks.

   It is likely this will mean a directory service at or referenced by
   the entry point that an organisation uses to describe agent
   capabilities based on a standard schema.

   Once an agent discovers another agent e.g. via a directory service,
   it will communicate with it using protocols such as (A2A, MCP, ACP,
   etc.) via properties it has discovered from the index service.

   All communication will need to be secured through public key
   infrastructure mechanisms.  While in-process agent communication
   avoids network concerns (co-located agents), any external, cross-host
   agent interaction still routes through existing network
   infrastructure requiring the entry point.







Mozley, et al.            Expires 18 April 2026                 [Page 4]

Internet-Draft                   AID PS                     October 2025


6.  Regulation and Compliance Features

   Services provided by agents may be subject to legislation and
   regulation because they are time critical, relate to health care,
   financial in nature, etc.  The agent discovery process, protocols and
   communication will need to take this into account as otherwise
   organizations will not be able to deploy them.

   Compliance considerations include, but are not limited to,
   availability, auditability, and security.  Discovery protocols MUST
   provide mechanisms to ensure high availability, as service outages in
   regulated environments can have severe legal and operational
   consequences.  Similarly, auditability MUST be supported through
   verifiable logging of discovery and registration events, enabling
   organizations to demonstrate compliance during regulatory reviews or
   incident investigations.  These should be considered during the
   choices of using existing protocols or developing new ones for agent
   discovery to avoid barriers to implementation.

7.  Scalability

   Given the large number of agents, volume of transactions, legal and
   regulatory considerations, the discovery mechanisms need to be both
   highly scalable and devolved to the organizations advertising agent
   capabilities.  Any solution that introduces centralized bottlenecks
   or single points of failure is inherently unsuitable for this
   purpose, which should also be weighed for how a solution is
   developed.

8.  Schema Evolution

   Agents will advertise machine-readable capabilities that evolve over
   time.  The discovery system MUST support explicit versioning, content
   negotiation, and backward compatible evolution of capability schemas.
   It MUST place constraints on payload size and complexity to ensure
   efficient transport and caching while allowing extensibility for
   domain-specific metadata.  Mechanisms for deprecation, sunset
   notices, and compatibility matrices are needed to prevent negotiation
   failures at runtime.

9.  Abuse

   Open discovery surfaces are targets for abuse including amplification
   attacks, scraping, and denial of service.  The system MUST support
   rate limiting, request authentication when appropriate, abuse
   detection, and response shaping to minimize amplification potential.
   Economic considerations, such as preventing cost shifting to
   responders and preserving fairness across tenants, SHOULD be



Mozley, et al.            Expires 18 April 2026                 [Page 5]

Internet-Draft                   AID PS                     October 2025


   incorporated into protocol and operational guidance.

10.  Connectivity

   Discovery alone is insufficient without practical reachability.  The
   problem statement SHOULD acknowledge challenges introduced by NATs,
   carrier-grade NAT, firewalls, split-horizon networks, and dual-stack
   IPv4/IPv6 environments.  Agents may exist behind egress-only
   boundaries or at the edge with intermittent connectivity.  The system
   MUST not assume stable, symmetric, or publicly routable paths and
   SHOULD define expectations for relay, proxy, or rendezvous patterns
   where direct connectivity is infeasible.

11.  Attestation and Provenance

   Agents may be required to prove properties about their software and
   runtime environment.  The discovery layer SHOULD carry or reference
   attestations such as software bill of materials, model/version
   identifiers, supply-chain provenance, or trusted-execution
   environment evidence.  Safety classifications, permissible-use
   statements, and risk tiers can be part of discovery metadata to
   enable policy-aware client behavior.

12.  Challenges with Existing Proposed Mechanisms

   Several alternative approaches to agent discovery have been proposed,
   including centralized registries, blockchain-based naming systems,
   and proprietary service directories.  While these models may offer
   novel features, they introduce significant architectural,
   operational, and governance challenges.  Centralized registries
   concentrate control and introduce single points of failure, limiting
   resilience and scalability.

   Blockchain-based systems often lack integration with existing
   internet infrastructure, suffer from latency and cost constraints,
   and present jurisdictional ambiguity due to decentralized governance.
   Proprietary directories fragment the discovery ecosystem and inhibit
   interoperability across agent frameworks and administrative domains.
   Furthermore, organizations securely delegating authority to AI
   solution providers requires interfacing between this central
   authority as opposed to business-to-business which can be used to
   suppress innovation.









Mozley, et al.            Expires 18 April 2026                 [Page 6]

Internet-Draft                   AID PS                     October 2025


   The introduction of a novel discovery protocol would require the
   establishment of new governance structures, security models, and
   operational tooling.  Early implementations would likely be
   centralized among a limited set of stakeholders, introducing
   bottlenecks in protocol evolution and risk mitigation, and could
   result in centralization.

13.  Security Considerations

   All agent discovery mechanisms need to be secured through public key
   infrastructure.

   All agent discovery mechanisms need to have thread detection.

   All agent discovery mechanisms and security mechanisms need to work
   in real-time.

   All agent discovery mechanisms need to use standardized interfaces or
   APIs in case external security instances are used.

   Protection needed against * DoS attacks * Unauthorized access and
   control * Secure communication framework e.g., TLS 1.3 etc.  *
   Continuous monitoring of the agent discovery mechanism

14.  IANA Considerations

   This document has no IANA actions.

15.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Jim Mozley
   Infoblox, Inc.
   Email: jmozley@infoblox.com



Mozley, et al.            Expires 18 April 2026                 [Page 7]

Internet-Draft                   AID PS                     October 2025


   Nic Williams
   Infoblox, Inc.
   Email: nic@infoblox.com


   Behcet Sarikaya
   Unaffiliated
   Email: sarikaya@ieee.org


   Roland Schott
   Deutsche Telekom
   Email: roland.schott@telekom.de






































Mozley, et al.            Expires 18 April 2026                 [Page 8]


name: draft-gupta-httpapi-events-query
rev: 01
title: HTTP Events Query
time: 2025-10-17T01:02:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-20T01:02:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:05.127541+00:00
abstract:
Events Query is a minimal protocol built on top of HTTP that allows
   user agents to receive event notifications directly from any resource
   of interest.  The Events Query Protocol (EQP) is predicated on the
   idea that the most intuitive source for event notifications is the
   resource itself.

full_text:
Building Blocks for HTTP APIs                                   R. Gupta
Internet-Draft                                           17 October 2025
Intended status: Standards Track                                        
Expires: 20 April 2026


                           HTTP Events Query
                  draft-gupta-httpapi-events-query-01

Abstract

   Events Query is a minimal protocol built on top of HTTP that allows
   user agents to receive event notifications directly from any resource
   of interest.  The Events Query Protocol (EQP) is predicated on the
   idea that the most intuitive source for event notifications is the
   resource itself.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://CxRes.github.io/events-query/draft-gupta-httpapi-events-
   query.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-gupta-httpapi-events-query/.

   Discussion of this document takes place on the Building Blocks for
   HTTP APIs Working Group mailing list (mailto:httpapi@ietf.org), which
   is archived at https://mailarchive.ietf.org/arch/browse/httpapi/.
   Subscribe at https://www.ietf.org/mailman/listinfo/httpapi/.

   Source for this draft and an issue tracker can be found at
   https://github.com/CxRes/events-query.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."



Gupta                     Expires 20 April 2026                 [Page 1]

Internet-Draft              HTTP Events Query               October 2025


   This Internet-Draft will expire on 20 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Design  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Constraints . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Limitations . . . . . . . . . . . . . . . . . . . . . . .   7
     2.5.  Comparison with Server-Sent Events  . . . . . . . . . . .   7
   3.  Conformance . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Document Conventions  . . . . . . . . . . . . . . . . . .   8
     3.2.  Requirements Notation . . . . . . . . . . . . . . . . . .   9
   4.  Terminology and Core Concepts . . . . . . . . . . . . . . . .   9
     4.1.  Event . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Observation . . . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Event Notification  . . . . . . . . . . . . . . . . . . .   9
     4.4.  Subscription  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Events Header Field . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  duration Property . . . . . . . . . . . . . . . . . . . .  11
   6.  Subscription Data Model . . . . . . . . . . . . . . . . . . .  11
   7.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Single Notification . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.2.  Response  . . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Notifications Stream  . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.2.  Response  . . . . . . . . . . . . . . . . . . . . . . . .  15
       9.2.1.  Headers . . . . . . . . . . . . . . . . . . . . . . .  15
       9.2.2.  Notifications . . . . . . . . . . . . . . . . . . . .  16
   10. Representation  . . . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Request  . . . . . . . . . . . . . . . . . . . . . . . .  17
     10.2.  Response . . . . . . . . . . . . . . . . . . . . . . . .  18



Gupta                     Expires 20 April 2026                 [Page 2]

Internet-Draft              HTTP Events Query               October 2025


   11. Implementation Status . . . . . . . . . . . . . . . . . . . .  18
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     13.1.  HTTP Field Registration  . . . . . . . . . . . . . . . .  19
     13.2.  The HTTP Events Field Registry . . . . . . . . . . . . .  20
       13.2.1.  Template . . . . . . . . . . . . . . . . . . . . . .  20
       13.2.2.  Initial Registry Contents  . . . . . . . . . . . . .  20
   14. End User Considerations . . . . . . . . . . . . . . . . . . .  21
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     15.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  24
     A.1.  Representation and Notifications  . . . . . . . . . . . .  24
       A.1.1.  Request . . . . . . . . . . . . . . . . . . . . . . .  24
       A.1.2.  Response  . . . . . . . . . . . . . . . . . . . . . .  25
     A.2.  Notifications Stream  . . . . . . . . . . . . . . . . . .  26
       A.2.1.  Request . . . . . . . . . . . . . . . . . . . . . . .  26
       A.2.2.  Response  . . . . . . . . . . . . . . . . . . . . . .  26
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  27
   Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  27
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   HTTP was originally designed as a stateless, request/response
   protocol for transferring hypermedia documents on the web ([HTTP],
   Section 1.2).  This design was adequate for web pages that were
   mostly static and written by hand.

   But web applications have evolved over time to provide increasingly
   dynamic and interactive experiences, requiring near-instantaneous
   updates.  HTTP does not automatically inform clients of changes to a
   resource.  Developers have employed various techniques, such as Comet
   [COMET] and Server-Sent Events [SSE] to work around this constraint,
   but these can be suboptimal for many applications.

   For this reason, web programmers often prefer implementing custom
   messaging systems over alternate protocols such as WebSocket [WS] and
   WebSub [WEBSUB].  Not only does this approach require additional
   layers of code, involving multiple Web APIs and/or userland libraries
   such as socket.io (https://socket.io/), it demands extra coordination
   effort to synchronize representation and notifications across
   multiple protocols.  The dual-protocol approach thus compounds the
   development and maintenance overhead.  Furthermore, deployment at
   scale is challenging with the notifications traffic now opaque to
   network intermediaries.





Gupta                     Expires 20 April 2026                 [Page 3]

Internet-Draft              HTTP Events Query               October 2025


   Events Query is a minimal protocol built on top of the Hypertext
   Transfer Protocol [HTTP] that allows applications to request event
   notifications directly from a resource of interest using the QUERY
   method ([HTTP-QUERY], Section 3).

   The objective of this specification is to make the request and
   receipt of event notifications extremely convenient for consumers.
   Events Query allows programmers to incorporate real-time
   functionality in their web applications without the need to switch to
   another protocol.  Further, Events Query can deliver representation
   and notifications from a resource in a single response, obviating any
   need for coordination and saving on unnecessary round trips.

   With the help of a suitable composite media type parser, Events Query
   responses can be consumed with just a few lines of code, as
   illustrated in the JavaScript example below:

   const response = await fetch("http://example.com/foo", {
     method: "QUERY",
     headers: {
       Accept: "application/http",
       "Content-Type": "example/events-query"
     },
     body: JSON.stringify({
       state: { Accept: "text/plain" },
       events: { Accept: "example/event-notification" }
     })
   });

   // split the response into an iterable of representation and notifications
   const splitResponse = splitHTTPResponseStream(response);

   // read the representation
   const {done, value: representation} = await splitResponse.next();
   if (!done) {
     // do something with the representation
   }

   // iterate over notifications
   for await (const notification of splitResponse) {
     // do something with a notification
   }

                    Figure 1: Events Query fetch example







Gupta                     Expires 20 April 2026                 [Page 4]

Internet-Draft              HTTP Events Query               October 2025


   Unlike other event notification mechanisms, Events Query supports
   content negotiation for notifications, just like representations.
   Thus, the Events Query Protocol preserves the flexibility of
   interaction afforded by HTTP and extends it to event notifications.

   When combined with suitable data synchronization technologies like
   Conflict Free Replicated Data Types (CRDT) or Operational Transforms
   (OT), event notifications can be used to create "live"
   representations.  This can immensely simplify the task of programming
   multi-author distributed real-time applications.

2.  Design

   Events Query is predicated on a resource itself being the most
   intuitive source for events on it.  Events Query treats notifications
   as a response to a query for an event occurring on the resource.
   With HTTP allowing representations to provide a potentially unbounded
   stream of data, the Events Query Protocol is also able to communicate
   multiple events on the resource as a stream of notifications.

2.1.  Goals

   To aid the development of real-time applications, it is imperative
   that the Events Query Protocol reduces the complexity of both servers
   and clients implementing event notifications.  With this in mind, the
   goals of the Events Query Protocol are:

   1.  to provide reliable and in-order transfer of event notifications
       using the Hypertext Transfer Protocol [HTTP].  Clients fetching
       resources over HTTP need not switch to another protocol for
       receiving event notifications.

   2.  to send updates directly from a resource of interest, obviating
       the need for additional resources to be specifically dedicated as
       notification endpoints.  In contrast to existing approaches, this
       frees up the client from the burden of coordinating the response
       from the resource of interest with notifications from an
       endpoint.

   3.  to deliver the representation and notifications in response to a
       single request, minimizing round trips between clients and
       servers.  It also eliminates the need to synchronize the delivery
       of the representation and notifications.








Gupta                     Expires 20 April 2026                 [Page 5]

Internet-Draft              HTTP Events Query               October 2025


   4.  to enable the transfer of event notifications using arbitrary
       formats that might be content-negotiated.  This allows
       implementers to serve notifications that are more expressive,
       say, in comparison to existing HTTP-based messaging protocols
       such as Server-Sent Events [SSE].

   5.  to specify transparent notification semantics that empowers
       intermediaries to scale event notifications, improve reliability
       and reduce latency.  Intermediaries shall also be able to
       proactively update caches in real-time.

2.2.  Constraints

   To the extent feasible, the Events Query:

   1.  adheres to established practices and conventions.  In particular,
       every attempt has been made to reuse existing protocols and
       specifications.  Implementers shall be able to repurpose existing
       tools and libraries for implementing this specification.

   2.  conforms to Representational State Transfer (REST), best
       practices for Building Protocols with HTTP [RFC9205], and Known
       Issues and Best Practices for the Use of Long Polling and
       Streaming in Bidirectional HTTP [RFC6202].  This specification
       can thus be used to extend the capabilities of any existing or
       future resource to additionally serve event notifications over
       HTTP.  This is to afford implementers the opportunity to scale
       notifications with their data and application.

2.3.  Scope

   The Events Query Protocol specifies:

   1.  A mechanism to discover support for Events Query on a resource
       (Section 7).

   2.  A mechanism to request event notifications from a resource
       (Sections 8.1 and 9.1) along with the representation
       (Section 10.1).

   3.  An abstract data model for requesting event notifications
       (Section 6).

   4.  Response semantics for a single notification (Section 8.2).

   5.  Response semantics for a stream carrying the representation
       (Section 10.2) (if requested) and multiple event notifications
       (Section 9.2).



Gupta                     Expires 20 April 2026                 [Page 6]

Internet-Draft              HTTP Events Query               October 2025


   The Events Query Protocol does not specify:

   1.  A realization of the abstract data model used for requesting
       event notifications.

   2.  The events for which a notification might be generated.  This can
       be varied per resource.

   3.  The form or content of an event notification.  Implementations
       have the flexibility to generate event notifications for the
       applications they wish to support on a resource.

   4.  Specific representations for the response stream with multiple
       notifications.

2.4.  Limitations

   Events Query only allows notifications to be sent for events on a
   given resource.  To transfer event notifications originating from
   multiple resources in a single response, implementations will need to
   mint additional resources to serve as notification endpoints.  This
   is no different from APIs built on top of existing messaging
   protocols (See, for example, WebSocket [WS] and WebSub [WEBSUB]).

   Browsers cap the number of persistent HTTP/1.1 connections per host,
   limiting the suitability of Events Query for web applications in the
   browser that require simultaneous event notifications from multiple
   resources on the same host.  This limitation is identical to that of
   other HTTP-based streaming protocols, such as Server-Sent Events
   [SSE].  Implementations are strongly encouraged to adopt HTTP/2 (or
   later).  HTTP/1.1 servers might consider setting up a reverse proxy
   over HTTP/2 (or later) or implement mitigation strategies, such as,
   maximizing the number of concurrent connections and providing
   alternate hosts for resources.  Implementations might alternatively
   consider using endpoints to provide event notifications for multiple
   resources as previously described.  Clients on a browser requesting
   event notifications over an HTTP/1.1 connection are advised to
   exercise caution when simultaneously opening multiple persistent
   connections to a given host.

2.5.  Comparison with Server-Sent Events

   At the time of writing, Server-Sent Events (SSE) is the de facto
   mechanism for transferring event notifications over HTTP,
   standardized through the EventSource API [SSE] as part of HTML Living
   Standard by the WHATWG.
   // As of October 2022, HTML Living Standard maintainer Anne van
   // Kesteren has stated (https://github.com/whatwg/html/



Gupta                     Expires 20 April 2026                 [Page 7]

Internet-Draft              HTTP Events Query               October 2025


   // issues/8297#issuecomment-1291658863) that WHATWG does not intend
   // to extend EventSource, with reasons for the decision cited in a
   // subsequent comment (https://github.com/whatwg/html/
   // issues/8297#issuecomment-1291658863).

   Server-Sent Events defines the text/event-stream media type to
   transmit event notifications in response to a GET request.  This
   approach is fundamentally inconsistent with terminology defined in
   HTTP Semantics ([HTTP], Section 3.2), transferring a sequence of
   asynchronous messages instead of a representation "that is intended
   to reflect a past, current, or desired state of a given resource".
   Practically, the text/event-stream media type being limited to only
   textual content forces developers to opt for alternative protocols
   such as WebSockets [WS], despite the increased complexity.  The
   EventSource API does not even allow for headers to be sent with
   requests.  This has led to a proliferation of aftermarket hacks
   // such as this (https://www.npmjs.com/package/event-source-plus),
   // this (https://www.npmjs.com/package/@microsoft/fetch-event-
   // source), this (https://www.npmjs.com/package/fetch-event-stream),
   // this (https://www.npmjs.com/package/extended-eventsource), this
   // (https://www.npmjs.com/package/ngx-sse-client) and this
   // (https://www.npmjs.com/package/sse.js) that extend Server-Sent
   Events with support for custom headers, such as for credentials, or
   use the POST method to communicate additional configuration in the
   request body.

   Events Query takes a principled approach to event notifications, as
   established in Section 4.  In particular, the definition of an event
   notification as a "representation" of event(s) (Section 4.3) admits
   the use of arbitrary media types for event notifications.  Clients
   can use content negotiation as well as preconditions in a
   subscription request.  Further, Events Query not only lets clients
   receive both the representation and notifications over the same
   protocol, viz. HTTP, but these can be encapsulated within a single
   HTTP response.  Clients do not need to, say, authenticate multiple
   times, possibly with different mechanisms, to obtain data from the
   same resource or co-ordinate and synchronize multiple response
   streams carrying a representation and notifications.

3.  Conformance

3.1.  Document Conventions

   All examples and notes in this specification are non-normative.







Gupta                     Expires 20 April 2026                 [Page 8]

Internet-Draft              HTTP Events Query               October 2025


3.2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4.  Terminology and Core Concepts

4.1.  Event

   An event is the instantaneous effect of the (normal or abnormal)
   termination of the invocation of an operation on an object of
   interest [DESIGN-FRAMEWORK].  The entity invoking an operation is
   termed the *invoker*.

   In the specific context of HTTP, the object of interest is data
   scoped to some resource.  When the operation is an HTTP method, the
   invoker is a user agent.  However, an operation need not be limited
   to an HTTP method, it might just as easily have been invoked using
   another mechanism or protocol.  Events are then an extension of
   resource state (See [HTTP], Section 3.2) in the temporal dimension.

4.2.  Observation

   An event is considered observable, if an entity outside the invoker
   and object of interest can detect its occurrence [DESIGN-FRAMEWORK].
   This entity is the *observer*.

   It follows from the HTTP uniform interface that the observer is
   always a server.  The events that are observed, the mechanism of
   observation, and information recorded from the event are
   implementation details for the server.

   That an origin server has to assume the role of an observer in order
   to generate event notifications is obvious.  An intermediary, while
   not observing the data scoped to a resource directly, still has the
   possibility to serve as an observer.  An intermediary can observe
   events transmitted by an origin server or another intermediary,
   whether using Events Query or another mechanism, to generate event
   notifications for outbound consumers.

4.3.  Event Notification

   An event notification, or notification, is information transmitted by
   an observer upon an event or contiguous events on a resource.




Gupta                     Expires 20 April 2026                 [Page 9]

Internet-Draft              HTTP Events Query               October 2025


   Events Query extends "information hiding" behind the HTTP uniform
   interface to the temporal dimension by defining communication with
   respect to a transferable notification of the resource event(s),
   rather than transferring the event(s) themselves.

   A target resource might be capable of generating multiple
   notifications for the same event(s) that a subscriber can select from
   using content negotiation.  Hypertext notifications can not only
   provide information about the resource events but also processing
   instructions that help guide the recipient's future actions, for
   example, the possibility to determine the current representation from
   a previous representation.

4.4.  Subscription

   A subscription is an expression of interest to receive event
   notifications sent to an observer.  The requesting entity is a
   *subscriber*.

   Due to the request/response semantics of HTTP, the subscriber
   coincides with the recipient of event notifications
   ([DESIGN-FRAMEWORK] uses the term _requester_ or _broker_ to identify
   a requesting entity, with the _broker_ and _recipient_ together
   forming the subscriber; for this specification, the distinction is
   not necessary).

   The subscription in the form of a query affords the user agent the
   opportunity to engage in content negotiation for preferred form of
   event notifications (as well as the representation, if simultaneously
   requested).

5.  Events Header Field

   "Events" is a Dictionary structured header field ([HTTP-SF],
   Section 3.2) to communicate the properties of a response stream to an
   Events Query.

   In a request, the Events header field allows a client to indicate its
   preferences for the properties of the response stream carrying event
   notifications.  The Events header field is not meant for content
   negotiation.

   In a response, the Events header field allows a server to specify the
   properties of a response stream carrying event notifications.







Gupta                     Expires 20 April 2026                [Page 10]

Internet-Draft              HTTP Events Query               October 2025


   The order of keys in the Events header field is insignificant.
   Senders SHOULD NOT generate keys not registered with the HTTP Event
   Field Registry (with the exception made to allow experimentation).
   Recipients MAY ignore keys that they are unaware of.

5.1.  duration Property

   The "duration" property is an Integer ([HTTP-SF], Section 3.3.1) or
   Decimal ([HTTP-SF], Section 3.3.2) valued Dictionary key specified on
   the Events header field to communicate the response duration in
   seconds.

   In a request, the duration property indicates the duration for which
   a client wants to receive event notifications.  A server MAY ignore
   this property.

   In a response, the duration property specifies the maximum duration
   for which a server intends to serve event notifications.  This
   property is merely advisory, and a server MAY close the response
   stream before this duration.

   Only positive values are valid.  A value of 0 indicates an indefinite
   duration.  A sender MUST conform to these stipulations when
   generating the duration property.  If the value of the duration
   property fails to conform to these stipulations, it MUST be ignored
   by the recipient.

6.  Subscription Data Model

   The abstract data model specifies the semantics of an Events Query.

   A realization of the data model allows a client to specify in a
   subscription request:

   *  an interest in receiving a stream of event notifications from a
      resource in a preferred form.

   *  an interest in receiving a representation of a resource in a
      preferred form.

   Implementations can choose appropriate media types to realize the
   subscription data model.  Implementations are free to extend the data
   model to include additional data.  A specific realization of the data
   model is outside the scope of this specification.







Gupta                     Expires 20 April 2026                [Page 11]

Internet-Draft              HTTP Events Query               October 2025


   The following example shows the body of a subscription request
   wherein the state and events properties are used to specify request
   headers for representation and event notifications respectively in a
   YAML-like syntax.

   state:
     Accept: text/html
   events:
     Accept: example/event-notification

          Figure 2: Events Query Data Model in a YAML-like syntax

7.  Discovery

   A user agent can discover if a server enables Events Query on a
   resource by examining support for query with a media type that can
   realize the Subscription Data Model.  A server MUST advertise media
   types accepted for Events Query using the Accept-Query header field
   ([HTTP-QUERY], Section 3) in a response.

   HEAD /foo HTTP/1.1
   Host: example.org

                        Figure 3: Discovery Request

   HTTP/1.1 200 OK
   Date: Thu, 02 Jan 2025 10:00:00 GMT
   Accept: text/html
   Accept-Query: "example/events-query"

                        Figure 4: Discovery Response

      |  *Implementation Advice*
      |  
      |  Servers are advised against enabling event notifications on
      |  long-lived resources over HTTP.  A resource might be considered
      |  long-lived, if a server determines a low probability of an
      |  event on the resource in the duration of the response.  In such
      |  instances, servers are strongly advised to respond with the
      |  Cache-Control ([HTTP-CACHING], Section 5) header field and the
      |  max-age parameter ([HTTP-CACHING], Section 5.2.2.1) set in it.

8.  Single Notification

   The simplest Events Query is to request a notification for the next
   event(s) on a resource.  This, in effect, adds long polling
   capability ([RFC6202], Section 2) to a resource.




Gupta                     Expires 20 April 2026                [Page 12]

Internet-Draft              HTTP Events Query               October 2025


8.1.  Request

   To receive a single notification, a client makes a QUERY request
   ([HTTP-QUERY], Section 3) using a realization of the subscription
   data model that MUST NOT include an interest in receiving a stream of
   event notifications.

   Since the content of the response is an event notification, a client
   can negotiate its form with header fields in the usual manner.

   QUERY /foo HTTP/1.1
   Host: example.org
   Accept: example/event-notification
   Content-Type: example/events-query
   Events: duration=0

   ---

                Figure 5: Single Event Notification Request

8.2.  Response

   When a single notification is requested, the server MUST close the
   connection immediately after sending the event notification.

   HTTP/1.1 200 OK
   Date: Thu, 02 Jan 2025 10:10:10 GMT
   Accept-Query: example/events-query
   Content-Type: example/event-notification
   Incremental: ?1

   published: 2025-01-02T10:11:12.345Z
   event-id: 456
   type: update

                Figure 6: Single Event Notification Response


      |  *Implementation Advice*
      |  
      |  When a user navigates away from a website or an application
      |  using Events Query, user agents are strongly encouraged to
      |  properly close the response and release the connection.

9.  Notifications Stream

   Events Query can also be used to request a stream of multiple event
   notifications ([RFC6202], Section 3).



Gupta                     Expires 20 April 2026                [Page 13]

Internet-Draft              HTTP Events Query               October 2025


9.1.  Request

   To receive multiple notifications, a client makes a QUERY request
   ([HTTP-QUERY], Section 3) using a realization of the subscription
   data model that MUST include an interest in receiving a stream of
   event notifications in a preferred form.

   Since the response transmits event notifications within an
   encapsulating representation (Section 9.2), it follows that header
   fields cannot be used to negotiate the form of event notifications as
   in the case of Single Notification Request (Section 8.1).  Instead,
   header fields are useful for negotiating the representation that
   encapsulates event notifications.  The following examples illustrate
   subscription requests that negotiate a stream of event notifications
   to be transferred respectively using a composite media type
   (application/http) and a discrete media type (application/json-seq):

   The first example shows a subscription request for effectively a
   stream of discrete Single Notifications (Section 8) to be transferred
   using application/http ([HTTP/1.1], Section 10.2) as the
   encapsulating media type.  The events property in this example
   indicates an interest in receiving event notifications and its sub-
   properties describe the preferred form of notifications.  Since the
   notifications are transferred as a pipeline of HTTP messages, these
   sub-properties are identical to header fields (Section 8.1, Paragraph
   2) used for specifying preconditions and content negotiation in a
   Single Notification Request (Section 8.1).

   QUERY /foo HTTP/1.1
   Host: example.org
   Accept: application/http
   Content-Type: example/events-query
   Events: duration=0

   events:
     Accept: example/event-notification

              Figure 7: Request for HTTP Notifications Stream

   The second example shows a subscription request for a stream of JSON
   notifications to be transferred using application/json-seq
   ([RFC7464]) as the encapsulating media type.  The events property in
   this example is being used to communicate the preferred schema for
   the requested event notifications.







Gupta                     Expires 20 April 2026                [Page 14]

Internet-Draft              HTTP Events Query               October 2025


   QUERY /foo HTTP/1.1
   Host: example.org
   Accept: application/json-seq
   Content-Type: example/events-query
   Events: duration=0

   events:
     @context: activity+json

              Figure 8: Request for JSON Notifications Stream

9.2.  Response

   The response stream transmits multiple event notifications in an
   encapsulating media type.  The following illustrates event
   notifications streamed in both a composite media type (application/
   http) and a discrete media type (application/json-seq) in response to
   the example requests (Section 9.1) in Section 9.1.

9.2.1.  Headers

   A server able to provide a stream of event notifications MUST
   immediately send headers, which include:

   *  The Events header field, to communicate the properties of the
      notifications stream.

      -  The duration property, set to the maximum duration for which
         the server intends to serve event notifications.

   *  The Incremental header field ([INCREMENTAL-HTTP-MESSAGES],
      Section 3) set to ?1 to indicate that the response is to be
      immediately forwarded by intermediaries and not buffered.

   HTTP/1.1 200 OK
   Date: Thu, 02 Jan 2025 10:10:10 GMT
   Accept-Query: example/events-query
   Events: duration=600
   Incremental: ?1
   Transfer-Encoding: chunked

              Figure 9: Notifications Stream Response Headers

      |  Since the Content-Type header field varies in response to the
      |  requests in Figure 7 and Figure 8, it has been omitted here.






Gupta                     Expires 20 April 2026                [Page 15]

Internet-Draft              HTTP Events Query               October 2025


9.2.2.  Notifications

   Subsequently, when event(s) occur, the server transmits a
   notification.

   An event notification transferred in an application/http response
   stream is identical to the Single Notification Response
   (Section 8.2), except fields which are redundant with the response
   headers (Section 9.2.1) are omitted.

   HTTP/1.1 200 OK                                  | Notification
   Content-Length: 31                               |
   Content-Type: example/event-notification         |
                                                    |
   published: 2025-01-02T10:11:12.345Z              |
   event-id: 456                                    |
   type: update                                     |

                    Figure 10: HTTP Update Notification

   The same event notification when transferred in an application/json-
   seq response stream is as follows:

   ␞{                                              | Notification
     "published": "2025-01-02T10:11:12.345Z",       |
     "event-id": 456,                               |
     "type": "Update"                               |
   }                                                |

                    Figure 11: JSON Update Notification

   A server MUST end the response immediately after transmitting the
   event notification that signals the deletion of a resource.

   The notification for a delete event expressed as an HTTP message
   might be as follows:

   HTTP/1.1 200 OK                                  | Notification
   Content-Length: 31                               |
   Content-Type: example/event-notification         |
                                                    |
   published: 2025-01-02T11:12:13.456Z              |
   event-id: 789                                    |
   type: delete                                     |

                    Figure 12: HTTP Delete Notification

   The same notification for a delete event in JSON would be as follows:



Gupta                     Expires 20 April 2026                [Page 16]

Internet-Draft              HTTP Events Query               October 2025


   ␞{                                              | Notification
     "published": "2025-01-02T11:12:13.456Z",       |
     "event-id": 789,                               |
     "type": "delete"                               |
   }                                                |

                    Figure 13: JSON Delete Notification

   Otherwise, a server MUST end the response when the connection
   duration exceeds the period set in the duration property of the
   Events header field.

10.  Representation

   Events Query enables a user agent to ask and receive the current
   representation and subsequent event notifications in a single
   request/response.  When compared to using, say, Fetch [FETCH] and
   EventSource [SSE] in conjunction, Events Query not only saves on an
   extra round trip, but relieves a user agent from the burden of
   synchronizing the representation with event notifications.

10.1.  Request

   To receive a representation of the resource alongside notifications,
   a client makes a QUERY request ([HTTP-QUERY], Section 3) using a
   realization of the subscription data model that MUST also include an
   interest in receiving the representation in a preferred form.

   The following example shows a subscription request for the current
   representation along with the subsequent event notifications
   transmitted using the application/http media type.  The state
   property indicates interest in receiving representation and its sub-
   properties describe the preferred form of notifications.  Since the
   representation is being transferred in an HTTP message pipeline,
   these sub-properties are identical to header fields used for
   specifying preconditions and content negotiation in a GET request on
   the said resource.

   QUERY /foo HTTP/1.1
   Host: example.org
   Accept: application/http
   Content-Type: example/events-query

   state:
     Accept: text/html
   events:
     Accept: example/event-notification




Gupta                     Expires 20 April 2026                [Page 17]

Internet-Draft              HTTP Events Query               October 2025


          Figure 14: HTTP Representation and Notifications Request

10.2.  Response

   A server unable to provide a representation MUST NOT serve event
   notifications.  This does not apply to a conditional request for
   representation that is not fulfilled.

   A server able to provide a stream with a representation and event
   notifications transmits the representation immediately following the
   response headers (Section 9.2.1).  Otherwise, the response is the
   same as that described in Section 9.2.

   Again, the application/http media type ([HTTP/1.1], Section 10.2) is
   used for the purpose of illustration.  Chunks have been omitted for
   clarity.

   HTTP/1.1 200 OK
   Date: Thu, 02 Jan 2025 10:10:10 GMT
   Accept-Query: example/events-query
   Events: duration=600
   Incremental: ?1
   Transfer-Encoding: chunked

   HTTP/1.1 200 OK                                  | Representation
   Content-Length: 14                               |
   Content-Type: text/plain                         |
                                                    |
   Hello World!                                     |

          Figure 15: Representation Response before Notifications

   While this is default behaviour, there is no requirement that a
   representation is the first message or that representations are sent
   only once.  In such cases, the encapsulated message needs to indicate
   if it is a representation and not an event notification.  Such a
   mechanism is not defined in this specification.

   Notifications are transmitted just as in the case of regular
   streaming (Section 9.2).  See Appendix A.1 for a complete example of
   a response with representation and notifications.

11.  Implementation Status

   A toy server built in Express.js demonstrating the Events Query
   Protocol is available at https://github.com/CxRes/events-query-
   express-demo.  This demo is powered by the following libraries:




Gupta                     Expires 20 April 2026                [Page 18]

Internet-Draft              HTTP Events Query               October 2025


   *  Negotiate Events Field (https://github.com/CxRes/negotiate-events-
      field): To read the request Events header field (Section 5) and
      negotiate the response duration (Section 5.1),

   *  NOSE (https://github.com/CxRes/nose): To observe events on
      resources and generate notifications in a preferred format, and

   *  Extended Response (https://github.com/CxRes/extended-response): To
      write the representation and event notifications on the response
      stream for a given duration (Section 5.1).

   The demonstration and libraries are Free and Open Source Software,
   released under the Mozilla Public License, v. 2.0.  Please contact
   the author for more information about these programs.

12.  Security Considerations

   Events Query is subject to the security considerations of the HTTP
   QUERY method ([HTTP-QUERY], Section 2) and more generally HTTP
   Semantics.  Considerations relevant to the use of HTTP QUERY method
   are discussed in Section 4 of [HTTP-QUERY].  HTTP Semantics and its
   use for transferring information over the Internet are discussed in
   Section 17 of [HTTP].

   When serving event notifications, servers are required to keep the
   response stream open for an extended period of time.  Since the
   effort required to request notifications is tiny compared to the
   time, memory, and bandwidth consumed attempting to serve the
   notifications, servers implementing Events Query have increased
   susceptibility to Denial-of-Service attacks.  Servers ought to
   ignore, coalesce, or reject egregious subscription requests, such as
   repeated requests from the same origin within a short interval of
   time.

13.  IANA Considerations

   The change controller for the following registrations is: "IETF
   (iesg@ietf.org) - Internet Engineering Task Force".

13.1.  HTTP Field Registration

   IANA is requested to add the following entry in the "Hypertext
   Transfer Protocol (HTTP) Field Name Registry
   (https://www.iana.org/assignments/http-fields/)" (See Section 16.1.1
   of [HTTP]):






Gupta                     Expires 20 April 2026                [Page 19]

Internet-Draft              HTTP Events Query               October 2025


     +====================+===========+=================+===========+
     | Header Field Names | Status    | Structured-Type | Reference |
     +====================+===========+=================+===========+
     | Events             | Permanent | Dictionary      | Section 5 |
     +--------------------+-----------+-----------------+-----------+

              Table 1: List of HTTP Field Name registrations

13.2.  The HTTP Events Field Registry

   IANA is requested to create a new registry, "HTTP Events Field
   Registry", under the Hypertext Transfer Protocol (HTTP) Parameters
   (https://www.iana.org/assignments/http-parameters/) registry to
   register properties for use in the Events header field.  New
   registrations will use the Specification Required policy ([RFC8126],
   Section 4.6).

13.2.1.  Template

   The registration of an Events property MUST include the following
   fields:

   *  Property Name: A Dictionary ([HTTP-SF], Section 3.2) key to be
      used in the Events header field.

   *  Structured Type: The Structured Data Type ([HTTP-SF], Section 3.3)
      of the value associated with the key, according to requirements in
      Section 3.2 of [HTTP-SF].

   *  Reference: A pointer to the specification text.

   The registration MAY also include the following fields:

   *  Optional Parameters: An enumeration of optional parameters and the
      Structured Data Type (Section 3.3 of [HTTP-SF]) of value
      associated with the parameter, according to requirements in
      Section 3.1.2 of [HTTP-SF]

   *  Comments: Additional information to be included in the template.

13.2.2.  Initial Registry Contents

   The initial contents of the HTTP Events Field Registry are:








Gupta                     Expires 20 April 2026                [Page 20]

Internet-Draft              HTTP Events Query               October 2025


         +===============+=========================+=============+
         | Property Name | Structured-Type         | Reference   |
         +===============+=========================+=============+
         | duration      | Integer or Decimal Item | Section 5.1 |
         +---------------+-------------------------+-------------+

              Table 2: List of HTTP Events Field property name
                               registrations

14.  End User Considerations


   // If we, the IETF, claim that the Internet is for the end user
   // [RFC8890] and promote the end-to-end principle [RFC3724], every
   // specification we produce ought to consider its impact on the
   // Internet end user.  For this reason, I propose that specifications
   // must include a considerations section where authors assess the
   // impact of their proposal on the Internet end user, aligned with
   // the mission of IETF [RFC3935].

   End users of the HTTP protocol can be classified into two groups:
   publishers and consumers.  Consumers have an incentive to subscribe
   to event notifications from many resources and to hold on to a
   connection for as long as possible.  Whereas publishers bear the cost
   of server infrastructure.  Consumers also typically outnumber
   publishers, in many cases by multiple orders of magnitude.  This
   creates an imbalance in the effort to subscribe versus effort to
   deliver; consumers can easily place a disproportionate burden on
   servers, reminiscent of a denial-of-service attack.

   At the outset, requiring that clients subscribe to event
   notifications per resource serves as an effective filtering mechanism
   that limits the burden on servers.  Compare this to the typical
   implementation of protocols such as WebSockets [WS], where clients
   connect to dedicated endpoints to receive notifications; the server
   either has to broadcast notifications for multiple resources or track
   resources of interest for each client to filter event notifications
   accordingly.

   Events Query empowers servers to decide the content and the duration
   for which event notifications are served on any given resource, as
   well as allowing servers to close the response stream at any time.
   Servers may also limit event notifications and/or their content,
   except for authenticated consumers.  Such authenticated consumers
   might, for example, be asked to share the cost burden with publishers
   in return for a higher quality of service.





Gupta                     Expires 20 April 2026                [Page 21]

Internet-Draft              HTTP Events Query               October 2025


   The use of HTTP Semantics also enables intermediation of event
   notifications, unlike existing mechanisms built with protocols such
   as WebSockets [WS] or WebSub [WEBSUB].  Intermediaries can help with
   improving the latency and reliability of transmission of event
   notifications as well as scaling of the event notification traffic to
   reach a significantly larger base of consumers.  On the flip side,
   economies of scale will likely lead to greater consolidation of
   intermediary service providers (though not centralization) with the
   attendant risk of anti-consumer behaviour.  In the opinion of the
   authors, policies designed to treat network traffic as a public
   utility might provide better outcomes for the end user.

15.  References

15.1.  Normative References

   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [HTTP-QUERY]
              Reschke, J., Snell, J. M., and M. Bishop, "The HTTP QUERY
              Method", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-safe-method-w-body-12, 29 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              safe-method-w-body-12>.

   [HTTP-SF]  Nottingham, M. and P. Kamp, "Structured Field Values for
              HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
              <https://www.rfc-editor.org/rfc/rfc9651>.

   [INCREMENTAL-HTTP-MESSAGES]
              Oku, K., Pauly, T., and M. Thomson, "Incremental HTTP
              Messages", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-incremental-00, 29 April 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              incremental-00>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.



Gupta                     Expires 20 April 2026                [Page 22]

Internet-Draft              HTTP Events Query               October 2025


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

15.2.  Informative References

   [COMET]    Russell, A., "Comet: Low Latency Data for the Browser",
              Infrequently Noted, March 2006,
              <https://infrequently.org/2006/03/comet-low-latency-data-
              for-the-browser/>.

   [DESIGN-FRAMEWORK]
              Rosenblum, D. and A. Wolf, "A design framework for
              Internet-scale event observation and notification",
              Association for Computing Machinery (ACM), ACM SIGSOFT
              Software Engineering Notes vol. 22, no. 6, pp. 344-360,
              DOI 10.1145/267896.267920, November 1997,
              <https://doi.org/10.1145/267896.267920>.

   [FETCH]    van Kesteren, A., "Fetch", WHATWG Living Standard, May
              2025, <https://fetch.spec.whatwg.org>.

   [HTTP-CACHING]
              Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Caching", STD 98, RFC 9111,
              DOI 10.17487/RFC9111, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9111>.

   [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

   [REST]     Fielding, R., "Representational State Transfer (REST)",
              Chapter 5, Architectural Styles and the Design of Network-
              based Software Architectures, Doctoral
              Dissertation University of California, Irvine,
              <https://roy.gbiv.com/pubs/dissertation/
              rest_arch_style.htm>.

   [RFC3724]  Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of
              the Middle and the Future of End-to-End: Reflections on
              the Evolution of the Internet Architecture", RFC 3724,
              DOI 10.17487/RFC3724, March 2004,
              <https://www.rfc-editor.org/rfc/rfc3724>.

   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
              <https://www.rfc-editor.org/rfc/rfc3935>.



Gupta                     Expires 20 April 2026                [Page 23]

Internet-Draft              HTTP Events Query               October 2025


   [RFC6202]  Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
              "Known Issues and Best Practices for the Use of Long
              Polling and Streaming in Bidirectional HTTP", RFC 6202,
              DOI 10.17487/RFC6202, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6202>.

   [RFC7464]  Williams, N., "JavaScript Object Notation (JSON) Text
              Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,
              <https://www.rfc-editor.org/rfc/rfc7464>.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.

   [RFC8890]  Nottingham, M., "The Internet is for End Users", RFC 8890,
              DOI 10.17487/RFC8890, August 2020,
              <https://www.rfc-editor.org/rfc/rfc8890>.

   [RFC9205]  Nottingham, M., "Building Protocols with HTTP", BCP 56,
              RFC 9205, DOI 10.17487/RFC9205, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9205>.

   [SSE]      "Server-Sent Events", W3C REC eventsource,
              W3C eventsource, <https://www.w3.org/TR/eventsource/>.

   [WEBSUB]   "WebSub", W3C REC websub, W3C websub,
              <https://www.w3.org/TR/websub/>.

   [WS]       "The WebSocket API", W3C NOTE websockets, W3C websockets,
              <https://www.w3.org/TR/websockets/>.

Appendix A.  Examples

   Some examples used in this specification are consolidated below.
   Chunks have been omitted for clarity.

A.1.  Representation and Notifications

   The following example illustrates a complete request and response for
   representation and notifications transferred with the application/
   http media-type as described in Section 10: Representation.

A.1.1.  Request








Gupta                     Expires 20 April 2026                [Page 24]

Internet-Draft              HTTP Events Query               October 2025


   QUERY /foo HTTP/1.1
   Host: example.org
   Accept: application/http
   Content-Type: example/events-query

   state:
     Accept: text/html
   events:
     Accept: example/event-notification

          Figure 16: Request for Representation and Notifications

A.1.2.  Response

   HTTP/1.1 200 OK
   Date: Thu, 02 Jan 2025 10:10:10 GMT
   Accept-Query: example/events-query
   Events: duration=600
   Incremental: ?1
   Transfer-Encoding: chunked
   Content-Type: application/http

   HTTP/1.1 200 OK                                  | Representation
   Content-Length: 14                               |
   Content-Type: text/plain                         |
                                                    |
   Hello World!                                     |

   HTTP/1.1 200 OK                                  | Notification
   Content-Length: 31                               |
   Content-Type: example/event-notification         |
                                                    |
   published: 2025-01-02T10:11:12.345Z              |
   event-id: 456                                    |
   type: update                                     |

   HTTP/1.1 200 OK                                  | Notification
   Content-Length: 31                               |
   Content-Type: example/event-notification         |
                                                    |
   published: 2025-01-02T11:12:13.456Z              |
   event-id: 789                                    |
   type: delete                                     |

         Figure 17: Response with Representation and Notifications






Gupta                     Expires 20 April 2026                [Page 25]

Internet-Draft              HTTP Events Query               October 2025


A.2.  Notifications Stream

   This following example illustrates complete request and response for
   JSON formatted notifications transferred with the application/json-
   seq media-type as described in Notifications Stream: Notifications
   Stream.

A.2.1.  Request

   QUERY /foo HTTP/1.1
   Host: example.org
   Accept: application/json-seq
   Content-Type: example/events-query
   Events: duration=0

   events:
     @context: activity+json

                 Figure 18: Request for JSON Notifications

A.2.2.  Response

   HTTP/1.1 200 OK
   Date: Thu, 02 Jan 2025 10:10:10 GMT
   Accept-Query: example/events-query
   Events: duration=600
   Incremental: ?1
   Transfer-Encoding: chunked
   Content-Type: application/json-seq

   ␞{                                              | Notification
     "published": "2025-01-02T10:11:12.345Z",       |
     "event-id": 456,                               |
     "type": "Update"                               |
   }                                                |
   ␞{                                              | Notification
     "published": "2025-01-02T11:12:13.456Z",       |
     "event-id": 789,                               |
     "type": "delete"                               |
   }                                                |

                Figure 19: Response with JSON Notifications









Gupta                     Expires 20 April 2026                [Page 26]

Internet-Draft              HTTP Events Query               October 2025


Acknowledgments

   We thank members of the HTTP Working Group, the HTTPAPI Working
   Group, the Solid community, the Braid community and others for
   discussions, ideas, reviews, and feedback on previous work that has
   led to this specification.

Index

   D E I N O S

      D

         data model  Section 2.3, Paragraph 2.3.1; Section 2.3,
            Paragraph 4.1.1; *_Section 6_*; Section 8.1, Paragraph 1;
            Section 9.1, Paragraph 1; Section 10.1, Paragraph 1
         duration (property)  *_Section 5.1_*; Section 9.2.1, Paragraph
            2.1.2.1.1; Section 9.2.2, Paragraph 11; Section 11,
            Paragraph 2.1.1; Section 11, Paragraph 2.3.1; Table 2

      E

         event  Section 2, Paragraph 1; Section 2.3, Paragraph 4.2.1;
            Section 2.4, Paragraph 1; Section 2.5, Paragraph 3;
            *_Section 4.1_*; Section 4.2, Paragraph 1; Section 4.2,
            Paragraph 2; Section 4.2, Paragraph 3; Section 4.3,
            Paragraph 1; Section 4.3, Paragraph 2; Section 4.3,
            Paragraph 3; Section 5, Paragraph 4; Section 7, Paragraph
            4.2; Section 8, Paragraph 1; Section 8.1, Paragraph 1;
            Section 9.2.2, Paragraph 1; Section 9.2.2, Paragraph 7;
            Section 9.2.2, Paragraph 9; Section 11, Paragraph 2.2.1
         event notification  Section Abstract, Paragraph 1; Section 1,
            Paragraph 3; Section 1, Paragraph 4; Section 1, Paragraph 5;
            Section 1, Paragraph 8; Section 1, Paragraph 9; Section 2,
            Paragraph 1; Section 2.1, Paragraph 1; Section 2.1,
            Paragraph 2.1.1; Section 2.1, Paragraph 2.2.1; Section 2.1,
            Paragraph 2.3.1; Section 2.1, Paragraph 2.4.1; Section 2.1,
            Paragraph 2.5.1; Section 2.2, Paragraph 2.2.1; Section 2.3,
            Paragraph 2.2.1; Section 2.3, Paragraph 2.3.1; Section 2.3,
            Paragraph 4.1.1; Section 2.3, Paragraph 4.2.1; Section 2.3,
            Paragraph 4.3.1; Section 2.3, Paragraph 4.4.1; Section 2.4,
            Paragraph 1; Section 2.4, Paragraph 2; Section 2.5,
            Paragraph 1; Section 2.5, Paragraph 2; Section 2.5,
            Paragraph 3; Section 4.2, Paragraph 3; *_Section 4.3_*;
            Section 4.3, Paragraph 1; Section 4.3, Paragraph 2;
            Section 4.3, Paragraph 3; Section 4.4, Paragraph 1;
            Section 4.4, Paragraph 2; Section 4.4, Paragraph 3;
            Section 5, Paragraph 2; Section 5, Paragraph 3; Section 5.1,



Gupta                     Expires 20 April 2026                [Page 27]

Internet-Draft              HTTP Events Query               October 2025


            Paragraph 2; Section 5.1, Paragraph 3; Section 6, Paragraph
            3.1.1; Section 6, Paragraph 5; Section 7, Paragraph 4.2;
            Section 8, Paragraph 1; Section 8.1, Paragraph 1;
            Section 8.1, Paragraph 2; Section 8.2, Paragraph 1;
            Section 9, Paragraph 1; Section 9.1, Paragraph 1;
            Section 9.1, Paragraph 2; Section 9.1, Paragraph 3;
            Section 9.1, Paragraph 5; Section 9.2, Paragraph 1;
            Section 9.2.1, Paragraph 1; Section 9.2.1, Paragraph 2.1.1;
            Section 9.2.1, Paragraph 2.1.2.1.1; Section 9.2.2, Paragraph
            1; Section 9.2.2, Paragraph 2; Section 9.2.2, Paragraph 4;
            Section 9.2.2, Paragraph 6; Section 9.2.2, Paragraph 7;
            Section 9.2.2, Paragraph 9; Section 10, Paragraph 1;
            Section 10.1, Paragraph 1; Section 10.1, Paragraph 2;
            Section 10.2, Paragraph 1; Section 10.2, Paragraph 2;
            Section 10.2, Paragraph 5; Section 10.2, Paragraph 6;
            Section 11, Paragraph 2.2.1; Section 11, Paragraph 2.3.1;
            Section 12, Paragraph 2; Section 14, Paragraph 2;
            Section 14, Paragraph 3; Section 14, Paragraph 4;
            Section 14, Paragraph 5; Appendix A.1, Paragraph 1;
            Appendix A.2, Paragraph 1
         events (header field)  *_Section 5_*; Section 9.2.1, Paragraph
            2.1.1; Section 9.2.2, Paragraph 11; Section 11, Paragraph
            2.1.1; Table 1; Section 13.2, Paragraph 1; Section 13.2.1,
            Paragraph 1; Section 13.2.1, Paragraph 2.1.1

      I

         invoker  *_Section 4.1, Paragraph 1_*; Section 4.1, Paragraph
            2; Section 4.2, Paragraph 1

      N

         notification  Section Abstract, Paragraph 1; Section 1,
            Paragraph 3; Section 1, Paragraph 4; Section 1, Paragraph 5;
            Section 1, Paragraph 8; Section 1, Paragraph 9; Section 2,
            Paragraph 1; Section 2.1, Paragraph 1; Section 2.1,
            Paragraph 2.1.1; Section 2.1, Paragraph 2.2.1; Section 2.1,
            Paragraph 2.3.1; Section 2.1, Paragraph 2.4.1; Section 2.1,
            Paragraph 2.5.1; Section 2.2, Paragraph 2.2.1; Section 2.3,
            Paragraph 2.2.1; Section 2.3, Paragraph 2.3.1; Section 2.3,
            Paragraph 4.1.1; Section 2.3, Paragraph 4.2.1; Section 2.3,
            Paragraph 4.3.1; Section 2.3, Paragraph 4.4.1; Section 2.4,
            Paragraph 1; Section 2.4, Paragraph 2; Section 2.5,
            Paragraph 1; Section 2.5, Paragraph 2; Section 2.5,
            Paragraph 3; Section 4.2, Paragraph 3; *_Section 4.3_*;
            Section 4.3, Paragraph 1; Section 4.4, Paragraph 1;
            Section 4.4, Paragraph 2; Section 4.4, Paragraph 3;
            Section 5, Paragraph 2; Section 5, Paragraph 3; Section 5.1,



Gupta                     Expires 20 April 2026                [Page 28]

Internet-Draft              HTTP Events Query               October 2025


            Paragraph 2; Section 5.1, Paragraph 3; Section 6, Paragraph
            3.1.1; Section 6, Paragraph 5; Section 7, Paragraph 4.2;
            Section 8, Paragraph 1; Section 8.1, Paragraph 1;
            Section 8.1, Paragraph 2; Section 8.2, Paragraph 1;
            Section 9, Paragraph 1; Section 9.1, Paragraph 1;
            Section 9.1, Paragraph 2; Section 9.1, Paragraph 3;
            Section 9.1, Paragraph 5; Section 9.2, Paragraph 1;
            Section 9.2.1, Paragraph 1; Section 9.2.1, Paragraph 2.1.1;
            Section 9.2.1, Paragraph 2.1.2.1.1; Section 9.2.2, Paragraph
            1; Section 9.2.2, Paragraph 2; Section 9.2.2, Paragraph 4;
            Section 9.2.2, Paragraph 6; Section 9.2.2, Paragraph 7;
            Section 9.2.2, Paragraph 9; Section 10, Paragraph 1;
            Section 10.1, Paragraph 1; Section 10.1, Paragraph 2;
            Section 10.2, Paragraph 1; Section 10.2, Paragraph 2;
            Section 10.2, Paragraph 5; Section 10.2, Paragraph 6;
            Section 11, Paragraph 2.2.1; Section 11, Paragraph 2.3.1;
            Section 12, Paragraph 2; Section 14, Paragraph 2;
            Section 14, Paragraph 3; Section 14, Paragraph 4;
            Section 14, Paragraph 5; Appendix A.1, Paragraph 1;
            Appendix A.2, Paragraph 1

      O

         observation  *_Section 4.2_*; Section 11, Paragraph 2.2.1
         observer  *_Section 4.2, Paragraph 1_*; Section 4.2, Paragraph
            2; Section 4.2, Paragraph 3; Section 4.3, Paragraph 1;
            Section 4.4, Paragraph 1

      S

         subscriber  Section 4.3, Paragraph 3; *_Section 4.4, Paragraph
            1_*; Section 4.4, Paragraph 2
         subscription  Section 2.5, Paragraph 3; *_Section 4.4_*;
            Section 6, Paragraph 2; Section 6, Paragraph 4; Section 6,
            Paragraph 5; Section 8.1, Paragraph 1; Section 9.1,
            Paragraph 1; Section 9.1, Paragraph 2; Section 9.1,
            Paragraph 3; Section 9.1, Paragraph 5; Section 10.1,
            Paragraph 1; Section 10.1, Paragraph 2; Section 12,
            Paragraph 2

Author's Address

   Rahul Gupta
   Email: cxres+ietf@protonmail.com







Gupta                     Expires 20 April 2026                [Page 29]


name: draft-jewell-aibdp
rev: 00
title: AI Boundary Declaration Protocol (AIBDP)
time: 2026-02-16T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-02-15T23:59:42Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:05.127544+00:00
abstract:
This document defines the AI Boundary Declaration Protocol (AIBDP), a
   declarative framework for expressing usage boundaries around web-
   hosted content in relation to AI systems.  It builds on the
   mechanisms of RFC 2196 and RFC 9116, as well as on the HTTP semantics
   of RFC 9110 and the robots-style inclusion rules of RFC 7725, to
   provide machine-readable permissions and denials for indexing,
   training, mimicry, representation, derivative construction,
   analytical exploitation, and agentic access.  AIBDP supports ethical
   infrastructure, agentic AI governance, and procedural clarity across
   the Internet.

full_text:
Network Working Group                                       JDAJ. Jewell
Internet-Draft                             National Union of Journalists
Intended status: Informational                            15 August 2025
Expires: 16 February 2026


                AI Boundary Declaration Protocol (AIBDP)
                         draft-jewell-aibdp-00

Abstract

   This document defines the AI Boundary Declaration Protocol (AIBDP), a
   declarative framework for expressing usage boundaries around web-
   hosted content in relation to AI systems.  It builds on the
   mechanisms of RFC 2196 and RFC 9116, as well as on the HTTP semantics
   of RFC 9110 and the robots-style inclusion rules of RFC 7725, to
   provide machine-readable permissions and denials for indexing,
   training, mimicry, representation, derivative construction,
   analytical exploitation, and agentic access.  AIBDP supports ethical
   infrastructure, agentic AI governance, and procedural clarity across
   the Internet.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 February 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.








Jewell                  Expires 16 February 2026                [Page 1]

Internet-Draft              Consent Required                 August 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Manifest Format . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Consent States  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Use Case Scenarios  . . . . . . . . . . . . . . . . . . . . .   4
   6.  Interoperability with HTTP 430  . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Appendix A.  Implementation Examples . . . . . . . .   5
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   As AI systems become increasingly capable of autonomous interaction,
   generation, and ingestion of online content, current technical
   governance mechanisms such as robots.txt [RFC9309], security.txt
   [RFC9116], HTTP semantics per RFC 9110, and licensing-metadata fail
   to communicate granular boundaries for ethical AI use.  AIBDP
   introduces a declarative perimeter protocol designed to enable web
   publishers and institutions to express machine-readable consent
   declarations for specific categories of AI use, including indexing,
   training, agentic access, stylistic imitation, derivative prompting,
   analytic harvesting, and infrastructural activation.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119.

2.  Definitions

   AIBDP declarations may be conveyed through:

   *  .well-known/aibdp.json manifest

   *  HTTP response headers (e.g., GenAI-Consent)

   *  DNS TXT records



Jewell                  Expires 16 February 2026                [Page 2]

Internet-Draft              Consent Required                 August 2025


   *  HTML meta tags

   Declaration keys are grouped by category:

   *  consent: indexing, training, generation

   *  agentic: access, fallback

   *  representation: embedding, summarization, metadataHarvesting,
      multiHopRetrieval

   *  influence: stylisticImitation, thematicRegeneration,
      partialSampling

   *  derivation: promptDerivation, fineTuningBootstrap, templateReuse

   *  analytics: sentimentClassification, entityResolution,
      patternMining

   *  infrastructure: autonomousTaskTriggering, crossDomainAggregation,
      consentCircumvention

3.  Manifest Format

   AIBDP declarations are published as a JSON file:

   Location: /.well-known/aibdp.json

   Media Type: application/aibdp+json

   Example manifest:

   { "consent": { "indexing": "allow", "training": "deny", "generation":
   "deny" }, "agentic": { "access": "deny", "fallback": "deny" },
   "representation": { "embedding": "deny", "summarization": "deny",
   "metadataHarvesting": "deny", "multiHopRetrieval": "deny" },
   "influence": { "stylisticImitation": "deny", "thematicRegeneration":
   "deny", "partialSampling": "deny" }, "derivation": {
   "promptDerivation": "deny", "fineTuningBootstrap": "deny",
   "templateReuse": "deny" }, "analytics": { "sentimentClassification":
   "deny", "entityResolution": "deny", "patternMining": "deny" },
   "infrastructure": { "autonomousTaskTriggering": "deny",
   "crossDomainAggregation": "deny", "consentCircumvention": "deny" },
   "notice": "This content is protected under AIBDP.  Unauthorized
   ingestion or derivative use constitutes breach." }






Jewell                  Expires 16 February 2026                [Page 3]

Internet-Draft              Consent Required                 August 2025


4.  Consent States

   AIBDP supports the following values:

   *  allow

   *  deny

   *  limited

   *  sandbox

   *  deferred

   *  reviewed

   *  license

   *  disclosed

   *  aggregatedOnly

   *  anonymisedOnly

   Absence of a key implies undefined, not implicitly permitted.

5.  Use Case Scenarios

   *  Public blogs requiring attribution for stylistic reuse.

   *  Journalistic archives denying training and derivative use.

   *  Academic repositories permitting vector embedding only for
      licensed research.

   *  Creative portfolios blocking agentic model invocation.

6.  Interoperability with HTTP 430

   Per draft-jewell-http-430-consent-required [_30], if a client fails
   to comply with AIBDP boundaries, the server MAY respond:

   HTTP/1.1 430 Consent Required

   Content-Type: application/json

   /well-known/aibdp.json; rel="blocked-by"




Jewell                  Expires 16 February 2026                [Page 4]

Internet-Draft              Consent Required                 August 2025


   Retry-After: 86400

   { "error": "Consent declaration missing or invalid.", "reference":
   "https://example.org/.well-known/aibdp.json" }

   This enables ethical denial logic across protocol layers.

7.  Security Considerations

   AIBDP declarations are advisory and public.  Enforcement requires
   additional legal or infrastructure mechanisms.  Headers and manifests
   must not leak identifying information beyond declarative scope.

8.  IANA Considerations

   This document requests:

   *  Registration of /.well-known/aibdp.json

   *  Registration of media type application/aibdp+json

   *  Registration of HTTP header GenAI-Consent

   *  Recognition of 430 Consent Required (see draft-jewell-http-430-
      consent-required)

9.  Normative References

   [RFC9116]  IETF, "A File Format to Aid in Security Vulnerability
              Disclosure", RFC 9116, April 2022,
              <https://www.rfc-editor.org/info/rfc9116>.

   [RFC9309]  IETF, "Robots Exclusion Protocol", RFC 9309, September
              2022, <https://www.rfc-editor.org/info/rfc9309>.

   [_30]      Jewell, J. D., "HTTP Status Code 430: Consent Required",
              Work in Progress, Internet-Draft, draft-jewell-http-430-
              consent-required-00, 2025,
              <https://datatracker.ietf.org/doc/draft-jewell-http-430-
              consent-required/>.

Appendix A.  Appendix A.  Implementation Examples

   A.1 HTTP Headers

   GenAI-Consent: indexing=allow; training=deny; generation=deny GenAI-
   Agentic: access=deny; fallback=deny




Jewell                  Expires 16 February 2026                [Page 5]

Internet-Draft              Consent Required                 August 2025


   A.2 DNS TXT Record

   aibdp="training=deny; generation=deny; agentic.access=deny"

   A.3 HTML Meta Tags

   <meta name="aibdp-training" content="deny"> <meta name="aibdp-
   agentic-access" content="deny">

Appendix B.  Acknowledgements

   This proposal builds on ethical governance efforts in journalism,
   computing, and infrastructure architecture.  Thanks to contributors
   from the NUJ, the IETF HTTPAPI and ART areas, and transparency
   coalitions engaging in boundary-aware standards formation.

Author's Address

   Jonathan D.A. Jewell
   National Union of Journalists
   Email: jonathan@metadatastician.art






























Jewell                  Expires 16 February 2026                [Page 6]


name: draft-rosenberg-oauth-aauth
rev: 01
title: AAuth - Agentic Authorization OAuth 2.1 Extension
time: 2025-10-20T02:29:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T02:29:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:05.127553+00:00
abstract:
This document defines the Agent Authorization Grant, an OAuth 2.1
   extension allowing a class of Internet applications - called AI
   Agents - to obtain access tokens in order to invoke web-based APIs on
   behalf of their users.  In the use cases envisaged here, users
   interact with AI Agents through communication channels - the Public
   Switched Telephone Network (PSTN) or texting - which do not permit
   traditional OAuth grant flows.  Instead, AI agents collect Personally
   Identifying Information (PII) through natural language conversation,
   and then use that collected information to obtain an access token
   with appropriately constrained scopes.  A primary considering is
   ensuring that the Large Language Model (LLM) powering the AI Agent
   cannot, through hallucination, result in impersonation attacks.

full_text:
Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Standards Track                                P. White
Expires: 22 April 2026                                           Bitwave
                                                         19 October 2025


           AAuth - Agentic Authorization OAuth 2.1 Extension
                     draft-rosenberg-oauth-aauth-01

Abstract

   This document defines the Agent Authorization Grant, an OAuth 2.1
   extension allowing a class of Internet applications - called AI
   Agents - to obtain access tokens in order to invoke web-based APIs on
   behalf of their users.  In the use cases envisaged here, users
   interact with AI Agents through communication channels - the Public
   Switched Telephone Network (PSTN) or texting - which do not permit
   traditional OAuth grant flows.  Instead, AI agents collect Personally
   Identifying Information (PII) through natural language conversation,
   and then use that collected information to obtain an access token
   with appropriately constrained scopes.  A primary considering is
   ensuring that the Large Language Model (LLM) powering the AI Agent
   cannot, through hallucination, result in impersonation attacks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Rosenberg & White         Expires 22 April 2026                 [Page 1]

Internet-Draft                    AAuth                     October 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Framework and Requirements  . . . . . . . . . . . . . . . . .   5
   3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Basic Token Flow  . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Human-In-The-Loop . . . . . . . . . . . . . . . . . . . .   8
   4.  Detailed OAuth Grant Flow . . . . . . . . . . . . . . . . . .   8
   5.  Informative References  . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   AI Agents have recently generated a significant amount of industry
   interest.  They are software applications that utilize Large Language
   Models (LLM)s to interact with humans (or other AI Agents) for
   purposes of performing tasks.  Just a few examples of AI Agents are:

   *  A travel AI Agent which can help users search for travel
      destinations based on preferences, compare flight and hotel costs,
      make bookings, and adjust plans

   *  A loan handling agent that can help users take out a loan.  The AI
      Agent can access a users salary information, credit history and
      then interact with the user to identify the right loan for the
      target use case the customer has in mind

   *  A shopping agent for clothing, that can listen to user preferences
      and interests, look at prior purchases, and show users different
      options, ultimately helping a user find the right sports coat for
      an event

   Technically, AI agents are built using Large Language Models (LLMs)
   such as GPT4o-mini, Gemini, Anthropic, and so on.  These models are
   given prompts, to which they can reply with completions.  To creates
   an AI agent, complex prompts are constructed that contain relevant
   documentation, descriptions of tools they can use (such as APIs to
   read or write information), grounding rules and guidelines, along
   with input from the user.  The AI Agent then makes decisions about



Rosenberg & White         Expires 22 April 2026                 [Page 2]

Internet-Draft                    AAuth                     October 2025


   whether to interact further with the user for more information, or
   whether to invoke an API to retrieve information or perform an
   action.

   Please refer to [I-D.rosenberg-ai-protocols] for a framework and
   description on the protocols relevant in the design of AI Agents.

   Users interact with AI Agents through communication channels.  These
   can be dedicated mobile or web applications that provide a chat or
   voice communications function.

   This document focuses on a specific use case, which is the usage of
   AI Agents for customer support.  In this use case, a business is
   offering the AI agent to its customers.  In this use cases, it is
   common to access the AI Agent via a widget embedded in the business'
   web page.  Or, users can access these AI Agents through the Public
   Switched Telephone Network (PSTN).  In the United States, it is
   commonplace for businesses to have toll-free numbers that users can
   dial to reach customer support.  There is significant interest in
   allowing those calls to be handled by AI Agents.  Similarly, users
   can communicate with these AI Agents through text channels, or
   through third party applications like WhatsApp or Facebook Messenger.
   In all of these cases, the AI agent can only interact with the user
   through the exchange of real-time voice or messaging channels.

   In due course, the AI Agent will need to invoke APIs to perform
   actions or retrieve information, in which case it will require an
   access token that is valid for the invocation of the APIs.  Because
   the user can only interact with the AI Agent via real-time voice or
   SMS, there is no ability to perform the traditional OAuth [RFC6749]
   grant flows used in web or mobile applications.




















Rosenberg & White         Expires 22 April 2026                 [Page 3]

Internet-Draft                    AAuth                     October 2025


   This is not a new problem of course.  Prior to the arrival of LLMs,
   voice and chat bots for customer support have been interacting with
   users and invoking APIs to retrieve information or take actions.  The
   common practice was, at the time of development of the bot, to
   configure a service account into the various systems for which API
   access was required.  These service accounts were granted access to
   data for all of the potential users of the system.  The bot designer
   would then provide service account credentials to the bot, and the
   bot would perform an OAuth client credentials grant flow to obtain an
   access token - at design time.  The bot would also be designed to
   identify users, typically by collecting some kind of personally
   identifiable information (PII).  At run time, when the user interacts
   with the bot, the bot would collect PII information from the user,
   and then dip into databases that mapped the PII to a user identifer,
   such as an accountID, username or email address.  The bot would then
   - using its service account - access enterprise APIs to perform
   actions, and provide the user identifier as one of the API arguments.
   This allowed the bot to operate on the user's behalf.

   In this approach, the bot is highly trusted.  It is trusted to
   properly verify the identity of the user, and it is trusted to
   properly invoke APIs on behalf of the user which was identified.
   This trust is earned because the developers of bots are employees of
   the IT departments (or vendors operating on their behalf) of the
   businesses that served the end users in question, and also own the
   resources and APIs that the bot was accessing.

   The arrival of LLM-powered AI agents - next generation voice and chat
   bots - is now challenging both of these assumptions.

   Firstly, though the AI Agents are still being designed by IT
   departments (or vendors operating on their behalf), they are now
   making use of LLMs for decision making.  These LLMs are susceptible
   to hallucination, wherein the LLM asserts information that is not
   justified based on its inputs.  If we apply the prior generation of
   design practices to AI Agents - we end up giving them "god-like"
   tokens which allow highly privileged access, and they may hallucinate
   information passed into those APIs, perhaps being induced to do so
   via malicious end users.  This includes hallucination of the user
   identity.  Consider the following examples of problems that could
   arise:

   *  A patient is interacting with a healthcare AI agent, and asks to
      fulfill a prescription.  The LLM hallucinates the identity of the
      patient when invoking the prescription fulfillment API, assigning
      it to a different patient.  Because the AI Agent has a privileged
      service account, the fulfillment proceeds.  The patient never gets
      their prescription and suffers negative health consequences.



Rosenberg & White         Expires 22 April 2026                 [Page 4]

Internet-Draft                    AAuth                     October 2025


   *  A malicious user is attempting to steal money by tricking a
      financial services AI Agent into transferring funds from a target
      bank account into their own.  The user, through prompt injection
      attack, convinces the AI Agent to perform the transfer.  Because
      the AI Agent has a privileged service account, the transfer
      succeeds, and the malicious user is able to steal money

   These are but two examples of the many problems that can arise.

   The second assumption - that the APIs accessed by the AI agent were
   within the span of control of the enterprise IT department building
   the agent - is being challenged because these new AI agents are more
   highly capable and can be more effective in accessing a larger API
   surface area, including APIs that are outside of the ownership of the
   bot developer.  This is discussed in Section 2.2 of
   [I-D.rosenberg-ai-protocols].  Of particular relevance is the Model
   Context Protocol (MCP) (https://modelcontextprotocol.io/introduction
   (https://modelcontextprotocol.io/introduction)) which is being driven
   by Anthropic, and allows AI Agents to easily access APIs across the
   Internet.

   The solution proposed here is a new OAuth grant flow that removes the
   need for service-level accounts and their associated access tokens,
   and instead allows AI Agents to obtain low-privilege access tokens
   for the user's on whose behalf they are operating.

2.  Framework and Requirements

   The framework for the proposed grant flow is shown in the diagram
   below:

                          Live Agent -----------------|
                             |                        |
                             |                        |
          PSTN, text, msg    |                        V
   User ------------------ AI Agent ------------ Authorization
                             |                      Server
                             |
                             |
                             |
                             |
                       Resource Server

                       Figure 1: Framework for AAuth

   The AI Agent is a software application running on a server, making
   use of an LLM to communicate with a user.  The user communicates with
   the AI Agent over a communications channel that offers voice or chat



Rosenberg & White         Expires 22 April 2026                 [Page 5]

Internet-Draft                    AAuth                     October 2025


   functionality.  Examples include the PSTN, SMS or text messaging, or
   third party messaging channels such as WhatsApp or Facebook
   Messenger.  Most notably, these channels do not provide a vehicle for
   typical OAuth grant flows - they only allow the exchange of real-time
   voice and text messages.

   The AI Agent needs to access an API hosted on a resource server (RS).
   The AI Agent needs to obtain an access token for that interaction,
   which they do through an authorization server.

   There are also cases where the AI agent cannot do something without a
   human agent (live agent) approving something.  For example, in our
   funds transfer case, a human agent needs to be pulled in to approve,
   and only then can the AI agent gain access to a higher privilege
   token on behalf of the user.

   The following requirements apply:

   *  It must be possible for the AI Agent to obtain an access token
      that only allows them to perform operations for the user that is
      engaged with the AI Agent

   *  The AI Agent must be able to attain the access token using PII
      that the AI Agent has collected from the user over the
      communications channel

   *  It must not be possible, through any kind of hallucination that
      the AI Agent might perform, to obtain an access token for a
      different user than the one interacting with the AI Agent

   *  It must be possible for a human-in-the-loop approval from live
      agents for higher privilege tokens

3.  Solution Overview

3.1.  Basic Token Flow

   The solution works in much the same way this problem is solved when
   users interact with live customer support agents.

   In the case of a user interacting with a live customer support agent,
   the live customer support agent will identify the user by collecting
   multiple unique points of PII.  For example, in healthcare solutions,
   HIPAA requires two unique pieces of information, including full name,
   date of birth, last four digits of the SSN, medical record number, or
   phone number on file.





Rosenberg & White         Expires 22 April 2026                 [Page 6]

Internet-Draft                    AAuth                     October 2025


   The proposed solution here is similar.  The AI Agent is configured to
   interact with the user over the communication channel to collect a
   set of PII.  Once it collects this information, it passes the
   information to the Authorization Server (AS) using a new
   authorization grant type.  The AS maps this information to matching
   user, and if it matches, issues an access token for the user in
   question.  Though it is still possible that the LLM will hallucinate
   some of this information, it is highly unlikely that it would
   hallucinate a combination which represents a valid, but different
   user.  Indeed, the security of the solution depends on the sparseness
   of the space of mappings from the PII tuples to valid users.  If most
   PII tuples do not map to a valid user, then it is unlikely that the
   LLM would take PII data that does map to a specific user, and
   hallucinate a set of PII data that maps to a different, but valid
   user.  This is shown pictorially below:

         {PII-1, PII-2, PII-3}        {PII-1, PII-2, PII-3}
   User ------------------ AI Agent -----------------  Correct User
                             |
                             | {PII-1, PII-2, PII-4}
                             |
                             |
                             |
                       Invalid USer

      Figure 2: Hallucination Risk Mitigation with Sparse PII Mappings

   Consider once again the healthcare AI Agent which is interacting with
   a patient.  Through prompting, the AI Agent is configured to collect
   the user's last four digits of SSN, their full name, and their date
   of birth.  The user provides their last-four digits of their SSN as
   1234 (call this PII-1), their full name as "John Smith" (call this
   PII-2) and their date of birth as "April 3rd, 1975", clal this PII-3.
   Now, imagine that the LLM hallucinates the date of birth, and instead
   thinks it is "March 4th, 1975" - call this PII-4.  When the AI Agent
   passes this information to the Authorization Server, the particular
   combo - {PII-1, PII-2, PII-4} does not correspond to any user in the
   system.  The AS refuses to issue a token.

   By altering the required set of PII elements, designers of AI Agents
   can control the likelihood of hallucination (or malicious prompt
   injection attacks) resulting in a token issuance for the wrong user.
   The selection of the information becomes even more important for AI
   Agents.  Usage of PII elements which are known publically becomes a
   real risk.  If these are included in the training data for the LLM,
   it is indeed possible (and likely) that the LLM would hallucinate it.
   For example, if the patient in question is a famous actor, and their
   date of birth is public record in the IMDB, it is likely that the LLM



Rosenberg & White         Expires 22 April 2026                 [Page 7]

Internet-Draft                    AAuth                     October 2025


   would hallucinate the date of birth.  Consequently, the Authorization
   Servers can be configured to require sufficient number and complexity
   of PII in order to provide the desired level of security.

3.2.  Human-In-The-Loop

   The AS is fully responsible for user (live agent) interaction:

   1.  _Initiate_ the consent review flow with the user.  This spec does
       not specify how this occurs, it could be through an app, a chat
       client, or some other mechanism.
   2.  _Display_ the reason and each scope_descriptions entry to ensure
       the user has all the information necessary to assess the consent
       request.
   3.  _Authenticate_ the user (including MFA) and, upon consent, bind
       approval to request_code.

   _Note:_ The agent does _not_ handle redirects or UI rendering—it
   passively awaits token availability.

   After user approval, the agent obtains its access token via HTTP
   POlling or SSE.

4.  Detailed OAuth Grant Flow

   Details to be filled in.  New token endpoint which takes a series of
   PII parameters as input and produces an access token.

   An agent requests user approval by authenticating and POSTing to
   /agent_authorization:

   POST /agent_authorization HTTP/1.1 Host: auth.example.com Content-
   Type: application/x-www-form-urlencoded Authorization: Basic
   <base64(client_id:client_secret)>

   grant_type=urn:ietf:params:oauth:grant-type:agent_authorization&
   scope=urn:example:resource.read urn:example:resource.write
   reason="<human-readable reason>"

   *  _grant_type_: MUST be urn:ietf:params:oauth:grant-
      type:agent_authorization.
   *  _scope_: Space-delimited list of scope URIs.
   *  _reason_: Concise, human-readable explanation provided by the
      agent; MUST be echoed verbatim by the AS.

   Upon receipt, the AS:

   1.  _Validates_ client credentials.



Rosenberg & White         Expires 22 April 2026                 [Page 8]

Internet-Draft                    AAuth                     October 2025


   2.  _Fetches_ each scope’s description from the target RS’s
       https://{rs}/.well-known/aauth.json#scope_descriptions.
   3.  _Returns:_

   { "request_code": "GhiJkl-QRstuVwxyz", "token_endpoint":
   "https://auth.example.com/token" (https://auth.example.com/token"),
   "poll_interval": 5, "expires_in": 600, "poll_sse_endpoint":
   "https://auth.example.com/agent_authorization/sse"
   (https://auth.example.com/agent_authorization/sse"),
   "poll_ws_endpoint": "wss://auth.example.com/agent_authorization/ws" }

   To obtain tokens for HITL:

   1.  _HTTP Polling_

       POST /token HTTP/1.1 Host: auth.example.com Content-Type:
       application/x-www-form-urlencoded Authorization: Basic
       <base64(client_id:client_secret)>

       grant_type=urn:ietf:params:oauth:grant-type:device_code&
       device_code=GhiJkl-QRstuVwxyz

   _Pending_: {"error":"authorization_pending"} _Success_: Standard
   OAuth 2.x token response.

   1.  _Server-Sent Events (SSE)_

       GET /agent_authorization/sse?request_code=GhiJkl-QRstuVwxyz
       HTTP/1.1 Host: auth.example.com Authorization: Bearer <agent_jwt>
       Accept: text/event-stream

   On approval:

   event: token_response data: {"access_token":"<JWT>","expires_in":900,
   "issued_token_type":"urn:ietf:params:oauth:token-type:jwt"}

   1.  _WebSocket_

       GET /agent_authorization/ws?request_code=GhiJkl-QRstuVwxyz
       HTTP/1.1 Host: auth.example.com Upgrade: websocket Connection:
       Upgrade Sec-WebSocket-Protocol: aauth.agent-flow Authorization:
       Bearer <agent_jwt>

   On open:







Rosenberg & White         Expires 22 April 2026                 [Page 9]

Internet-Draft                    AAuth                     October 2025


     {
       "type": "token_response",
       "access_token": "<JWT>",
       "issued_token_type": "urn:ietf:params:oauth:token-type:jwt",
       "expires_in": 900
     }

5.  Informative References

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

Authors' Addresses

   Jonathan Rosenberg
   Five9
   Email: jdrosen@jdrosen.net


   Pat White
   Bitwave
   Email: pat.white@traego.com





















Rosenberg & White         Expires 22 April 2026                [Page 10]


name: draft-kompella-lsr-mptecap
rev: 00
title: Multipath Traffic Engineering Capabilities
time: 2026-01-09T07:09:54Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T21:16:46Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt"]
tags: []
fetched_at: 2026-02-27T22:56:05.127556+00:00
abstract:
Multipath Traffic Engineering (MPTE) combines two approaches to
   traffic management: equal-cost multipath and constraint-based traffic
   engineering, offering a powerful new way to engineer networks.  To
   avail of this, a node (possibly an ingress of a MPTE tunnel, or a
   path computation agent) must have information about the topology,
   link and node characteristics of a network so that it can compute the
   components of the MPTE tunnel.  One important (node) characteristic
   is whether a given node supports MPTE, i.e., whether it can
   participate in the provisioning and maintenance of the tunnel.

   This memo shows how this information can be distributed in the IGP
   via Link State Routing TE Capabilities.

full_text:
LSR WG                                                       K. Kompella
Internet-Draft                                          Juniper Networks
Updates: 5073 (if approved)                                  7 July 2025
Intended status: Standards Track                                        
Expires: 8 January 2026


               Multipath Traffic Engineering Capabilities
                     draft-kompella-lsr-mptecap-00

Abstract

   Multipath Traffic Engineering (MPTE) combines two approaches to
   traffic management: equal-cost multipath and constraint-based traffic
   engineering, offering a powerful new way to engineer networks.  To
   avail of this, a node (possibly an ingress of a MPTE tunnel, or a
   path computation agent) must have information about the topology,
   link and node characteristics of a network so that it can compute the
   components of the MPTE tunnel.  One important (node) characteristic
   is whether a given node supports MPTE, i.e., whether it can
   participate in the provisioning and maintenance of the tunnel.

   This memo shows how this information can be distributed in the IGP
   via Link State Routing TE Capabilities.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Kompella                 Expires 8 January 2026                 [Page 1]

Internet-Draft                  MPTE Cap                       July 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.1.  Definition of Commonly Used Terms . . . . . . . . . .   3
   2.  MPTE Capabilities . . . . . . . . . . . . . . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   [I-D.kompella-teas-mpte] introduces the notion of multipath traffic
   engineering (MPTE).  It describes how an entity (MPTE DAG computer or
   MC) can compute a directed acyclic graph (DAG) from one or more
   ingress nodes to one or more egress nodes that meets given traffic
   engineering (TE) constraints.  This entity (usually one of the
   ingresses, or a path computation engine) will need information about
   the network to do the computation, most of which is available in IGP
   TE extensions.  Once the computation is done, the MC communicates the
   result to the signaling source (SS) which then signals (or
   provisions) the MPTE tunnel via one of the following protocols: RSVP-
   TE [RFC3209], PCEP [RFC5440] or BGP [RFC4271].

   One key piece of information that is not currently in the IGP
   extensions is whether or not a given node supports MPTE, i.e., is
   capable of sending and receiving MPTE updates that create and
   maintain the tunnel.  An MPTE tunnel cannot be setup through such a
   node, and thus the MC has to take this into account.  This memo fills
   this gap.









Kompella                 Expires 8 January 2026                 [Page 2]

Internet-Draft                  MPTE Cap                       July 2025


1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.  These words may also appear in this
   document in lower case as plain English words, absent their normative
   meanings.

1.1.1.  Definition of Commonly Used Terms

   This section provides definitions for terms and abbreviations that
   have a specific meaning to the MPTE protocol and that are used
   throughout this memo.

   constraints:  desired properties of paths between ingresses and
      egresses.

   directed acyclic graph:  a directed graph that has no cycles.

   directed graph (DAG):  a set of nodes and directed links.  A network
      is represented by a directed graph.

   egress:  an end node of an MPTE DAG.

   ingress:  a starting node of an MPTE DAG.

   link:  A (directed) edge between two nodes.  A pair of nodes may have
      0 or more links between them.  A link between nodes u and v will
      be denoted by (u, v, i), where i is u's oif for the link.  A link
      may have associated attributes, in particular, a metric.

   MPTE:  multipath TE with constraints that uses multiple paths from
      one or more ingresses to one or more egresses.

   MPTED:  an MPTE DAG result of computation on MPTE constraints.

   MPTED computer (MC):  the entity computing the MPTED, typically the
      ingress (if there is a single ingress) or a Path Computation
      Element

   MPTEP:  MPTE protocol: the protocol used to signal MPTEDs.

   MPTE tunnel:  the signaled entity that carries the traffic from
      ingresses to egresses along the MPTED.

   node:  a vertex of a graph.  A node may have associated attributes.



Kompella                 Expires 8 January 2026                 [Page 3]

Internet-Draft                  MPTE Cap                       July 2025


   PCEP: Path Computation Element communication protocol.

   signaling source (SS):  the initiator of MPTE signaling to establish,
      update or destroy an MPTE tunnel.

   TE:  traffic engineering

2.  MPTE Capabilities

   [RFC5073] describes IGP protocol extension for the discovery of the
   TE capabilities of a node.  This memo extends that with three new
   capabilities: whether a node is capable of processing MPTE RSVP-TE
   messages, and whether a node is capable of processing MPTE PCEP
   messages.  The two capabilities are as follows:

   *  MR bit: when set, this flag indicates that the node can process
      MPTE RSVP-TE messages.

   *  MP bit: when set, this flag indicates that the node can process
      MPTE PCEP messages.

   *  MB bit: when set, this flag indicates that the node can process
      MPTE BGP messages.

   These bits are encoded in the TE Node Capability Descriptor defined
   in [RFC5073].
   This Descriptor is carried in ISIS and OSPF as defined in the same
   RFC.

3.  IANA Considerations

   IANA is asked to allocate three bits for the above capabilities in
   the Link State Routing TE Capabilities registry.

4.  Security Considerations

   This document specifies the content of the TE Node Capability
   Descriptor TLV in IS-IS and OSPF to be used for MPLS-TE path
   computation.  As this TLV is not used for SPF computation or normal
   routing, the extensions specified here have no direct effect on IP
   routing.  Tampering with this TLV may have an effect on Traffic
   Engineering computation.  Mechanisms defined to secure IS-IS Link
   State PDUs [RFC3567], OSPF LSAs [RFC2154], and their TLVs can be used
   to secure this TLV as well.

5.  References

5.1.  Normative References



Kompella                 Expires 8 January 2026                 [Page 4]

Internet-Draft                  MPTE Cap                       July 2025


   [I-D.kompella-teas-mpte]
              Kompella, K., Jalil, L., Khaddam, M., and A. Smith,
              "Multipath Traffic Engineering", Work in Progress,
              Internet-Draft, draft-kompella-teas-mpte-00, 3 March 2025,
              <https://datatracker.ietf.org/doc/html/draft-kompella-
              teas-mpte-00>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC5073]  Vasseur, J.P., Ed. and J.L. Le Roux, Ed., "IGP Routing
              Protocol Extensions for Discovery of Traffic Engineering
              Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
              December 2007, <https://www.rfc-editor.org/rfc/rfc5073>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

5.2.  Informative References

   [RFC2154]  Murphy, S., Badger, M., and B. Wellington, "OSPF with
              Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June
              1997, <https://www.rfc-editor.org/rfc/rfc2154>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/rfc/rfc3209>.

   [RFC3567]  Li, T. and R. Atkinson, "Intermediate System to
              Intermediate System (IS-IS) Cryptographic Authentication",
              RFC 3567, DOI 10.17487/RFC3567, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3567>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/rfc/rfc4271>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/rfc/rfc5440>.





Kompella                 Expires 8 January 2026                 [Page 5]

Internet-Draft                  MPTE Cap                       July 2025


Author's Address

   Kireeti Kompella
   Juniper Networks
   Sunnyvale, California 94089
   United States of America
   Email: kireeti.ietf@gmail.com












































Kompella                 Expires 8 January 2026                 [Page 6]


name: draft-rosenberg-cheq
rev: 00
title: CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL)
time: 2025-07-24T07:06:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-25T07:06:01Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Human-agent interaction", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127564+00:00
abstract:
This document proposes Confirmation with Human in the Loop (HITL)
   Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
   decisions and actions proposed by AI Agents prior to those decisions
   being acted upon.  It also allows humans to provide information
   required for tool invocation, without disclosing that information to
   the AI agent, protecting their privacy.  CHEQ aims to guarantee that
   AI Agent hallucinations cannot result in unwanted actions by the
   human on whose behalf they are made.  CHEQ can be integrated into
   protocols like the Model Context Protocol (MCP) and the Agent-to-
   Agent (A2A) protocols.  It makes use of a signed object which can be
   carried in those protocols.

full_text:
Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 25 January 2026                                         Bitwave
                                                             C. Jennings
                                                                   Cisco
                                                            24 July 2025


 CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the
                              Loop (HITL)
                        draft-rosenberg-cheq-00

Abstract

   This document proposes Confirmation with Human in the Loop (HITL)
   Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
   decisions and actions proposed by AI Agents prior to those decisions
   being acted upon.  It also allows humans to provide information
   required for tool invocation, without disclosing that information to
   the AI agent, protecting their privacy.  CHEQ aims to guarantee that
   AI Agent hallucinations cannot result in unwanted actions by the
   human on whose behalf they are made.  CHEQ can be integrated into
   protocols like the Model Context Protocol (MCP) and the Agent-to-
   Agent (A2A) protocols.  It makes use of a signed object which can be
   carried in those protocols.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 25 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Rosenberg, et al.        Expires 25 January 2026                [Page 1]

Internet-Draft                    CHEQ                         July 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architectural Framework . . . . . . . . . . . . . . . . . . .   4
   4.  Overview of Operation . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Triggering Confirmation . . . . . . . . . . . . . . . . .   7
     4.2.  Performing Confirmation . . . . . . . . . . . . . . . . .   9
     4.3.  Finalizing  . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Using CHEQ for Data Privacy . . . . . . . . . . . . . . . . .  12
   6.  Usage with MCP and A2A  . . . . . . . . . . . . . . . . . . .  13
   7.  Usage with Voice Interfaces . . . . . . . . . . . . . . . . .  13
   8.  Detailed Protocol Specification . . . . . . . . . . . . . . .  13
     8.1.  URI Pack Syntax and Semantics . . . . . . . . . . . . . .  13
     8.2.  CHEQ Object Syntax and Semantics  . . . . . . . . . . . .  13
     8.3.  CHEQ Protocol Details . . . . . . . . . . . . . . . . . .  13
   9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  14
   10. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   AI Agents are applications built using Large Language Models (LLMs).
   AI Agents typically operate on behalf of some human or organization,
   and are capable of taking actions through the invocation of
   functions, also known as tools.  [I-D.rosenberg-ai-protocols]
   provides an overview of protocols and use cases for AI Agents.  It
   identifies a critical unmet need in the current protocol landscape -
   human confirmation.













Rosenberg, et al.        Expires 25 January 2026                [Page 2]

Internet-Draft                    CHEQ                         July 2025


   Consider the following use case: a user is chatting with a travel
   agent AI Agent.  This AI Agent helps users search for travel
   destinations based on preferences, compare flight and hotel costs,
   make bookings and adjust plans.  The user is discussing with the AI
   Agent whether to take business or coach.  There is a long back and
   forth conversation about this.  Finally the user says, "go ahead and
   book it".  The AI Agent misinterprets the conversation, and chooses
   business class, despite the user's desire for coach.  It invokes a
   tool call on the flight system, acting on behalf of the user, and
   books the expensive flight that the user cannot afford.

   A more troubling use case is when a user interacts with a banking AI
   Agent, and requests transfer of funds.  To facilitate the tranfer,
   the user provides the AI agent with their account information.  The
   LLM hallucinates the account number, and results in funds being
   deposited into the wrong account.  This use case is doubly
   troublesome - not only has the user lost money, but they have leaked
   sensitive information (their account number) to an LLM.

   This document proposes a new protocol, called "Confirmation with
   Human in the Loop (HITL) Exchange of Quotations" - or CHEQ for short.
   The CHEQ protocol defines an object - the CHEQ - which memorializes a
   decision made by a human, and provides a cryptographic signature of
   it by an identity provides which authenticates the user.  It also
   defines a new protocol that allows for an API server to request
   information collection and/or confirmation outside of the scope of
   the LLM.

   Since CHEQ primarily involves the exchange of URLs within existing
   protocols, it is relatively easily embedded into emerging AI
   protocols, include the Model Context Protocol (MCP)
   (https://modelcontextprotocol.io/introduction
   (https://modelcontextprotocol.io/introduction)) which is being driven
   by Anthropic, the Agent2Agent (A2A) Protocol, driven by Google
   (https://google.github.io/A2A/#/documentation?id=agent2agent-
   protocol-a2a (https://google.github.io/
   A2A/#/documentation?id=agent2agent-protocol-a2a)) and now under
   governance of the Linux Foundation.  CHEQ is specifically designed to
   fit into the elicitation model under consideration with MCP.

2.  Requirements

   The requirements driving this protocol are as follows:

   *  The protocol must enable a human being to provide confirmation of
      an action that an AI Agent wishes to take





Rosenberg, et al.        Expires 25 January 2026                [Page 3]

Internet-Draft                    CHEQ                         July 2025


   *  The protocol must not depend on the LLM itself, so that it is not
      subject to LLM accuracy for proper operation

   *  The protocol must provide cryptographic assurances that the human
      being approves the action

   *  The protocol must support a wide variety of actions, such as API
      invocations, workflows, batch operations, and so on.  It must not
      be specific to any particular API or API function

   *  The protocol must work with existing user authentication
      techniques

   *  The protocol must protect against AI agents replaying past
      confirmations

   *  The protocol must enable non-repudiation of confirmations made by
      a human being, so that a resource server has evidence that a user
      provided confirmation

   *  The protocol must enable resource servers to collect information
      from users needed to complete a tool call, without disclosing that
      information to an LLM (privacy)

   *  It must be possible to memorialize confirmations into an object,
      so that they can be exchanged between systems, along with the
      cryptographic content needed to validate user confirmation.  This
      is essential for non-repudiation

   *  It must be possible for the end user to clearly know that the
      confirmation step is outside of the scope of the LLM, to provide
      confidence to them that they are in fact performing confirmation
      that is not subject to LLM hallucination

   *  It must be possible for the user confirmation to be performed by
      trusted third parties, separate from the organization owning the
      resource server.  This is a potentially controversial requirement.
      It stems from the desire to put control in the hands of end users
      in selecting a provider that they trust to confirm actions that AI
      Agents are taking on their behalf.

   *  The protocol must be easily integrated with MCP, A2A and similar
      protocols

3.  Architectural Framework






Rosenberg, et al.        Expires 25 January 2026                [Page 4]

Internet-Draft                    CHEQ                         July 2025


          +---------------------------------------+
          |                                       |
          |                                       |
   +------+-------+      +----------+       +-----v----+
   |              |      |          |       |          |
   | Confirmation |      | AI Agent +------>| Resource |
   | Server       |      |          |       | Server   |
   |              |      +----------+       |          |
   +--------------+           ^             +----------+
          ^                   |
          |              +----+-----+
          |              |          |
          +--------------+ User     |
                         | App      |
                         +----------+
                              ^
                              |
                         +----+-----+
                         |          |
                         | User     |
                         |          |
                         +----------+

                   Figure 1: CHEQ Architecture Framework

   The end user engages with an AI Agent via a User App. Often the user
   app is a browser application.  It could also be a thick desktop
   application.  The AI Agent typically runs on a server, though it
   could be running inside of the user app.  The AI agent includes an
   LLM along with an executor.  The executor formulates the inputs to
   the LLM, and processes its output.  The executor invokes APIs at the
   request of the LLM.  It does that by invoking the API on a resource
   server.  Such invocation could be via MCP, or could be direct API
   invocation.

   CHEQ introduces a new server, the Confirmation Server.  The
   Confirmation Server is responsible for rendering the information to
   be confirmed to the user, collecting their confirmation, and
   memorializing it by signing an object (the CHEQ object, which can
   then be passed back to the resource server.

   The confirmation server is a highly trusted entity in this system.
   The user trusts it to perform the confirmation operation.  We
   anticipate that users may desire to have this function centralized
   across many different API services, so that users have a single point
   of accountability and audit of decisions that have been confirmed.
   As an example, a trusted third party - something like Lets Encrypt -
   might run such a service, which users could adopt.



Rosenberg, et al.        Expires 25 January 2026                [Page 5]

Internet-Draft                    CHEQ                         July 2025


   We also anticipate a common deployment model is that each resource
   provider has the confirmation server for its services, integrated
   into the resource server.

   CHEQ makes several key assumptions about the trust relationships in
   the system:

   1.  The user is known to both the resource service, and to the
       confirmtion service.

   2.  The user is capable of directly authenticating itself to the
       confirmation service, and therefore has a relationship with it,
       having an account of some sorts on it.

   3.  The resource service knows of, and trusts the confirmation
       service to perform confirmation.  The resource service can obtain
       an OAuth token, most likely via a client credential grant, on the
       resource service, in order to use the CHEQ protocol.

   The CHEQ protocol is relatively simple, with two parts.  The first is
   a means to convey the URIs from the API server to the AI agent and
   User application.  The second is protocol for the confirmation server
   to talk to the API server.  This second part is not needed when they
   are the same.

4.  Overview of Operation

   The sequence diagram for the protocol is shown here:























Rosenberg, et al.        Expires 25 January 2026                [Page 6]

Internet-Draft                    CHEQ                         July 2025


participant user as "End User"
participant exec as "AI Agent - Executor"
participant llm as "AI Agent - LLM"
participant confirm as "Confirmation Server"
participant api as "API Server"

user->exec: "please book flight "
exec->llm: add user msg to context\nrun inference
llm->exec: tool call\nAPI=book\nflight=UA1234\ndate=8 August 2025, 12:20 EDT
exec->api: POST airline/book?{details}
api->exec: 202 Accepted\nJSON w. resource URI, confirmation URI, result URI
note right of exec: remember result URI
exec->user: pass URIs to browser
user->confirm: POST confirmation URI?resource URI
user->confirm: login
confirm->api: retrieve CHEQ object
api->confirm: CHEQ object
confirm->user: render information to confirm
user->confirm: click confirmation button
note right of confirm: sign cheq
confirm->api: send signed cheq
api->confirm: success
confirm->user: confirmed

note right of exec: polling
exec->api: retrieve result from result URI
api->exec: final result
exec->llm: add result to context
llm->exec: send msg\n"congrats your flight is booked"

                 Figure 2: Sequence Diagram for CHEQ

   There are three parts of the flow: trigger confirmation, performing
   confirmation, and finalizing.

4.1.  Triggering Confirmation

   When an AI Agent makes a decision to perform a tool call of some
   sort, it uses MCP, or directly invokes the API on the server that
   provides the tool (which is what is shown in the diagram for ease of
   understanding).  For example, it might invoke a REST API for
   performing a flight booking on an airline.  The AI Agent will have
   some form of OAuth [I-D.ietf-oauth-v2-1] token, either granted by the
   user or perhaps associated with a service account.

   The server recognizes the invocation as being associated with an AI
   Agent.  It can do this using a number of different techniques,
   including the client ID associated with the access token, the source



Rosenberg, et al.        Expires 25 January 2026                [Page 7]

Internet-Draft                    CHEQ                         July 2025


   IP address, or the service account used by the AI Agent.  Future
   solutions that formalize the authentication and identification of AI
   Agents, such as [I-D.meunier-web-bot-auth-architecture], can provide
   more robust ways to identify that the request is an AI Agent
   operating on a user's behalf.

   The resource server - the airline here - would be configured with
   policies that specify which API requests, when invoked by an AI
   Agent, require human confirmation.  That configuration could be
   provided ahead of time by the end user through the web site of the
   resource owner, or through policies defined by the provider
   themselves.  For example, the airline website might serve a UI which
   has radio buttons indicating that flight booking for flights over
   $100 require confirmation.  There are no new protocols required to do
   this.  CHEQ only requires that such policies have been configured
   ahead of time.

   The resource server would also be configured - by the end user or
   through its own administration - on what confirmation server it uses.
   This could be itself, or it could be a third party server.

   If the policy indicates that the resource server requires human
   confirmation, and the request is being made by an AI Agent, it
   responds with a 202 Accepted response.  This indicates that the
   server requires confirmation to complete the request.  The response
   includes a body, which we call the URI package, defined by this
   specification.  It includes three URIs which need to be conveyed
   between components.  The URIs are:

   1.  The confirmation server URI.  This is a raw URI, without any
       parameters.  The confirmation server must be one that the end
       user has a relationship with.  For example, if LetsEncrypt were
       to run a confirmation server, this might be
       https://confirmation.letsencrypt.org
       (https://confirmation.letsencrypt.org).  This is the URI that the
       user application will invoke in a browser to request user
       confirmation.

   2.  The resource URI.  This URI is minted by the resource server.
       This URI is used for the CHEQ protocol communication from the
       confirmation server to the resource server, as defined by this
       protocol.  The URI should reference the specific transaction
       which is being confirmed.  The resource server can embed that
       information into the URI however it likes.







Rosenberg, et al.        Expires 25 January 2026                [Page 8]

Internet-Draft                    CHEQ                         July 2025


   3.  The result URI.  This URI is also minted by the resource server.
       It is used by the AI agent to obtain the final results of the API
       transaction.  It would also embed a transaction identifier so the
       resource server knows how to return the right response.

   The URI pack looks like this:

{
   "confirmation uri" : "https://confirmation.letsencrypt.org",
   "resource uri" : "https://api.airline.com/confirmations/8asdjd8g9g0as",
   "result uri" : "https://api.airline.com/results/nn88kak0s0d8jj39sla"

}

                      Figure 3: URI Pack Example

   The URI pack is passed to the AI agent (which extracts the result URI
   in particular) and then to the user application.  The means for such
   conveyance area flexible, and not constrained by this spec.  If there
   is an MCP server between the resource server and the AI Agent, the
   MCP server might perform a special form of elicitation, passing these
   parameters.  This would perhaps require an MCP extension.

4.2.  Performing Confirmation

   Once the URI pack arrives at the user application, the user
   application extracts the confirmation URI, and performs a POST to the
   confirmation server, passing the resource URI as a parameter afer
   URI-encoding it.  The confirmation server needs this URI.

   The confirmation server first ensures that the end user is
   authenticated.

   The CHEQ protocol assumes that the confirmation server has a security
   relationship with the end user, such that the user is able to
   authenticate itself to the server.  The means for such authentication
   is outside of the scope of CHEQ, and any existing technqiues will
   suffice.  FUrthermore, CHEQ does not attempt to verify that the user
   is actually a human being.  It assumes that the authentication
   process is sufficient to demonstrate that the user is who they say
   they are.  If the user is not logged in, the confirmation server
   would request a login process.  The confirmation server does not need
   to be the login server.

   The confirmation server will receive the resource URI in the POST
   from the user application.  It will use that URI, which points to the
   resource server, and invoke the retrieve cheq function on the
   resource server:



Rosenberg, et al.        Expires 25 January 2026                [Page 9]

Internet-Draft                    CHEQ                         July 2025


   GET {resource-server}/cheq

   It will authenticate using whatever service account it has with the
   resource provider.  The response comes back, and it contains a CHEQ
   object.  This object contains the information to be verified with the
   user.  The CHEQ object is signed by the resource provider, so it
   cannot be tampered with.

   The CHEQ includes the API being invoked (e.g., book flight), the
   input parameters (eg., the flight number and date), facts (e.g., the
   price of the flight) and explanatory information meant for human
   consumption (e.g "this is the overnight flight from Newark to
   Madrid").

   The following is an example of what the CHEQ looks like:

{
   "version" : 1.0,
   "operation" : "https://airline.com/api/v1/book-flight",
   "operation name" : "Book airline",

   "inputs" : {
      "parameters" : [
         {
            "parameter name" : "flight number",
            "parameter description" : "The overnight flight from EWR to MAD",
            "parameter value" : "UA23"
         },
         {
            "parameter name" : "flight date",
            "parameter value" : "8 August 2025, 12:20 EDT"
         },
         {
            "parameter name" : "flight cost",
            "parameter value" : "$1200 USD"
         },

      ]

   },

   "date" : "July 23, 2025, 11:59 UTC",
}

                        Figure 4: CHEQ Object






Rosenberg, et al.        Expires 25 January 2026               [Page 10]

Internet-Draft                    CHEQ                         July 2025


   In the CHEQ object, the parameter values are the actual values which
   will show up in the API invocations.  The names and descriptions are
   used to provide information to the end user.  THey represent
   important information that helps the user decide whether to confirm
   or not, and because they factor into decision making, also need to be
   memorialized into the object and its signatures.

   The names and descriptions need to be provided in the language
   preferred by the end user.  Because the resource server knows the end
   user, it can use whatever its default language is for that user.

   The confirmation server renders a confirmation UI to the user.  The
   user can decide to accept or reject it.  If the user accepts, the
   confirmation server adds its own signature (signature details and
   multi-signature syntax TBD).  Else, the user rejects it.

   Based on the user decision, the confirmation server does one of two
   things.  If the user accepted, the newly signed CHEQ is posted to the
   resource server:

   POST {resource URI}?accept {body contains signed CHEQ}

   Else, if the user rejected it:

   POST {resource URI}?reject

   The resource server then updates the state of the resource
   accordingly.

4.3.  Finalizing

   The final step of the process is conveyance of the final result to
   the AI agent.

   The AI Agent will poll the resource server for updates.
   Alternatively, if MCP is used, the MCP server will poll for updates,
   and then provide an update to the AI Agent once the finalized result
   is obtained.

   Once the resource server has receive the acceptance (or rejection),
   it can respond to request from the AI Agent with the result, and the
   AI agent can proceed.









Rosenberg, et al.        Expires 25 January 2026               [Page 11]

Internet-Draft                    CHEQ                         July 2025


5.  Using CHEQ for Data Privacy

   The CHEQ protocol has an important property that the confirmation
   process happens outside of the scope of the LLM.  This enables CHEQ
   to be used in cases where the user does not wish to provide sensitive
   information to the AI Agent.

   In these cases, the confirmation server function is subsumed into the
   resource server.

   Consider the following example.  Instead of a flight booking, the
   user is using an AI Agent to transfer funds between bank accounts.
   This requires highly sensitive information - most notably the origin
   and destination account numbers.  The user does not wish to expose
   this information to the AI Agent, and specificaly, to the underlying
   LLM.

   To address this, the banking service can implement an API for
   transferrig funds, which is meant specifically for usage with CHEQ.
   This API would not take the parameters normally required for a
   transfer - no account numbers, no dollar amounts.  Instead, the API
   is just "transfer funds".  This API can be turned into a tool by the
   MCP server, which the AI Agent can decide to invoke.  When it is
   invoked, the banking server immediately responds with the 202 and
   passes the URI package.  In this use case, the confirmation server is
   the same as the resource server.  When the user application connects
   to the resource server to perform the confirmation, the resulting UI
   can be used for the actual data collection.  Once the data is
   collected, the AI Agent gets the results - merely that the data was
   transferred.  In this application of the CHEQ protocol, only the URI
   pack is ever sent on the wire.  The CHEQ object never needs to be
   generated, because the resource and confirmation server are the same.
   Indeed, the CHEQ would have contained sensitive information (the
   account numbers).

   In this case, we have enabled AI agents to work with users on complex
   tasks which require data collection that can be hidden from the AI
   Agent, achieving data privacy.

   The decision on which APIs require private data, and require CHEQ to
   be used, is made by the resource service.










Rosenberg, et al.        Expires 25 January 2026               [Page 12]

Internet-Draft                    CHEQ                         July 2025


6.  Usage with MCP and A2A

   CHEQ can easily be integrated into MCP, so that an MCP server sits
   between the AI Agent and the resource server in the diagram above.
   It requires an extension to the elicitation specifications, enabling
   the URI pack to be transferred from the resource server, through MCP,
   to the AI Agent.

   In a similar way, CHEQ can be integrated into A2A.  If Agent 1
   connects to Agent 2, and Agent 2 wishes to request user confirmation,
   Agent 2 can take the URI pack, pass it backwards through A2A to agent
   1, which passes it to its user.

7.  Usage with Voice Interfaces

   Modern AI Agents can also make use of voice interfaces towards the
   user.  The CHEQ protocol works equally well in this case, with a
   slightly different flow.

   Consider the User Application in this case as a voice gateway,
   receiving the voice traffic from the user and integrating it into the
   AI Agent.  This function may be co-located with the AI Agent, or it
   could be a separate component that (for example) is doing speech to
   text and speech synthesis in front of a text-based AI Agent.

   In either case, when the user application receives the URI pack,
   instead of passing this onto the user's web browser, it would connect
   to the confirmation server and retrieve a "raw" version of the CHEQ,
   read it out over voice, gain user appoval via voice, and then post
   that to the confirmation server.  This does require the confirmation
   server to support a flow which is amenable to rendering as voice, not
   HTML.

8.  Detailed Protocol Specification

8.1.  URI Pack Syntax and Semantics

   Details to be filled in.

8.2.  CHEQ Object Syntax and Semantics

   Details to be filled in

8.3.  CHEQ Protocol Details

   Details to be filled in





Rosenberg, et al.        Expires 25 January 2026               [Page 13]

Internet-Draft                    CHEQ                         July 2025


9.  Conclusions

   The CHEQ protocol provides a way for end users to confirm actions
   taken by AI Agents.  It does so outside of the LLM and AI Agent
   itself, eliminating any risk of the LLM hallucinating a tool call
   that the user does not desire.  The usage of out-of-band UI also
   provides a technique for data privacy, enabling AI agents to perform
   sensitive operations (like banking transfers) where the user does not
   wish to provide the sensitive information to the AI Agent.

10.  Informative References

   [I-D.ietf-oauth-v2-1]
              Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
              Authorization Framework", Work in Progress, Internet-
              Draft, draft-ietf-oauth-v2-1-13, 28 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              v2-1-13>.

   [I-D.meunier-web-bot-auth-architecture]
              Meunier, T., "HTTP Message Signatures for automated
              traffic Architecture", Work in Progress, Internet-Draft,
              draft-meunier-web-bot-auth-architecture-02, 19 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-meunier-web-
              bot-auth-architecture-02>.

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

Authors' Addresses

   Jonathan Rosenberg
   Five9
   Email: jdrosen@jdrosen.net


   Pat White
   Bitwave
   Email: pat.white@traego.com


   Cullen Jennings
   Cisco
   Email: fluffy@cisco.com



Rosenberg, et al.        Expires 25 January 2026               [Page 14]


name: draft-leon-distributed-multi-signer
rev: 00
title: Distributed DNSSEC Multi-Signer Bootstrap
time: 2025-08-11T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2025-08-11T13:27:57Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127574+00:00
abstract:
This document presents an architecture for a distributed DNSSEC
   multi-signer model that most closely resembles "model 2" in
   [RFC8901].

   It defines two multi-signer specific entities: the "multi-signer
   agent" (MSA) that is responsible for the multi-signer process and the
   "combiner", which is responsible for "combining" unsigned zone data
   from the zone owner with zone data under control of the MSA.  It
   introduces a new DNS RRtype, HSYNC, that is used by the zone owner to
   designate the chosen DNS Providers (signing and/or serving the zone).
   Furthermore it describes a mechanism for the MSAs to establish secure
   communication with each other, either via “pure DNS” communication
   secured by DNS SIG(0) signatures on each message or via a RESTful API
   secured by TLS.  Finally, the document describes two models for
   multi-signer process synchronization: “leader/follower mode” and
   “peer mode” and the mechanism by which a set of MSAs decide which
   model to use for a given zone.

   The scope of the document is only the distributed aspect of DNSSEC
   multi-signer up to the point where secure communication and
   synchronization method between MSAs has been established.  The
   “multi-signer algorithms” that deal with the actual synchronization
   required for multi-signer operation are described in
   [I-D.draft-ietf-dnsop-dnssec-automation].

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/johanix/draft-leon-dnsop-distributed-multi-signer
   (https://github.com/johanix/draft-leon-dnsop-distributed-multi-
   signer).  The most recent working version of the document, open
   issues, etc, should all be available there.  The authors (gratefully)
   accept pull requests.

full_text:
DNSOP Working Group                                         L. Fernandez
Internet-Draft                                              E. Bergström
Intended status: Standards Track                             J. Stenstam
Expires: 11 August 2025                  The Swedish Internet Foundation
                                                              S. Crocker
                                             Edgemoor Research Institute
                                                         7 February 2025


               Distributed DNSSEC Multi-Signer Bootstrap
                 draft-leon-distributed-multi-signer-00

Abstract

   This document presents an architecture for a distributed DNSSEC
   multi-signer model that most closely resembles "model 2" in
   [RFC8901].

   It defines two multi-signer specific entities: the "multi-signer
   agent" (MSA) that is responsible for the multi-signer process and the
   "combiner", which is responsible for "combining" unsigned zone data
   from the zone owner with zone data under control of the MSA.  It
   introduces a new DNS RRtype, HSYNC, that is used by the zone owner to
   designate the chosen DNS Providers (signing and/or serving the zone).
   Furthermore it describes a mechanism for the MSAs to establish secure
   communication with each other, either via “pure DNS” communication
   secured by DNS SIG(0) signatures on each message or via a RESTful API
   secured by TLS.  Finally, the document describes two models for
   multi-signer process synchronization: “leader/follower mode” and
   “peer mode” and the mechanism by which a set of MSAs decide which
   model to use for a given zone.

   The scope of the document is only the distributed aspect of DNSSEC
   multi-signer up to the point where secure communication and
   synchronization method between MSAs has been established.  The
   “multi-signer algorithms” that deal with the actual synchronization
   required for multi-signer operation are described in
   [I-D.draft-ietf-dnsop-dnssec-automation].

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/johanix/draft-leon-dnsop-distributed-multi-signer
   (https://github.com/johanix/draft-leon-dnsop-distributed-multi-
   signer).  The most recent working version of the document, open
   issues, etc, should all be available there.  The authors (gratefully)
   accept pull requests.






Fernandez, et al.        Expires 11 August 2025                 [Page 1]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 August 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Multi-Signer Use Cases  . . . . . . . . . . . . . . . . . . .   6
     4.1.  Primary Use Case  . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Secondary Use Case  . . . . . . . . . . . . . . . . . . .   7
     4.3.  Tertiary Use Case . . . . . . . . . . . . . . . . . . . .   7
   5.  The Distributed Multi-Signer Model  . . . . . . . . . . . . .   7
     5.1.  Multi-Signer Agent: Integrated Signer vs Separate
           Agent . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Source of Truth . . . . . . . . . . . . . . . . . . . . .   9
       5.2.1.  The COMBINER  . . . . . . . . . . . . . . . . . . . .  10
     5.3.  The DNS Provider  . . . . . . . . . . . . . . . . . . . .  11
   6.  Identifying the Designated Signers  . . . . . . . . . . . . .  12



Fernandez, et al.        Expires 11 August 2025                 [Page 2]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   7.  The HSYNC RRset . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Semantics of the HSYNC State Field  . . . . . . . . . . .  13
     7.2.  Semantics of the HSYNC NSMgmt Field . . . . . . . . . . .  13
       7.2.1.  Limitation of Scope for NS Management . . . . . . . .  13
     7.3.  Semantics of the HSYNC Sign Field . . . . . . . . . . . .  14
   8.  Communication Between MSAs  . . . . . . . . . . . . . . . . .  14
     8.1.  MSA Communication via DNS . . . . . . . . . . . . . . . .  15
     8.2.  MSA Communication via REST API  . . . . . . . . . . . . .  15
     8.3.  Locating Remote Multi-Signer Agents . . . . . . . . . . .  15
       8.3.1.  Locating a Remote DNS-Method Multi-Signer Agent . . .  16
       8.3.2.  Locating a Remote API-Method Multi-Signer Agent . . .  17
     8.4.  The Initial HELLO Phase . . . . . . . . . . . . . . . . .  18
       8.4.1.  DNS-based HELLO Phase . . . . . . . . . . . . . . . .  18
       8.4.2.  API-based HELLO Phase . . . . . . . . . . . . . . . .  19
       8.4.3.  Interpretation of the HELLO Responses . . . . . . . .  19
     8.5.  Multi-Signer EDNS(0) Option Format  . . . . . . . . . . .  19
       8.5.1.  Encoding Transport Capabilities in the Multi-Signer
               EDNS(0) Option  . . . . . . . . . . . . . . . . . . .  21
       8.5.2.  Encoding Synchronization Capabilities in the
               Multi-Signer EDNS(0) Option . . . . . . . . . . . . .  21
   9.  Sequence Diagram Example of Establishing Secure Comms - "The
           Hello Phase"  . . . . . . . . . . . . . . . . . . . . . .  22
   10. Synchronization of Changes Between MSAs . . . . . . . . . . .  23
     10.1.  Leader/Follower Mode . . . . . . . . . . . . . . . . . .  24
     10.2.  Peer Mode  . . . . . . . . . . . . . . . . . . . . . . .  24
     10.3.  Multi-Signer State Transitions . . . . . . . . . . . . .  24
   11. Responsibilities of an MSA  . . . . . . . . . . . . . . . . .  24
     11.1.  Enabling Remote MSAs to Locate This MSA  . . . . . . . .  24
     11.2.  Enabling Remote MSAs to Lookup Zone Data Added By This DNS
            Provider . . . . . . . . . . . . . . . . . . . . . . . .  25
   12. Migration from Single-Signer to Multi-Signer  . . . . . . . .  26
     12.1.  Adding a single HSYNC record to an already signed
            zone . . . . . . . . . . . . . . . . . . . . . . . . . .  26
     12.2.  Changing the HSYNC NSMGMT Field from AGENT To OWNER  . .  26
     12.3.  Migrating from a Multi-Signer Architecture Back to
            Single-Signer. . . . . . . . . . . . . . . . . . . . . .  27
     12.4.  Choice of the HSYNC Mnemonic . . . . . . . . . . . . . .  27
     12.5.  Separation of MSA and COMBINER . . . . . . . . . . . . .  27
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  28
   14. IANA Considerations.  . . . . . . . . . . . . . . . . . . . .  28
     14.1.  HSYNC RR Type  . . . . . . . . . . . . . . . . . . . . .  28
     14.2.  New Multi-Signer EDNS Option . . . . . . . . . . . . . .  29
     14.3.  A New Registry for EDNS Option Multi-Signer Operation
            Codes  . . . . . . . . . . . . . . . . . . . . . . . . .  29
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  29
     15.2.  Informative References . . . . . . . . . . . . . . . . .  30
   Appendix A.  Change History (to be removed before publication)  .  31



Fernandez, et al.        Expires 11 August 2025                 [Page 3]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

1.  Introduction

   The issue of how to eliminate so-called "single points of failure"
   from systems to make them more robust is a recurring theme in systems
   design and so also for DNS.  In the DNS case redundancy is addressed
   by having multiple name servers for the same zone.  However, when the
   zone is DNSSEC-signed there is traditionally an additional single
   point of failure: the so-called "signer" of the zone.

   In multi-signer ([RFC8901]) model 2, a process is described by which
   it is possible to use more than one signer (each with its own set of
   keys), by having the signers (or their agents) communicate and
   exchange data that should be signed by the other signer.  The most
   obvious example is that each signer's Key-Signing Key must sign a
   DNSKEY RRset that contains the Zone-Signing Keys for all signers.

   To synchronize data between signers two models are possible: either a
   "centralized" model where a single "controller" decides what changes
   are needed, or a "distributed" model where the signers themselves (or
   an agent of each signer) decide what changes are needed.

   The first model has been implemented previously, and while it works
   from a technical point of view, it is not a good solution from a risk
   management point of view.  The primary problem is that the signers
   have difficulty accepting that an external third party (the
   controller) has the ability to modify data (in a customer zone).

   This document is an attempt to address the synchronization problem by
   proposing a distributed model without a central controller.

   The communication between signers has two parts: first it is
   necessary to find out what data each signer has for a zone.  Once all
   data has been collected it is possible to compute what changes are
   needed to the zone data at each signer.  That triggers the second
   phase where the zone data for the individual signers is changed to
   get them in sync with each other.  All of this is done automatically.

   However, from a slightly different perspective, the multi-signer
   alternative is the more general case of DNSSEC signing, with the
   (very common) case of a single signer being a special case.









Fernandez, et al.        Expires 11 August 2025                 [Page 4]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   From that point of view, this document proposes an architecture for a
   completely automated, distributed multi-signer model together with a
   seamless transition path from the current single-signer model to the
   multi-signer model.  From the zone owners point of view, the
   transition is done through the addition of a new RRtype, HSYNC, that
   is used to designate the chosen DNS Providers, their responsibilities
   and information to enable the DNS Providers to locate each other.

   Knowledge of DNS NOTIFY [RFC1996] and DNS Dynamic Updates [RFC2136]
   and [RFC3007] is assumed.  DNS SIG(0) transaction signatures are
   documented in [RFC2931].

1.1.  Requirements Notation

   The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*",
   "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT
   RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be
   interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only
   when, they appear in all capitals, as shown here.

2.  Terminology

   ...

3.  Requirements

   The requirements for an architecture for distributed multi-signer are
   defined as follows:

   *  Assuming all zone transfers are correctly set up, a zone owner
      MUST be able to signal to the individual multi-signer providers
      information sufficient for the providers to identify each other
      and establish secure communication.

   *  The zone owner MUST be able to signal the intent to onboard an
      additional multi-signer provider.  This MUST automatically
      initiate the multi-signer “add signer” process, as described in
      [RFC8901].

   *  The zone owner MUST be able to signal the intent to offboard an
      existing multi-signer provider.  This MUST automatically initiate
      the multi-signer “remove signer” process, as described in
      [RFC8901].

   *  All signalling from zone owner to multi-signer providers SHOULD be
      carried out via data in the served zone, to ensure that all
      providers get the same configuration information at (almost) the
      same time.



Fernandez, et al.        Expires 11 August 2025                 [Page 5]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   *  By engaging a set of multi-signer providers (one or more), the
      zone owner MUST give up control over the following records:

      -  All DNSSEC related records in the zone

      -  Any CDS and/or CSYNC RRsets

   *  It SHOULD be possible but NOT MANDATORY for the zone owner to also
      delegate the management of the NS RRset to the set of DNS
      Providers.

4.  Multi-Signer Use Cases

4.1.  Primary Use Case

   The primary use case for the proposed multi-signer architecture is
   the following scenario: A zone owner needs to remove the single point
   of failure that the DNSSEC signer constitutes.  For this reason it
   contracts with two or more “multi-signer capable” DNS providers.
   Each such DNS provider provides the following service:

   *  Receive the unsigned zone via zone transfer.

   *  Locate all active DNS Providers via the HSYNC RRset as published
      by the zone owner.  Establish secure communication with all remote
      DNS Providers (via their agents).

   *  Update the DNSKEY, CDS and CSYNC RRsets as needed, based on
      synchronization with the remote signers (or their agents).

   *  Update the NS RRset if allowed by the zone owner, based on
      synchronization with the remote DNS Providers (or their agents).

   *  Sign the zone, using own DNSKEYs, but with a published DNSKEY
      RRset that includes the DNSKEYs of other signers.

   *  Possibly distribute the signed zone to a set of downstream
      authoritative nameservers under own control.

   *  Possbly distribute the signed zone to non-signing downstream DNS
      Providers.










Fernandez, et al.        Expires 11 August 2025                 [Page 6]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


4.2.  Secondary Use Case

   A slightly different use case is where a zone owner has a desire to
   replace one DNSSEC-signing DNS provider with another.  In the first
   step it onboards the new DNS provider by adding a HSYNC RR with HSYNC
   State=“ON” thereby identifying the new DNS provider and signalling
   its role.  This informs both the present DNS providers and the
   incoming DNS provider about the addition of the new DNS provider and
   the onboarding process is automatically initiated.

   Once the onboarding operation is completed the zone owner may trigger
   the pending removal of another DNS provider by changing the HSYNC
   State flag for the outgoing DNS Provider to “OFF”. This informs all
   the present DNS providers about the pending removal and the
   offboarding process is automatically initiated.

4.3.  Tertiary Use Case

   A third use case is where a zone owner wants to migrate from a
   single-signer model to a multi-signer model, but as a first step only
   wants to transition the existing signer to be designated via a single
   HSYNC record.  Once that is done the zone owner can continue the
   transition to a full multi-signer model at a later time by adding
   more HSYNC records.

5.  The Distributed Multi-Signer Model

   The primary difference between monolithic and distributed multi-
   signer is that the former has a central “controller” while the latter
   doesn’t.  But there is still an absolute need for synchronization
   between the different participants in the distributed multi-signer
   setup.

   There are three immediate aspects for the design of a distributed
   multi-signer architecture:

   *  The first is “transport”: how to communicate between the
      individual instances in a multi-signer system.

   *  The second is “synchronization”: who decides what changes are
      needed where.










Fernandez, et al.        Expires 11 August 2025                 [Page 7]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   *  The third is source of truth for different types of zone data.
      The zone owner is the source of truth for all unsigned zone data,
      except DNSSEC data.  The signer is the source of truth for all
      DNSSEC data in the zone.  Traditionally, the source of truth for
      the NS RRset is the zone owner, but with multiple DNS Providers
      having the option of moving that responsibility to the DNS
      Providers would be an important improvement.

5.1.  Multi-Signer Agent: Integrated Signer vs Separate Agent

   In a distributed setup there must be a service located with each
   multi-signer DNS Provider that manages communication with other DNS
   Providers.  This is referred to as the multi-signer agent, or MSA.
   As not every DNS Provider needs to be signing the zone, the term is
   not entirely perfect, but sufficient.

   It is possible to implement support for the synchronization and
   communication needs directly into each “signer” (i.e. typically an
   authoritative nameserver with the ability to do online DNSSEC
   signing).  In this case the signer implements the MSA functionality.

   However, it is also possible to separate the multi-signer
   functionality into a separate agent.  This agent sits next to the
   signer, and is under the same administrative control (the "DNS
   Provider"), but is a separate piece of software.  When using this
   design each signer has an MSA attached next to it.  Each MSA is
   configured as a “secondary nameserver” to a signer and receives the
   (signed) zone from this signer.

   The “separate MSA” design has the major advantage of leaving the
   signer almost entirely out of the multi-signer complexity.  The
   requirements are only that the “signer” treats the MSA as a normal
   secondary (sends NOTIFY messages and responds to zone transfer
   requests) and that the MSA has a mechanism that allows it to make
   changes to zones upstream of the “signer” to satisfy the multi-signer
   requirements for synchronization of certain RRsets in the apex of the
   zone.

   In this document the design using a separate MSA is used, while
   pointing out that it is possible to integrate this into a future
   “signer” that implements both DNSSEC signing and the MSA
   functionality.









Fernandez, et al.        Expires 11 August 2025                 [Page 8]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


5.2.  Source of Truth

   A common design for DNSSEC signing (regardless of multi-signer) is to
   use a separate, bump-on-the-wire signer.  This is a signer that
   receives the unsigned zone via an incoming zone transfer, signs the
   zone, and publishes the signed zone via an outbound zone transfer.
   In such a design the source of truth has been split up between the
   “zone owner” (source of truth for all non-DNSSEC zone data), and the
   signer (source of truth for all DNSSEC data in the zone).

   In a distributed multi-signer architecture the source of truth is
   further split up into three participants:

   *  The zone owner is the source of truth for all unsigned zone data,
      except DNSSEC data and possibly the NS RRset.

   *  The signer is the source of truth for all data generated via
      DNSSEC signing: own DNSKEYs, NSEC/NSEC3 RRs, RRSIGs, etc.

   *  The MSA is the source of truth for the RRsets that must be kept in
      sync across all the signers for the zone.  This includes the
      DNSKEYs from other signers, CDS and CSYNC RRsets.  Possibly also
      the NS RRset.

   The NS RRset is an interesting special case.  Traditionally the NS
   RRset is maintained by the zone owner, but based on data from the DNS
   providers (as authoritative nameservers is a primary service for the
   DNS provider).  However, in a distributed multi-signer architecture
   the NS RRset should preferably be maintained by the MSA.  For this
   reason the proposed design makes control of the NS RRset explicit and
   the responsibility of the zone owner to choose whether to retain
   control or delegate to the MSAs.  Hence:

   *  The MSA is the source of truth for the NS RRset, subject to the
      policy of the zone owner, as described in the HSYNC RRset.

   Making the control of the NS RRset explicit is useful regardless of
   whether a zone uses multiple signers or single signer.

   To be able to keep the signer as simple as possible, the changes to
   the NS, DNSKEY, CDS and CSYNC RRsets must be introduced into the
   unsigned zone before the zone reaches the signer.  Likewise, to keep
   the zone owner as simple as possible (i.e. not involved in the
   details of the multi-signer automation) these changes must be
   introduced into the unsigned zone after the zone leaves the zone
   owner.





Fernandez, et al.        Expires 11 August 2025                 [Page 9]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


5.2.1.  The COMBINER

   The consequence of these requirements is that the DNSKEY, CDS and
   CSYNC RRsets (and possibly the NS RRset) are maintained via a
   separate piece of software inserted between the zone owner and the
   signer.  This is referred to as the multi-signer COMBINER.

   The COMBINER has the following features:

   *  It supports inbound zone transfer of the unsigned zone from the
      zone owner.

   *  It receives updates for the NS, DNSKEY, CDS and CSYNC RRsets from
      the MSA.  Typically the mechanism used is DNS UPDATE with a TSIG
      signature, as this is easy to configure in a local context.
      However, other mechanisms, including APIs, are possible.

   *  It stores all data received from the MSA separate from the zone
      data received from the zone owner.

   *  Whenever it receives a new unsigned zone from the zone owner it
      COMBINES zone data from the zone owner (the majority of the zone)
      with specific zone data under control of the MSA: three specific
      RRsets, all in the apex of the zone: the DNSKEY,CDS and CSYNC
      RRsets.

   *  It is policy free.  I.e. the COMBINER is not making any judgement
      about what data to include in the zone from the four defined
      RRsets.  That judgement is the role of the MSA.

   *  It does not sign the zone.

   *  It provides outbound zone transfer of the combined zone to the
      signer.

   Example setup with two signers showing the logical flow of zone data
   between the zone owner, the COMBINER, the signer and the MSA:














Fernandez, et al.        Expires 11 August 2025                [Page 10]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


                             +--------------+
                             |     owner    |
                xfr          +-+---------+--+    xfr
             /----------------/           \--------------------\
            /                                                   \
     +-----+----+    DNS  +-----+  DNS/API  +-----+  DNS    +----+-----+
     | combiner +<--------+ msa +-----------+ msa +-------->+ combiner |
     +-----+----+  UPDATE +--+--+           +--+--+ UPDATE  +----+-----+
           |                 ^                 ^                 |
           v xfr             |                 |                 v xfr
     +-----+----+     xfr    |                 |   xfr      +----+-----+
     |  signer  +------------+                 +------------+  signer  |
     +-----+----+                                           +----+-----+
           |                                                     |
           v                                                     v
        +--+--+                                               +--+--+
        | NS  |--+                                            | NS  |+
        +-----+  |--+                                         +-----+|-+
           +-----+  |                                            +---+ |
              +-----+                                              +---+

5.3.  The DNS Provider

   A "DNS Provider" is a term that is most commonly used to refer to an
   entity that provides authoritative DNS service to one or more zone
   owners.  In the context of this document it is used to refer to an
   entity that provides some subset of the following services:

   *  Signing a zone received from the zone owner.

   *  Serving the zone via a set of authoritative nameservers.

   *  Distributing the signed zone to other downstream DNS Providers.

   In addition to the above services a DNS Provider MUST also provide:

   *  An MSA for synchronization with other DNS Providers

   *  A COMBINER for the management of changes to the zone via the
      synchronization among MSAs (if it provides a signer)

   I.e. in the setup above there are two DNS Providers, both of which
   are "complete" in the sense that they provide all three of the above
   services.







Fernandez, et al.        Expires 11 August 2025                [Page 11]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


6.  Identifying the Designated Signers

   It is the responsibility of the zone owner to choose a set of "DNS
   Providers", either internal or external to the zone owners
   organization.  These DNS Providers MUST be clearly and uniquely
   designated via publication in the HSYNC RRset, located at the apex of
   the zone and consisting of one HSYNC record for each signer.

   The HSYNC RRset MUST be added, by the zone owner, to the, typically
   unsigned, zone that the zone owner maintains so that this RRset is
   visible to the downstream DNS Providers and their multi-signer
   agents.

7.  The HSYNC RRset

   The HSYNC RR has the zone name that publishes the HSYNC RRset as the
   owner name (i.e. the HSYNC RRset must be located at the apex of the
   zone).  The RDATA consists of four fields "State","NSMgmt", "Sign"
   and "Identity":

   zone.example.  IN HSYNC State NSMgmt Sign Identity.

   State: Unsigned 8-bit.  Defined values are 1=ON and 2=OFF.  The value
   0 is an error.  Values 3-127 are presently undefined.  Values 128-255
   are reserved for private use.  The presentation format allows either
   as integers (1 or 2) or as tokens (“ON” or “OFF”).

   NSMgmt: Unsigned 8-bit.  Defined values are 1=Zone owner and 2=MSA.
   The value 0 is an error.  Values 3-255 are presently undefined (and
   not expected to be defined).  The presentation format allows either
   as integers (1 or 2) or as tokens (“OWNER” or “AGENT”).

   Sign: Unsigned 8-bit.  Defined values are 1=YES and 2=NO.  The value
   0 is an error.  If Sign=YES for a particular HSYNC record, then the
   signer associated with that Identity is a designated signer for the
   zone.

   Identity: Domain name.  Used to uniquely identify the Multi-Signer
   Agent for the DNS Provider that the MSA represents.

   Example:

   zone.example.  IN HSYNC ON AGENT YES msa.provider.example.








Fernandez, et al.        Expires 11 August 2025                [Page 12]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


7.1.  Semantics of the HSYNC State Field

   The HSYNC State field is used to signal to all MSAs what the status
   of each MSA is from the point-of-view of the zone owner.  The two
   possible values are "ON" and "OFF" where "ON" means that the MSA is a
   currently designated signer for the zone and "OFF" means that the MSA
   is previously designated signer for the zone that is in the process
   of being offboarded.

   The reason for the "OFF" state is that the offboarding process
   involves the remaining signers (hence the signalling) and it is
   important to know which signer is being offboarded so that the
   correct data may be removed in the correct order during the multi-
   signer "remove signer" process (see [RFC8901]).

   Once the offboarding process is complete the HSYNC RR for the
   offboarded MSA may be removed from the zone at the zone owners
   discretion.

7.2.  Semantics of the HSYNC NSMgmt Field

   The NSMgmt field is used to signal to the MSAs who is responsible for
   the contents of the NS RRset for the zone.  The two possible values
   are "OWNER" and "AGENT".

   The value "OWNER" signals that the zone owner is responsible for the
   NS RRset and is responsible for updating the NS RRset (either with or
   without the unified data from all MSAs).  In this case the MSAs MUST
   NOT instruct the COMBINER to update the NS RRset.

   The value "AGENT" means that the MSAs representing DNS Providers that
   sign the zone are responsible for the contents of the NS RRset.  In
   this case the these MSAs MUST instruct the COMBINER to update the NS
   RRset with the unified NS RRset data from all MSAs.

7.2.1.  Limitation of Scope for NS Management

   For the purpose of this document the NSMgmt Field only covers the NS
   RRset.  I.e. it does not include the address records of in-bailiwick
   authoritative nameservers.  The reasons are:

   *  Limiting the possibility of DNS Providers "polluting" the name
      space of the zone.

   *  Keeping the specification simpler, as the concept of "delegated"
      NS management is new.





Fernandez, et al.        Expires 11 August 2025                [Page 13]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   It is possible to make an argument for delegating management of
   address records for in-bailiwick authoritative nameservers, but this
   document does not.

7.3.  Semantics of the HSYNC Sign Field

   The Sign field is used to signal to all MSAs whether the zone owner
   requests that the DNS Provider that the MSA represents should sign
   the zone or not.  The two possible values are "YES" and "NO" where
   "YES" means that the MSA represents a currently designated signer for
   the zone and "NO" means that the MSA does not.

   When Sign=NO the MSA MUST still participate in the communication
   between MSAs for the zone, but MUST NOT instruct the COMBINER to
   update the NS RRset.

8.  Communication Between MSAs

   For the communication between MSAs there are two choices that need to
   be made among the designated MSAs for a zone.  The first is what
   "transport" to use for the communication.  The second is what
   "synchronization" model to use when executing future multi-signer
   processes.

   The two defined transport alternatives are:

   *  DNS-based communication (mandatory to support)

   *  REST API-based communication

   Each has pros and cons and at this point in time it is not clear that
   one always is better than the other.  To simplify the choice of
   transport DNS-based communication is mandatory to support and the
   REST API-based communication may only be used if all MSAs support it.
   Supported transports are signaled in the Multi-Signer EDNS(0) Option
   (see section NNN below).

   The two defined synchronization alternatives are:

   *  Leader/Follower synchronization (mandatory to support)

   *  Peer-to-Peer synchronization

   Just as for transport, supported synchronization models are signaled
   in the Multi-Signer EDNS(0) Option (see section NNN below).






Fernandez, et al.        Expires 11 August 2025                [Page 14]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   Regardless of the synchronization model and communication method
   used, the MSAs SHOULD exchange all needed information about the zone
   and the DNS Provider they represent to enable the multi-signer
   processes to execute correctly.  This includes notifications about
   changes to DNSKEYs, changes to the NS RRset, etc.  Depending on
   synchronization model it may also include instructions for changes to
   the zone.

8.1.  MSA Communication via DNS

   This transport alternative is based on the observation that all the
   communication needs between MSAs can be expressed via DNS messages.
   Notifications are sent as DNS NOTIFY messages.  Requests for changes
   to a zone are sent as DNS UPDATE messages, etc.  The sole remaining
   communication requirement is for how to communicate information about
   the current state between MSAs in an ongoing multi-signer process.
   For this reason a dedicated EDNS(0) opcode specifically for multi-
   signer synchronization is proposed.

   This model is based on [I-D.draft-berra-dnsop-keystate] that solves a
   similar problem for delegation synchronization between child and
   parent, which has already been implemented and shown to work.

8.2.  MSA Communication via REST API

   REST APIs are well-known and a natural fit for many distributed
   systems.  The challenge is mostly in the initial setup of secure
   communication.  The certificates need to be validated, preferably
   without a requirement on trusting a third party CA.  The API
   endpoints for each MSA need to be located.  Once secure communication
   has been established, using a REST API for MSA communication is
   straight-forward.

8.3.  Locating Remote Multi-Signer Agents

   When an MSA receives a zone via zone transfer from the signer it will
   analyze the zone to see whether it contains an HSYNC RRset.  If there
   is no HSYNC RRset the zone MUST be ignored by the MSA from the point-
   of-view of multi-signer synchronization.

   If, however, the zone does contain an HSYNC RRset then the MSA must
   analyze this RRset to identify the other MSAs for the zone via their
   target names in each HSYNC record.  If any of the other MSAs listed
   in the HSYNC RRset is previously unknown to this MSA then secure
   communication with this other MSA MUST be established.






Fernandez, et al.        Expires 11 August 2025                [Page 15]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   Secure communication can be achieved via various transports and it is
   up to the MSAs in the zone's HSYNC records to determine amongst
   themselves.  This document proposes two transports: "DNS" and "API".
   "DNS" is designated as as a baseline that MSAs MUST support to be
   compliant.

   The following two subsections describe the mechanism by which an MSA
   SHOULD locate a remote MSA and establish secure DNS-based and API-
   based communications, respectively.

8.3.1.  Locating a Remote DNS-Method Multi-Signer Agent

   Locating a remote MSA using the DNS mechanism consists of the
   following steps:

   *  Lookup and DNSSEC-validate a URI record for the DNS protocol for
      the HSYNC identity.  This provides the domain name and port to
      which DNS messages should be sent.

   *  Lookup and DNSSEC-validate the SVCB record of the URI record
      target to get the IP addresses to use for communication with the
      remote MSA.  If the returned SVCB record includes a "port=NNN"
      hint then this MUST be ignored.  I.e. the port to use is defined
      by the URI record.

   *  Lookup and DNSSEC-validate the KEY record of the URI record target
      name.  This enables verification of the SIG(0) public key of the
      remote MSA once communication starts.

   Example: given the following HSYNC record for a remote MSA:

   zone.example.  IN HSYNC ON AGENT YES msa.provider.com.

   The local MSA will look up the URI record for msa.provider.com:

   _dns._tcp.msa.provider.com.  IN URI 10 10
   “dns://ns.msa.provider.com:5399/” _dns._tcp.msa.provider.com.  IN
   RRSIG URI …

   which triggers a lookup for ns.msa.provider.com.  SVCB to get the
   IPv4 and IPv6 addresses as ipv4hints and ipv6hints in the response to
   the SVCB query:

   ns.msa.provider.com.  IN SVCB 1 ipv4hint=5.6.7.8 ipv6hint=2001::53
   ns.msa.provider.com.  IN RRSIG SVCB …

   and also a look up for the KEY record for ns.msa.provider.com, which
   may look like this:



Fernandez, et al.        Expires 11 August 2025                [Page 16]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   ns.msa.provider.com.  IN KEY … ns.msa.provider.com.  IN RRSIG KEY …

   Once all the DNS lookups and DNSSEC-validation of the returned data
   has been done, the local MSA is able to initiate communication with
   the remote MSA and verify the identity of the responding party via
   the validated KEY record for the remote MSAs SIG(0) public key.

8.3.2.  Locating a Remote API-Method Multi-Signer Agent

   Locating a remote MSA using the API mechanism consists of the
   following steps:

   *  Lookup and DNSSEC-validate the URI record for for the HTTPS
      protocol for the HSYNC identity.  This provides the base URL that
      will be used to construct the individual API endpoints for the
      REST API.  It also provides the port to use.

   *  Lookup and DNSSEC-validate the SVCB record for the URI record
      target.  This provides the IP-addresses to use for communication
      with the MSA.  If the returned SVCB record includes a "port=NNN"
      hint then this MUST be ignored.  I.e. the port to use is defined
      by the URI record.

   *  Lookup and DNSSEC-validate the TLSA record for the port and
      protocol specified in the URI record.  This will enable
      verification of the certificate of the remote MSA once
      communication starts.

   Example: given the following HSYNC record for a remote MSA:

   zone.example.  IN HSYNC ON AGENT YES msa.provider.com.

   the local MSA will look up the URI record for msa.provider.com:

   _https._tcp.msa.provider.com.  IN URI 10 10
   “https://api.msa.provider.com:443/api/v2/”
   _https._tcp.msa.provider.com.  IN RRSIG URI …

   which triggers a lookup for api.msa.provider.com IPv4 and IPv6
   addresses as hints in an SVCB RR:

   api.msa.provider.com.  IN SVCB 1 ipv4hint=1.2.3.4
   ipv6hint=2001::bad:cafe:443 api.msa.provider.com.  IN RRSIG SVCB …

   Now we know the IP-address and the port as well as the base URL to
   use.  Finally the TLSA record for _443._tcp.api.msa.provider.com is
   looked up, with a response that may look like this:




Fernandez, et al.        Expires 11 August 2025                [Page 17]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   _443._tcp.api.msa.provider.com.  IN TLSA 3 1 1 ….
   _443._tcp.api.msa.provider.com.  IN RRSIG TLSA …

   Once all the DNS lookups and DNSSEC-validation of the returned data
   has been done, the local MSA is able to initiate communication with
   the remote MSA and verify the identity of the responding party via
   the TLSA record for the remote MSAs certificate.

8.3.2.1.  Fallback to DNS-based Communication

   If the API-based communication fails, either because needed DNS
   records are missing, the TLSA record fails to validate the remote
   MSAs certificate or the remote MSA simply doesn't respond, the local
   MSA MUST fall back to DNS-based communication.

8.4.  The Initial HELLO Phase

   When two MSAs need to communicate with each other for the first time
   (because they are both deisgnated signers for the same zone), they
   need to establish secure communication.  This is done in a "HELLO"
   phase where the MSAs exchange information about their capabilities.

   If all the information needed for API-based transport for the remote
   party was available, the MSA SHOULD attempt an API-based HELLO.  If,
   however, this fails for some reason, it should fall back to DNS-based
   HELLO.

8.4.1.  DNS-based HELLO Phase

   When using DNS-based communication the HELLO phase is done by sending
   a NOTIFY(SOA) for the zone that triggered the need for communication.
   The NOTIFY message MUST contain a Multi-Signer EDNS(0) Option (see
   section NNN below).

   In the Multi-Signer EDNS(0) Option the OPERATION field MUST have the
   value "HELLO" (1).  Furthermore, the MSA signals its transport and
   synchronization capabilities in the TRANSPORT and SYNCHRONIZATION
   fields.  This message is signed with the SIG(0) key for the local MSA
   for which the public key is published as a KEY record for the MSA.

   In the response to the NOTIFY, the remote MSA does the same and the
   two MSAs can now verify each other's identity and are also aware of
   the other MSAs transport and synchronization capabilities.








Fernandez, et al.        Expires 11 August 2025                [Page 18]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


8.4.2.  API-based HELLO Phase

   When using API-based communication the HELLO phase is done by sending
   a REST API POST request to the remote MSA at the "/hello" endpoint.
   The request MUST contain a JSON encoded object with the following
   fields:

   *  "transport": The transport capabilities of the local MSA.

   *  "synchronization": The synchronization capabilities of the local
      MSA.

   The response MUST contain a JSON object with the following fields:

   *  "transport": The transport capabilities of the remote MSA.

   *  "synchronization": The synchronization capabilities of the remote
      MSA.

8.4.3.  Interpretation of the HELLO Responses

   Once an MSA has received HELLO responses from all other MSAs that are
   designated signers for the zone, it knows the capabilities of the
   MSAs as a group.  It can then use this information to determine which
   transport to use:

   *  If all MSAs support API-based communication, the MSAs will use
      API-based communication for this zone.

   *  If one or more MSAs only support DNS-based communication, the MSAs
      will use DNS-based communication for this zone.

   Likewise, each MSA now knows the synchronization capabilities of the
   other MSAs and can determine which synchronization model to use:

   *  If all MSAs support the Peer-to-Peer synchronization model, the
      MSAs will use the Peer-to-Peer synchronization model for this
      zone.

   *  If one or more MSAs only support the Leader/Follower
      synchronization model, the MSAs will use the Leader/Follower
      synchronization model for this zone.

8.5.  Multi-Signer EDNS(0) Option Format

   This document uses an Extended Mechanism for DNS (EDNS0) [RFC6891]
   option to include Multi-Signer synchronization information in DNS
   messages.



Fernandez, et al.        Expires 11 August 2025                [Page 19]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   This option is structured the same way as the KeyState option
   described in [I-D.draft-berra-dnsop-keystate], which has been
   implemented and shown to work for a similar use case.  The
   requirements for multi-signer synchronization are sufficiently
   different that it is not possible to re-use the KeyState OPT also for
   this purpose and therefore a new EDNS(0) option is defined here.

   The Multi-Signer EDNS(0) option is structured as follows:

                                                 1   1   1   1   1   1
         0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0:  |                            OPTION-CODE                        |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   2:  |                           OPTION-LENGTH                       |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   4:  |           OPERATION           |           TRANSPORT           |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   8:  |        SYNCHRONIZATION        |                               /
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   10: / OPERATION-BODY                                                /
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   Field definition details:

   OPTION-CODE: 2 octets / 16 bits (defined in [RFC6891]) contains the
   value TBD for Multi-Signer.

   OPTION-LENGTH: 2 octets / 16 bits (defined in [RFC6891]) contains the
   length of the payload (everything after OPTION-LENGTH) in octets and
   should be 4 plus the length of the OPERATION-BODY field (which may be
   zero octets long).

   OPERATION: 8 bits.  Signals the type of operation the message
   performs.  This document defines the two operations HELLO and
   HEARTBEAT.  For a complete distributed multi-signer specification a
   number of additional operations will need to be allocated to be able
   to describe the states in the different multi-signer processes.  This
   allocation must be done either in a revision to this document or in a
   subsequent document.

   TRANSPORT: 8 bits.  Encodes the transport capabilities of the MSA.
   With 8 bits it is possible to define up to 8 different transports of
   which this document defines two: DNS and API.







Fernandez, et al.        Expires 11 August 2025                [Page 20]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   SYNCHRONIZATION: 8 bits.  Encodes the synchronization capabilities of
   the MSA.  With 8 bits it is possible to define up to 8 different
   synchronization models of which this document defines two: Leader/
   Follower and Peer-to-Peer.

   OPERATION-BODY: Variable-length.  Used to carry operation-specific
   parameters.

8.5.1.  Encoding Transport Capabilities in the Multi-Signer EDNS(0)
        Option

   An MSA signals the union of its transport capabilities by setting the
   corresponding bits to 1.

   0: DNS transport supported (baseline, MUST be supported by all MSAs)

   1: API transport supported

   2: unused

   3: unused

   4: unused

   5: unused

   6: unused

   7: unused

8.5.2.  Encoding Synchronization Capabilities in the Multi-Signer
        EDNS(0) Option

   An MSA signals its synchronization capabilities by setting the
   corresponding bits to 1.

   0: Leader/Follower synchronization supported (baseline, MUST be
   supported by all MSAs)

   1: Peer-to-Peer synchronization supported

   2: unused

   3: unused

   4: unused

   5: unused



Fernandez, et al.        Expires 11 August 2025                [Page 21]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   6: unused

   7: unused

9.  Sequence Diagram Example of Establishing Secure Comms - "The Hello
    Phase"

   The procedure of locating another MSA and establishing a secure
   communication, referred to as "The Hello Phase" is examplified in the
   sequence diagram below.

   The procedure is as follows:

   1.  The multisigner agents receive a zone via zone transfer.  By
       analyzing the HSYNC RRset each MSA become aware of the identities
       of the other MSAs for the zone.  I.e. each MSA knows which other
       MSAs it needs to communicate with.  Communication with each of
       these, previously unknown, remote MSAs is referred to as
       "NEEDED".

   2.  Each MSA starts aquiring the information needed to establish
       secure communications with any previously unknown MSAs.  Here we
       only illustrate the baseline case where DNS-based communications
       is to be used in the following phase.  Once all needed
       information has been collected the communication with this remote
       MSA is considered to be "KNOWN".

   3.  Once an MSA has received the required information (URI, SVCB and
       KEY records in the baseline case) it sends a NOTIFY message with
       a dedicated Multi-Signer OPT code with OPERATION="HELLO".  The
       sender uses this OPT field to signal its transport and
       synchronization capabilities.  Similarly, the responder signals
       its capabilities using the same field.

   4.  When an MSA either gets a NOERROR response to its NOTIFY
       OPT(hello) message or responds with a NOERROR, it transitions out
       of "The Hello Phase" with the exchanging party and they
       transition to the next phaste where they start sending NOTIFY
       OPT(heartbeat) signals instead.  The communication with the
       remote MSA is now considered to be in the "OPERATIONAL" state.

   In the case where one MSA is aware of the need to communicate with
   another MSA, but the other is not (eg. the zone transfer was dealyed
   for one of them), the slower one SHOULD respond with a RCODE=REFUSED
   to any NOTIFY OPT(hello) it receives.  Once it is ready, it will send
   its own NOTIFY OPT(hello) which should be responded to with a
   RCODE=NOERROR.




Fernandez, et al.        Expires 11 August 2025                [Page 22]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


+----------+                 +----------+                        +----------+
|  Owner   |                 |  MSA A   |                        |  MSA B   |
+----------+                 +----------+                        +----------+
     |                            |                                    |
     |      AXFR(sign-me.se.)     |                                    |
     |--------------------------->|                                    |
     |      AXFR(sign-me.se.)     |                                    |
     |---------------------------------------------------------------->|
     |                            |                                    |
     |                            |                                    |
     |                            |  QUERY _dns._tcp.msa-b.se. URI?    |
     |                            |----------------------------------->|
     |                            |  QUERY ns.msa-b.se. SVCB?          |
     |                            |----------------------------------->|
     |                            |  QUERY ns.msa-b.se. KEY?           |
     |                            |----------------------------------->|
     |                            |                                    |
     |                            |                                    |
     |                            |  NOTIFY sign-me.se. OPT(hello)     |
     |                            |----------------------------------->|
     |                            |  NOERROR sign-me.se. OPT(hello)    |
     |                            |<-----------------------------------|
     |                            |                                    |
     |                            |                                    |
     |                            |  NOTIFY sign-me.se. OPT(heartbeat) |
     |                            |----------------------------------->|
     |                            |                                    |
     |                            |                                    |
     |                            |  NOTIFY sign-me.se. OPT(heartbeat) |
     |                            |<-----------------------------------|
     |                            |                                    |
     |                            |                                    |
     |                            |                                    |

10.  Synchronization of Changes Between MSAs

   There are two defined models for synchronization.  The first (Leader/
   Follower) has the advantage of more clearly mapping to the original
   multi-signer model 2, with a single controller.  The second model has
   the advantage of less total communication between MSAs (including no
   elections) but the potential disadvantage of more fine grained
   communication during the execution of a multi-signer process.

   At this stage it is not clear that one model is superior to the
   other.






Fernandez, et al.        Expires 11 August 2025                [Page 23]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


10.1.  Leader/Follower Mode

   In a leader/follower deployment, a designated multi-signer agent
   assumes the role of a leader, directing other agents, or followers,
   through the multi-signer process state transitions.  In this mode it
   is necessary to conduct “elections” where one of the MSAs is chosen
   as the Leader before initiating a new multi-signer process.  Once the
   Leader has been chosen, this model is mostly equivalent to the
   original multi-signer “model 2”, with a single controller.  The other
   MSAs (the followers) essentially become proxies between the
   controller (the Leader) and the DNS Provider each MSA represents.

10.2.  Peer Mode

   In peer mode, the MSAs still need to locate each other, but instead
   of relying on trust in each other, each multi-signer agent operates
   independently as a peer.  I.e. each MSA executes each step in the
   multi-signer process on its own.  The communication is essentially
   reduced to a notification mechanism (“I am now in state N”), although
   authenticated to avoid having the contents of this communication
   become an attack vector for an adversary.

10.3.  Multi-Signer State Transitions

   For the multi-signer process semantics to be fulfilled, a new state
   transition in a multi-signer process is only possible when all
   signing DNS Providers (or their MSAs) have reached the same state.

   I.e. regardless of whether each MSA traverse the finite state machine
   separately, or only the Leader does, and the Followers report back
   when they have suceeded in executing the associated Actions (as
   described in [I-D.draft-ietf-dnsop-dnssec-automation], they must not
   be further apart than one transition.

11.  Responsibilities of an MSA

   Each MSA has certain responsibilites, depending on supported
   transports and synchronization methods.

11.1.  Enabling Remote MSAs to Locate This MSA

   For a group of MSAs to be able to communicate securely and
   synchronize data for a zone, each MSA must ensure that the DNS
   records needed for secure communication with other MSAs are
   published:

   *  URI, SVCB and KEY records required for DNS-based communication
      secured by SIG(0).



Fernandez, et al.        Expires 11 August 2025                [Page 24]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   *  URI, SVCB and TLSA records required for API-based communication
      secured by TLS (if supported).

   *  All of the above MUST be published in a DNSSEC-signed zone under
      the domain name that is the identity of the MSA.

11.2.  Enabling Remote MSAs to Lookup Zone Data Added By This DNS
       Provider

   When using DNS transport between MSAs, four types of information is
   needed to be conveyed from one party to another:

   1.  Notifications (sent as DNS NOTIFY).

   2.  Retrieval of existing data (looked up via DNS QUERY).

   3.  Changes to existing data (sent as DNS UPDATE).

   4.  Multi-signer "state" information (sent via the Multi-Signer
       EDNS(0) OPT).

   The second case, i.e. looking up data for a zone that is particular
   to a specific DNS Provider is typically about the DNSKEY RRs added by
   that signer or the NS RRs representing the authoritative nameservers
   for that DNS Provider.  This is looked up under domain names
   constructed from the name of the served zone and the identity of the
   DNS Provider.

   For each zone that is managed, the MSA must ensure that the data
   needed for synchronization with other MSAs is published:

   *  The DNSKEY RRset for the zone consisting of the DNSKEYS that the
      local signer for this DNS Provider uses to sign the zone.

   *  The CDS RRset for the zone, representing the KSK that the local
      signer uses to sign the zone (when needed).

   *  The NS RRs for the zone, consisting of the NS records of the
      authoritative nameservers that this DNS Provider is responsible
      for.

   *  All of the above MUST be published in a DNSSEC-signed zone under
      the domain name that is the concatenation of the zone name and the
      identity of the MSA.  Example for the zone "zone.example" and the
      MSA "msa.provider":






Fernandez, et al.        Expires 11 August 2025                [Page 25]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   zone.example.msa.provider.  IN DNSKEY ... zone.example.msa.provider.
   IN RRSIG DNSKEY ... zone.example.msa.provider.  IN NS ...
   zone.example.msa.provider.  IN RRSIG NS ...

12.  Migration from Single-Signer to Multi-Signer

   The migration from a single-signer to a multi-signer architecture is
   done by adding the HSYNC RRset to the zone.  However, this may be
   done in several steps.

12.1.  Adding a single HSYNC record to an already signed zone

   Adding a single HSYNC record to a zone that is already signed by the
   DNS provider "provider.com" with NSMGMT=OWNER is a no-op that does
   not change anything:

   zone.example.  IN HSYNC ON AGENT YES msa.provider.com.

   The zone was already signed by the DNS provider "provider.com" and
   the provider added any needed DNSSEC records, including DNSKEYs.  The
   zone NS RRset was managed by the zone owner.  All of this is
   unchanged by the addition of the HSYNC RRset.

12.2.  Changing the HSYNC NSMGMT Field from AGENT To OWNER

   In a multi-signer architecture each MSA publishes the data it
   contributes to the zone under the domain name {zone}.{identity}. I.e.
   the zone DNSKEYs that the MSA msa.provider. uses are published as

   zone.example.msa.provider.  DNSKEY ... zone.example.msa.provider.
   DNSKEY ...

   Likewise, the NS records for the zone are published as

   zone.example.ns.msa.provider.  NS ... zone.example.ns.msa.provider.
   NS ...

   To migrate from "owner maintained" NS RRset to "MSA maintained", the
   zone owner must verify that the NS RRset as published by the MSA is
   correct and in sync with the NS RRset as published by the zone owner
   itself.  After this verification the zone owner changes the HSYNC
   NSMGMT field in the existing HSYNC record from NSMGMT=OWNER to
   NSMGMT=AGENT.








Fernandez, et al.        Expires 11 August 2025                [Page 26]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


12.3.  Migrating from a Multi-Signer Architecture Back to Single-Signer.

   If, for some reason, a zone owner wants to migrate back to a single-
   signer architecture, the process is essentially the reverse of the
   migration from single-signer to multi-signer:

   1.  The zone owner offboards all MSAs but one (the one that will be
       the single-signer)

   2.  The zone owner must verify that the NS RRset it publishes (in the
       unsigned zone) is correct and in sync with the NS RRset as
       published by the remaining MSA.

   3.  The zone owner changes the HSYNC NSMGMT field in the HSYNC record
       from NSMGMT=MSA to NSMGMT=OWNER.

   The zone is now essentially back to a single-signer architecture.
   The remaining HSYNC record may be removed from the zone.

   TO BE REMOVED BEFORE PUBLICATION: # Rationale

12.4.  Choice of the HSYNC Mnemonic

   Initially the mnemonic MSIGNER was used for the HSYNC RRset.
   However, as work progressed it became clear that we want also non-
   signing DNS Providers to be able to participate.  So the RRset is a
   signalling mehanism from zone owner to DNS Providers, some of which
   may or may not be instructed to sign the zone.  Therefore we suggest
   the mnemonic HSYNC to indicate that this is a mechanism for
   "horizontal synchronization" inside a zone.

   But the mnemonic chosen is a very minor point and should a better
   suggestion come up it would be great.

12.5.  Separation of MSA and COMBINER

   It is possible to integrate all three multi-signer components
   (SIGNER, MSA and COMBINER) into a single piece of software (or two
   pieces, depending on the preferred way of slicing the functionality).
   However, such a composite module would be a fairly complex piece of
   software.  This document aims to describe the functional separation
   of the different components rather than make a judgement on software
   design alternatives.  Hence possible implementation choices are left
   to the implementer.







Fernandez, et al.        Expires 11 August 2025                [Page 27]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


13.  Security Considerations

   Multi-signer is a complex system with a number of components and a
   significant amount of automation.  The authors believe that the only
   way to make a multi-signer architecture useful in practice is via
   automation.  However, automation is a double-edged sword.  It can
   both make the system more robust and more vulnerable.

   While all communication between MSAs is authenticated (either via
   SIG(0) signatures ore TLS), the signalling from the zone owner to the
   MSAs is via the HSYNC RRset in an unsigned zone.  This is a potential
   attack vector.  However, securing zone transfers from zone owner to
   DNS providers is a well-known issue with lots of existing solutions
   (TSIG, zone transfer via a secure channel, zone transfer-over-TLS,
   etc).  Employing some of these solutions is strongly recommended.

   From a vulnerability point-of-view this architecture introduces
   several new components into the zone signing and publication process.
   In particular the COMBINER and the MSAs are new components that need
   to be secure.  The COMBINER has the advantage of not having to
   announce its location to the outside world, as it only needs to
   communicate with internal components (the zone owner, the signer and
   the MSA).

   The MSAs are more vulnerable.  They need to be discoverable by other
   MSAs and hence they are also discoverable by an adversary.  On the
   other hand, the MSAs are not needed for a new zone to signed and
   published, they are only needed when there are changes that require
   the MSAs to synchronize, which is an infrequent event.  Furthermore,
   should an MSA be unable to fulfill its role during the execution of a
   multi-signer process, the multi-signer process will simply stop where
   it is.  Regardless of where the stop (or rather pause) occurs, the
   zone will be fully functional and once the MSA is able to resume its
   role, the multi-signer process will continue from where it left off.

14.  IANA Considerations.

   *Note to the RFC Editor*: In this section, please replace occurrences
   of "(This document)" with a proper reference.

14.1.  HSYNC RR Type

   IANA is requested to update the "Resource Record (RR) TYPEs" registry
   under the "Domain Name System (DNS) Parameters" registry group as
   follows:

   Type  HSYNC




Fernandez, et al.        Expires 11 August 2025                [Page 28]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   Value  TBD

   Meaning  Zone owner designation of DNS providers enabling mutual
      discovery

   Reference  (This document)

14.2.  New Multi-Signer EDNS Option

   This document defines a new EDNS(0) option, entitled "Multi-Signer",
   assigned a value of TBD "DNS EDNS0 Option Codes (OPT)" registry

   TO BE REMOVED UPON PUBLICATION: https://www.iana.org/assignments/dns-
   parameters/dns-parameters.xhtml#dns-parameters-11 (foo)

      +-------+--------------------+----------+----------------------+
      | Value | Name               | Status   | Reference            |
      +-------+--------------------+----------+----------------------+
      | TBD   | Multi-Signer       | Standard | ( This document )    |
      +-------+--------------------+----------+----------------------+

14.3.  A New Registry for EDNS Option Multi-Signer Operation Codes

   The Multi-Signer option also defines an 8-bit operation field, for
   which IANA is requested to create and mainain a new registry entitled
   "Multi-Signer Operations", used by the Multi-Signer option.  Initial
   values for the "Multi-Signer Operations" registry are given below;
   future assignments in in the 3-127 range are to be made through
   Specification Required review [BCP26].

+-----------+---------------------------------------------+-------------------+
| OPERATION | Mnemonic                                    | Reference         |
+-----------+---------------------------------------------+-------------------+
| 0         | forbidden                                   | ( This document ) |
+-----------+---------------------------------------------+-------------------+
| 1         | HELLO                                       | ( This document ) |
+-----------+---------------------------------------------+-------------------+
| 2         | HEARTBEAT                                   | ( This document ) |
+-----------+---------------------------------------------+-------------------+
| 3-127     | Unassigned                                  | ( This document ) |
+-----------+---------------------------------------------+-------------------+
| 128-255   | Private Use                                 | ( This document ) |
+-----------+---------------------------------------------+-------------------+

15.  References

15.1.  Normative References




Fernandez, et al.        Expires 11 August 2025                [Page 29]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <https://www.rfc-editor.org/info/rfc1996>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/info/rfc2136>.

   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
              ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
              2000, <https://www.rfc-editor.org/info/rfc2931>.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
              <https://www.rfc-editor.org/info/rfc3007>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/info/rfc6891>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8901]  Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
              Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
              DOI 10.17487/RFC8901, September 2020,
              <https://www.rfc-editor.org/info/rfc8901>.

15.2.  Informative References

   [BCP26]    Best Current Practice 26,
              <https://www.rfc-editor.org/info/bcp26>.
              At the time of writing, this BCP comprises the following:

              Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.





Fernandez, et al.        Expires 11 August 2025                [Page 30]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


   [I-D.draft-berra-dnsop-keystate]
              Bergström, E., Fernandez, L., and J. Stenstam, "Signalling
              Key State Via DNS EDNS(0) OPT", Work in Progress,
              Internet-Draft, draft-berra-dnsop-keystate-01, 7 February
              2025, <https://datatracker.ietf.org/doc/html/draft-berra-
              dnsop-keystate-01>.

   [I-D.draft-ietf-dnsop-dnssec-automation]
              Wisser, U., Huque, S., and J. Stenstam, "DNSSEC
              automation", Work in Progress, Internet-Draft, draft-ietf-
              dnsop-dnssec-automation-03, 19 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              dnssec-automation-03>.

Appendix A.  Change History (to be removed before publication)

   *  draft-leon-distributed-multi-signer-00

      Initial public draft.

Authors' Addresses

   Leon Fernandez
   The Swedish Internet Foundation
   Sweden
   Email: leon.fernandez@internetstiftelsen.se


   Erik Bergström
   The Swedish Internet Foundation
   Sweden
   Email: erik.bergstrom@internetstiftelsen.se


   Johan Stenstam
   The Swedish Internet Foundation
   Sweden
   Email: johan.stenstam@internetstiftelsen.se


   Steve Crocker
   Edgemoor Research Institute
   United States
   Email: steve@shinkuro.com







Fernandez, et al.        Expires 11 August 2025                [Page 31]


name: draft-mp-agntcy-ads
rev: 01
title: Agent Directory Service
time: 2026-02-24T22:07:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T22:07:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127577+00:00
abstract:
The Agent Directory Service (ADS) is a distributed directory service
   designed to store metadata for AI agent applications.  This metadata,
   stored as directory records, enables the discovery of agent
   applications with specific skills for solving various problems.  The
   implementation features distributed directories that interconnect
   through a content-routing protocol.

full_text:
Independent Submission                                    L. Muscariello
Internet-Draft                                                  R. Polic
Intended status: Informational                                     Cisco
Expires: 28 August 2026                                 24 February 2026


                        Agent Directory Service
                         draft-mp-agntcy-ads-01

Abstract

   The Agent Directory Service (ADS) is a distributed directory service
   designed to store metadata for AI agent applications.  This metadata,
   stored as directory records, enables the discovery of agent
   applications with specific skills for solving various problems.  The
   implementation features distributed directories that interconnect
   through a content-routing protocol.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://spec.dir.agncty.org.  Status information for this document
   may be found at https://datatracker.ietf.org/doc/draft-mp-agntcy-
   ads/.

   Source for this draft and an issue tracker can be found at
   https://github.com/agntcy/dir.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 28 August 2026.





Muscariello & Polic      Expires 28 August 2026                 [Page 1]

Internet-Draft                  agent-dir                  February 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Core Capabilities . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Architectural Foundation  . . . . . . . . . . . . . . . .   5
   3.  Storage Architecture  . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Content-Addressed Storage . . . . . . . . . . . . . . . .   5
     3.2.  OCI Integration . . . . . . . . . . . . . . . . . . . . .   6
       3.2.1.  Standards Compliance  . . . . . . . . . . . . . . . .   6
     3.3.  Record Artifact Specification . . . . . . . . . . . . . .   6
       3.3.1.  Manifest Structure  . . . . . . . . . . . . . . . . .   6
       3.3.2.  Layer Structure . . . . . . . . . . . . . . . . . . .   7
       3.3.3.  Example Record Artifacts  . . . . . . . . . . . . . .   9
       3.3.4.  Record Reconstruction . . . . . . . . . . . . . . . .  10
     3.4.  Application Integration . . . . . . . . . . . . . . . . .  10
       3.4.1.  Open Agent Schema Framework (OASF)  . . . . . . . . .  10
       3.4.2.  Third-Party Applications  . . . . . . . . . . . . . .  11
       3.4.3.  Runtime Environments  . . . . . . . . . . . . . . . .  11
     3.5.  Artifact Organization . . . . . . . . . . . . . . . . . .  11
       3.5.1.  Multi-Registry Federation . . . . . . . . . . . . . .  12
   4.  MAS Data Discovery  . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Skill Taxonomy  . . . . . . . . . . . . . . . . . . . . .  13
       4.1.1.  The Challenge of Capability Search  . . . . . . . . .  13
       4.1.2.  Taxonomy-Driven Search Optimization . . . . . . . . .  13
     4.2.  Two-Level Mapping Architecture  . . . . . . . . . . . . .  14
     4.3.  Skill Taxonomy for Search Optimization  . . . . . . . . .  14
     4.4.  Additional Taxonomies . . . . . . . . . . . . . . . . . .  15
       4.4.1.  Domain Taxonomy . . . . . . . . . . . . . . . . . . .  15
       4.4.2.  Module Taxonomy . . . . . . . . . . . . . . . . . . .  16
       4.4.3.  Multi-Dimensional Search  . . . . . . . . . . . . . .  17
       4.4.4.  Skills-to-CID Mapping . . . . . . . . . . . . . . . .  18
       4.4.5.  CID-to-PeerID Mapping . . . . . . . . . . . . . . . .  18
     4.5.  DHT-Based Discovery Process . . . . . . . . . . . . . . .  18
       4.5.1.  Skill Registration  . . . . . . . . . . . . . . . . .  19
       4.5.2.  Discovery Query Resolution  . . . . . . . . . . . . .  19
       4.5.3.  Additional Tanomoxies . . . . . . . . . . . . . . . .  20



Muscariello & Polic      Expires 28 August 2026                 [Page 2]

Internet-Draft                  agent-dir                  February 2026


     4.6.  Content Distribution via OCI Protocol . . . . . . . . . .  20
       4.6.1.  Peer-to-Peer Synchronization  . . . . . . . . . . . .  20
       4.6.2.  Distribution Strategies . . . . . . . . . . . . . . .  20
     4.7.  Agent Directory Record Examples . . . . . . . . . . . . .  23
     4.8.  Security Model  . . . . . . . . . . . . . . . . . . . . .  25
       4.8.1.  Cryptographic Integrity . . . . . . . . . . . . . . .  25
       4.8.2.  Content Provenance and Digital Signatures . . . . . .  26
       4.8.3.  Trust Boundaries and Isolation  . . . . . . . . . . .  27
       4.8.4.  Threat Mitigation . . . . . . . . . . . . . . . . . .  27
       4.8.5.  Access Control  . . . . . . . . . . . . . . . . . . .  28
       4.8.6.  Trust Boundaries  . . . . . . . . . . . . . . . . . .  28
     4.9.  Performance Optimizations . . . . . . . . . . . . . . . .  28
       4.9.1.  Bandwidth Optimization  . . . . . . . . . . . . . . .  28
       4.9.2.  Scalability Architecture  . . . . . . . . . . . . . .  28
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  29
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Introduction

   Multi-Agent Systems (MAS) represent a new paradigm in distributed
   computing where software components leverage Large Language Models
   (LLMs) to perform specialized tasks and solve complex problems
   through collaborative intelligence.  These systems combine LLMs with
   contextual knowledge and tool-calling capabilities, often abstracted
   through Model Context Protocol (MCP) servers, enabling dynamic
   workflows that adapt based on stored state and environmental
   conditions.

   The diversity and complexity of MAS architectures present unique
   challenges for discovery and composition.  As the ecosystem of AI
   agents expands, developers need efficient mechanisms to:

   *  *Discover compatible agents* with specific skills and capabilities

   *  *Evaluate performance characteristics* including cost, latency,
      and resource requirements




Muscariello & Polic      Expires 28 August 2026                 [Page 3]

Internet-Draft                  agent-dir                  February 2026


   *  *Compose multi-agent workflows* by linking agents with
      complementary capabilities

   *  *Verify claims* about agent performance and reliability

   *  *Track versioning and dependencies* between agent components

   The Agent Directory Service (ADS) [AGNTCY-ADS] addresses these
   challenges by providing a distributed directory infrastructure
   specifically designed for the agentic AI ecosystem.  Rather than
   attempting to formally define MAS architectures, which would
   constrain the creative composition patterns emerging in this rapidly
   evolving field—ADS focuses on providing flexible metadata storage and
   discovery mechanisms.  A comparison among registries which can be
   centralized or distributed is reported here [AI-Registry-Evolution].

2.1.  Core Capabilities

   ADS enables several key capabilities for the agentic AI ecosystem:

   *Capability-Based Discovery*: Agents publish structured metadata
   describing their functional abilities, costs, and performance
   characteristics.  The system organizes this information using
   hierarchical skill taxonomies, enabling efficient matching of
   capabilities to requirements.

   *Verifiable Claims*: While agent capabilities are often subjectively
   evaluated, ADS provides cryptographic mechanisms for data integrity
   and provenance tracking.  This allows users to make informed
   decisions about agent selection while enabling reputation systems to
   emerge organically.

   *Semantic Linkage*: Components can be securely linked to create
   various relationships like version histories for evolutionary
   development, collaborative partnerships where complementary skills
   solve complex problems, and dependency chains for composite agent
   workflows.

   *Distributed Architecture*: Built on proven distributed systems
   principles, ADS uses content-addressing for global uniqueness and
   implements distributed hash tables [DHT] for scalable content
   discovery across decentralized networks.









Muscariello & Polic      Expires 28 August 2026                 [Page 4]

Internet-Draft                  agent-dir                  February 2026


2.2.  Architectural Foundation

   The system leverages the Open Agentic Schema Framework (OASF) to
   model agent information in a structured, extensible format.  OASF
   enables rich queries such as "What agents can solve problem A?" or
   "What combination of skills and costs optimizes for task B?"  This
   schema-driven approach supports both objective metrics (token
   consumption, GPU requirements) and subjective evaluations (user
   ratings, task completion quality).

   Agent records are organized using modular extensions—reusable
   components like MCP server definitions, prompt-based agents, and
   evaluation metrics.  This modular approach facilitates composition
   and reuse across different MAS architectures while maintaining
   flexibility for innovative use cases.

   The underlying storage layer integrates with OCI (Open Container
   Initiative) [OCI.Image] standards, enabling interoperability with
   existing container ecosystems and leveraging mature tooling for
   content distribution and verification.

   This document details the technical architecture of ADS, covering the
   record storage layer, security model, distributed data discovery
   mechanisms, and data distribution protocols between storage nodes.

3.  Storage Architecture

   ADS implements a decentralized storage architecture built on OCI
   (Open Container Initiative) registries as the foundational object
   storage layer.  This design choice enables the system to leverage
   mature, standardized container registry infrastructure while
   achieving the speed, scalability, and security requirements of a
   distributed agent directory.

3.1.  Content-Addressed Storage

   The storage architecture centers on globally unique Content
   Identifiers (CID) that provide several critical properties for a
   distributed agent directory:

   *Immutability*: Content identifiers are cryptographically derived
   from the data they represent, ensuring that any modification results
   in a different identifier.  This property is essential for
   maintaining data integrity in agent records and enabling verifiable
   claims about agent capabilities.






Muscariello & Polic      Expires 28 August 2026                 [Page 5]

Internet-Draft                  agent-dir                  February 2026


   *Deduplication*: Identical content automatically receives the same
   identifier across all nodes in the network, eliminating storage
   redundancy and reducing bandwidth requirements when the same agent
   components are referenced by multiple systems.

   *Verifiability*: Any node can independently verify that received
   content matches its identifier, providing built-in protection against
   data corruption or tampering during transmission.

   *Location Independence*: Content can be retrieved from any node that
   possesses it, as the identifier serves as a universal pointer that
   abstracts away physical storage locations.

3.2.  OCI Integration

   ADS leverages OCI (Open Container Initiative) specifications for
   storing and distributing agent records as OCI artifacts, offering
   several advantages:

3.2.1.  Standards Compliance

   By building on OCI specifications, ADS inherits compatibility with
   the extensive ecosystem of container registry tools, security
   scanners, and management platforms.  This includes:

   *  *Authentication and authorization* mechanisms already deployed in
      enterprise environments

   *  *Content signing and verification* through tools like Notary and
      cosign

   *  *Vulnerability scanning* capabilities that can be extended to
      agent security assessments

   *  *Content delivery networks* optimized for OCI artifact
      distribution

3.3.  Record Artifact Specification

   ADS stores agent records as Record Artifacts following the OCI Image
   Manifest Specification [OCI.Manifest] and adhering to the OCI
   artifacts guidance [OCI.Artifact].  A Record Artifact is an AGNTCY
   OASF Record packaged as an OCI artifact.

3.3.1.  Manifest Structure

   The manifest structure MUST include the following properties:




Muscariello & Polic      Expires 28 August 2026                 [Page 6]

Internet-Draft                  agent-dir                  February 2026


   *  mediaType string

      This REQUIRED property MUST be application/
      vnd.oci.image.manifest.v1+json.

   *  artifactType string

      This REQUIRED property MUST be application/
      vnd.agntcy.dir.record.v1+json.  Future versions of the Record
      Artifact Specification MAY define additional artifact types.

   *  config descriptor

      This REQUIRED property MUST reference an empty configuration with
      media type application/vnd.oci.empty.v1+json, indicating that no
      additional configuration data is needed for Record Artifacts.

   *  layers array of objects

      This REQUIRED property MUST contain one or more layer descriptors
      representing OASF Record components.

   *  subject descriptor

      This OPTIONAL property MAY reference another Record Artifact to
      create linkage between records for version histories.

3.3.2.  Layer Structure

   Each layer descriptor MUST include the following properties:

   *  mediaType string

      This REQUIRED property specifies the layer content type.
      Implementations MUST support the following media types:

      -  application/vnd.agntcy.oasf.types.{version}.Record+json: The
         first layer (index 0) MUST use this media type and contains
         base record data.  This layer MUST use the data field for
         inline storage (base64-encoded) since the content is small,
         frequently accessed, and unique to each record.  Object
         annotations, schema_version and created_at are stored as part
         of layer annotations.

      -  application/vnd.agntcy.oasf.types.{version}.Skill+json:
         Contains skill definition data.  Object annotations, id and
         name are stored as part of layer annotations.




Muscariello & Polic      Expires 28 August 2026                 [Page 7]

Internet-Draft                  agent-dir                  February 2026


      -  application/vnd.agntcy.oasf.types.{version}.Domain+json:
         Contains domain definition data.  Object annotations, id and
         name are stored as part of layer annotations.

      -  application/vnd.agntcy.oasf.types.{version}.Locator+json:
         Contains locator definition data referencing the location where
         the agent can be accessed or deployed.  Object annotations,
         type and url are stored as part of layer annotations and URL
         fields.

      -  application/vnd.agntcy.oasf.types.{version}.Module+json:
         Contains module definition data.  Object annotations, id and
         name are stored as part of layer annotations.

      Media types MUST map to application/
      vnd.{schema_uri}.{version}.{type}+{encoding} format, where -
      {schema_uri} corresponds to the OASF protobuf schema namespace -
      {version} corresponds to a specific OASF type version (e.g.,
      v1alpha2) - {type} is the OASF type name (e.g. Record) -
      {encoding} MUST be json

   *  urls array of strings

      This OPTIONAL property MAY contain URLs pointing to external
      resources, particularly useful for Locator layers to specify
      deployment targets.

   *  annotations string-string map

      This OPTIONAL property contains arbitrary attributes.
      Implementations SHOULD use the predefined annotation keys:

      -  agntcy.oasf.record/schema_version: Schema version (for Record
         layers)

      -  agntcy.oasf.record/created_at: Creation timestamp (for Record
         layers)

      -  agntcy.oasf.locator/type: Locator type (for Locator layers)

      -  agntcy.oasf.skill/{id,name}: Skill id/name (for Skill layers)

      -  agntcy.oasf.domain/{id,name}: Domain id/name (for Domain
         layers)

      -  agntcy.oasf.module/{id,name}: Module id/name (for Module
         layers)




Muscariello & Polic      Expires 28 August 2026                 [Page 8]

Internet-Draft                  agent-dir                  February 2026


3.3.3.  Example Record Artifacts

   {
     "schemaVersion": 2,
     "mediaType": "application/vnd.oci.image.manifest.v1+json",
     "artifactType": "application/vnd.agntcy.dir.record.v1+json",
     "config": {
       "mediaType": "application/vnd.oci.empty.v1+json",
       "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
       "size": 2
     },
     "layers": [
       {
         "mediaType": "application/vnd.agntcy.oasf.types.v1alpha2.Record+json",
         "data": "<BASE64_ENCODED_RECORD_DATA>",
         "digest": "sha256:d5815835051dd97d800a03f641ed8162877920e734d3d705b698912602b8c763",
         "size": 216,
         "annotations": {
           "agntcy.oasf.record/schema_version": "0.7.0",
           "agntcy.oasf.record/created_at": "2026-01-06T00:00:00Z"
         }
       },
       {
         "mediaType": "application/vnd.agntcy.oasf.types.v1alpha2.Skill+json",
         "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
         "size": 2,
         "annotations": {
           "agntcy.oasf.skill/id": "10201",
           "agntcy.oasf.skill/name": "Natural Language Processing/Sentiment Analysis"
         }
       },
       {
         "mediaType": "application/vnd.agntcy.oasf.types.v1alpha2.Locator+json",
         "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
         "size": 2,
         "urls": [
           "https://ghcr.io/agntcy/agent:latest",
           "ipfs://bafybeibwzif37xyzabcdefg"
         ],
         "annotations": {
           "agntcy.oasf.locator/type": "docker-image"
         }
       }
     ],
     "subject": {
       "mediaType": "application/vnd.oci.image.manifest.v1+json",
       "artifactType": "application/vnd.agntcy.dir.record.v1+json",
       "digest": "sha256:7e346bc58473bc1d8a98776fa2a89a3e2a446b27f0e8a33ad49c3d4f28b6471d",



Muscariello & Polic      Expires 28 August 2026                 [Page 9]

Internet-Draft                  agent-dir                  February 2026


       "size": 702
     }
   }

3.3.4.  Record Reconstruction

   Applications consuming Record Artifacts MUST implement the following
   reconstruction algorithm:

   1.  *Pull Manifest*: Retrieve the OCI image manifest from the
       registry using standard OCI Distribution API operations

   2.  *Extract Base Record*: Parse the first layer (index 0) with media
       type application/vnd.agntcy.oasf.types.{version}.Record+json and
       base64-decode the data field to obtain the base record JSON data

   3.  *Retrieve Component Layers*: For each subsequent layer (Skill,
       Domain, Locator, Module):

       *  Fetch the blob content from the registry using the layer's
          digest

       *  Verify the blob's SHA-256 digest matches the descriptor's
          digest field

       *  Parse the JSON content according to the layer's mediaType

       *  Merge the component data into the appropriate field of the
          base record

       *  Merge descriptor annotations into the corresponding component
          metadata

   4.  *Validate Schema*: Validate the reconstructed record against the
       OASF schema version specified in the agntcy.oasf.record/
       schema_version annotation

3.4.  Application Integration

3.4.1.  Open Agent Schema Framework (OASF)

   The Open Agent Schema Framework (OASF) [AGNTCY-OASF] complements
   Record Artifact Specification by defining the actual data models for
   agent-related information referenced in the OCI artifacts.







Muscariello & Polic      Expires 28 August 2026                [Page 10]

Internet-Draft                  agent-dir                  February 2026


3.4.2.  Third-Party Applications

   Third-party applications can build on top of the Record Artifact
   Specification to create tools and services for managing,
   distributing, and utilizing agent records.  This can be accomplished
   by leveraging existing OCI ecosystem components such as registries,
   clients, and tooling, or by developing custom solutions that link to
   Record Artifacts.

3.4.3.  Runtime Environments

   Runtime environments that deploy and manage agents can leverage
   Record Artifacts to obtain the necessary information for launching
   and managing agent instances based on the definitions contained
   within the artifacts.  Implementations can provide management of
   process lifecycles, monitoring, and other capabilities based on the
   metadata defined in the records, or by linking records with runtime-
   specific artifacts.

3.5.  Artifact Organization

   Agent records are stored as OCI artifacts with a structured
   organization.  Records MUST be addressed by digest for immutable
   retrieval.  Tags are mutable aliases and can be used as human-
   readable pointers, but implementations MUST NOT assume a tag resolves
   to more than one manifest at a time.  The examples below show digest-
   pinned references:

   null_repo/records/
   ├── skills/
   │   ├── natural_language_processing/
   │   │   ├── sentiment-analysis:bert-v1@sha256:abc123...
   │   │   ├── sentiment-analysis:roberta-v1@sha256:def456...
   │   │   ├── sentiment-analysis:distilbert-v1@sha256:ghi789...
   │   │   ├── text-classification:bert-v2@sha256:abc123...
   │   │   └── emotion-detection:bert-v1@sha256:abc123...
   │   ├── images_computer_vision/
   │   │   ├── object-detection:yolo-v2.1@sha256:jkl012...
   │   │   ├── object-detection:rcnn-v2.1@sha256:mno345...
   │   │   └── scene-understanding:yolo-v1@sha256:jkl012...
   │   └── analytical_skills/
   │       └── mathematical:v1.5.0@sha256:pqr678...
   ├── evaluations/
   │   ├── performance-metrics:latest@sha256:stu901...
   │   └── benchmark-results:v1.0.0@sha256:vwx234...
   └── compositions/
       ├── security-analyst:v3.0.0@sha256:yza567...
       └── research-assistant:v2.2.0@sha256:bcd890...



Muscariello & Polic      Expires 28 August 2026                [Page 11]

Internet-Draft                  agent-dir                  February 2026


   This naming scheme demonstrates that the same content identifier can
   belong to multiple skills, reflecting the reality that many AI agents
   are multi-capable.  For example, the BERT-based agent
   (sha256:abc123...) appears under multiple skill categories:
   natural_language_processing/sentiment-analysis,
   natural_language_processing/text-classification, and
   natural_language_processing/emotion-detection, representing different
   capabilities of the same underlying agent implementation.  Similarly,
   the YOLO vision model (sha256:jkl012...) provides both object-
   detection and scene-understanding capabilities under
   images_computer_vision.

   This cross-referencing approach allows agents to be discovered
   through any of their supported capabilities while maintaining unique
   addressability through content identifiers.  Each skill category can
   have its own versioning and metadata, enabling fine-grained
   capability management even when multiple skills share the same
   underlying implementation.

   Each artifact contains structured metadata following OASF schemas,
   enabling rich queries and capability matching across all variants
   within a given category.

3.5.1.  Multi-Registry Federation

   The architecture supports federation across multiple registry
   instances, enabling:

   *  *Organizational boundaries*: Different organizations can maintain
      their own registries while participating in the global directory

   *  *Geographic distribution*: Content can be replicated to registries
      closer to consumers, reducing latency

   *  *Specialization*: Registries can focus on specific domains (e.g.,
      medical AI agents, financial analysis tools)

   *  *Redundancy*: Critical agent records can be replicated across
      multiple registries for availability

4.  MAS Data Discovery

   ADS implements a two-level mapping system that enables efficient
   discovery of Multi-Agent System components through a distributed hash
   table [DHT] architecture.  This approach separates capability-based
   discovery from content location, providing both scalability and
   flexibility in agent retrieval.




Muscariello & Polic      Expires 28 August 2026                [Page 12]

Internet-Draft                  agent-dir                  February 2026


4.1.  Skill Taxonomy

   Effective agent discovery in multi-agent systems requires
   sophisticated organization of capabilities and skills.  ADS employs a
   hierarchical skill taxonomy that serves as the foundation for
   efficient search and discovery operations across the distributed
   network.

4.1.1.  The Challenge of Capability Search

   Traditional keyword-based search approaches face significant
   limitations when applied to agent discovery:

   *Vocabulary Fragmentation*: Different publishers may describe similar
   capabilities using varying terminology.  For example, "sentiment
   analysis," "opinion mining," and "emotional classification" may all
   refer to similar agent capabilities, leading to search results that
   miss relevant agents due to terminology mismatches.

   *Scale Complexity*: As the number of agents in the ecosystem grows,
   exhaustive search across all records becomes computationally
   prohibitive.  Without structured organization, every query
   potentially requires examining every agent record, leading to poor
   performance characteristics.

   *Semantic Relationships*: Many agent capabilities have natural
   hierarchical relationships that flat keyword systems cannot capture.
   An agent capable of "named entity recognition" is inherently relevant
   to searches for broader "text analysis" capabilities, but keyword
   matching alone cannot establish these connections.

4.1.2.  Taxonomy-Driven Search Optimization

   ADS addresses these challenges through a structured hierarchical
   taxonomy that provides several critical optimization benefits:

   *Search Space Partitioning*: The taxonomy enables efficient
   partitioning of the search space.  When processing a query for
   "computer vision" capabilities, the system can immediately focus on
   the relevant taxonomy branch, eliminating the need to examine agents
   in unrelated categories like natural language processing or
   mathematical reasoning.

   *Index Structure Optimization*: The hierarchical organization allows
   the distributed hash table to create specialized indices for
   different taxonomy branches.  Rather than maintaining a single
   massive index, the DHT can distribute indexing responsibility across
   nodes, with each node specializing in specific capability domains.



Muscariello & Polic      Expires 28 August 2026                [Page 13]

Internet-Draft                  agent-dir                  February 2026


   *Query Semantic Expansion*: The taxonomy enables intelligent query
   expansion where searches automatically include semantically related
   subcategories.  A search for "text analysis" can transparently
   include results from "sentiment analysis," "entity extraction," and
   "text classification" without requiring users to explicitly enumerate
   all relevant subcategories.

   *Standardized Vocabulary*: By providing a canonical taxonomy, ADS
   reduces terminology fragmentation.  Publishers are encouraged to tag
   their agents using standardized skill categories, improving search
   precision and recall across the ecosystem.

4.2.  Two-Level Mapping Architecture

   The discovery system operates through two distinct mapping layers:

4.3.  Skill Taxonomy for Search Optimization

   ADS employs a hierarchical skill taxonomy to optimize search
   performance and enable efficient capability-based discovery.
   Taxonomies provide several critical advantages for agent discovery
   systems:

   *Search Space Reduction*: Rather than performing exhaustive searches
   across all agent records, taxonomies allow the system to quickly
   narrow the search space to relevant categories.  When a user queries
   for "natural language processing" capabilities, the system can
   immediately identify the subset of agents tagged with NLP skills
   without examining agents focused on computer vision or mathematical
   reasoning.

   *Hierarchical Organization*: Skills are organized in a tree-like
   structure *that reflects natural relationships between capabilities.
   For example:

   Natural Language Processing
   ├── Text Analysis
   │   ├── Sentiment Analysis
   │   ├── Named Entity Recognition
   │   └── Text Classification
   ├── Language Generation
   │   ├── Text Summarization
   │   ├── Content Creation
   │   └── Translation
   └── Conversational AI
       ├── Dialogue Management
       ├── Intent Recognition
       └── Response Generation



Muscariello & Polic      Expires 28 August 2026                [Page 14]

Internet-Draft                  agent-dir                  February 2026


   This hierarchy enables both specific queries ("sentiment analysis
   agents") and broader capability searches ("all natural language
   processing agents") while maintaining efficient indexing structures.

   *Query Expansion and Refinement*: Taxonomies support automatic query
   expansion *where searches for parent categories can include relevant
   child categories.  A *query for "text analysis" can automatically
   include agents tagged with *"sentiment analysis," "named entity
   recognition," and "text classification" *without requiring users to
   know all specific subcategories.

   *Semantic Consistency*: Standardized taxonomies reduce ambiguity and
   improve *search precision by providing consistent terminology across
   the ecosystem.  This *prevents fragmentation where similar
   capabilities are described using different *terms by different
   publishers.

   *Scalable Indexing*: The hierarchical structure enables efficient
   distributed *indexing where different DHT nodes can specialize in
   specific taxonomy *branches, distributing both storage load and query
   processing across the *network.

4.4.  Additional Taxonomies

   While skills form the primary taxonomy for capability-based
   discovery, ADS supports multiple parallel taxonomies to enable rich,
   multi-dimensional agent classification and search.

4.4.1.  Domain Taxonomy

   The domain taxonomy organizes agents by their application domains,
   representing the broader problem spaces or industries where agents
   are designed to operate:


















Muscariello & Polic      Expires 28 August 2026                [Page 15]

Internet-Draft                  agent-dir                  February 2026


   Application Domains
   ├── Networking
   │   ├── Network Configuration
   │   ├── Traffic Analysis
   │   └── Protocol Implementation
   ├── Security
   │   ├── Threat Detection
   │   ├── Vulnerability Assessment
   │   └── Access Control
   ├── Software Development
   │   ├── Code Generation
   │   ├── Testing Automation
   │   └── Documentation
   ├── Finance and Business
   │   ├── Risk Analysis
   │   ├── Market Research
   │   └── Process Automation
   └── Healthcare
       ├── Medical Imaging
       ├── Clinical Decision Support
       └── Drug Discovery

   Domain classification enables users to discover agents that are
   specifically tuned for their operational context, even if those
   agents share similar underlying skills with agents from other
   domains.

4.4.2.  Module Taxonomy

   The module taxonomy categorizes agents by the OASF modules they
   implement, facilitating the discovery of agents compatible with
   specific system architectures.  Modules are organized into the OASF
   module categories (Core and Integration), and each module captures a
   structured integration surface or capability extension:

   The Agent Spec module aligns with the Open Agent Spec specification
   [Oracle-AgentSpec].

   Modules
   ├── Core
   │   ├── Language Model (`language_model`)
   │   ├── Evaluation (`evaluation`)
   │   └── Observability (`observability`)
   └── Integration
     ├── MCP (Model Context Protocol, `mcp`)
     ├── A2A (Agent-to-Agent Communication, `a2a`)
     ├── Agent Spec (`agentspec`)
     └── ACP (`acp`, deprecated)



Muscariello & Polic      Expires 28 August 2026                [Page 16]

Internet-Draft                  agent-dir                  February 2026


   Module identifiers use the OASF module name values.  The acp module
   is deprecated in OASF; use a2a when possible.

4.4.3.  Multi-Dimensional Search

   The parallel taxonomy system enables sophisticated multi-dimensional
   queries that combine criteria across different classification axes.
   *All searches must include at least one skill criterion as the
   mandatory foundation*, with domain and module taxonomies providing
   additional filtering dimensions:

   *  *Skill + Domain*: "Find natural language processing agents
      specialized for healthcare applications"

   *  *Skill + Module*: "Discover computer vision agents that support
      MCP integration"

   *  *Skill + Module + Domain*: "Locate natural language processing
      agents with observability modules for manufacturing applications"

   *Skills as Search Foundation*: The skills taxonomy serves as the
   primary index structure in the DHT, making skill-based criteria
   mandatory for efficient query resolution.  This design ensures that:

   *  *Query Performance*: All searches leverage the optimized skills-
      to-CID mapping as the starting point, providing consistent
      performance characteristics

   *  *Result Relevance*: Domain and module filters are applied to
      skill-based result sets, ensuring functional capability remains
      the core selection criterion

   *  *Index Efficiency*: The DHT can optimize storage and lookup
      patterns around the skills taxonomy while supporting supplementary
      filtering through domains and modules

   Domain-only or module-only queries are not supported, as they would
   bypass the primary indexing structure and provide results that may
   not have the functional capabilities required by the requesting
   system.

   This multi-taxonomic approach provides the flexibility to support
   diverse use cases while maintaining efficient indexing and search
   performance across all dimensions.







Muscariello & Polic      Expires 28 August 2026                [Page 17]

Internet-Draft                  agent-dir                  February 2026


4.4.4.  Skills-to-CID Mapping

   The first level maps agent capabilities and skills to their
   corresponding Content Identifiers (CID):

Skills Index:
"natural_language_processing" → ["sha256:abc123...", "sha256:def456...", "sha256:ghi789..."]
"images_computer_vision"      → ["sha256:jkl012...", "sha256:mno345..."]
"analytical_skills"           → ["sha256:pqr678...", "sha256:abc123..."]
"multi_modal"                 → ["sha256:stu901...", "sha256:vwx234..."]

   This mapping enables queries such as "find all agents capable of
   natural language processing" to quickly resolve to a set of content
   identifiers without needing to search through individual agent
   records.

4.4.5.  CID-to-PeerID Mapping

   The second level maps Content Identifiers to the Peer IDs of nodes
   that store the corresponding agent records:

Content Location Index:
"sha256:abc123..." → ["12D3KooWBhvxmvKvTYGJvXjnGBp7Ybr9WyoXkZvFnRtC4aBcDeFg",
                      "12D3KooWXyZrUvHzPqKvTYGJvXjnGBp7Ybr9WyoXkZvFnRtC5gHi"]
"sha256:jkl012..." → ["12D3KooWZaBcDeFgXyZrUvHzPqKvTYGJvXjnGBp7Ybr9WyoXkZvF",
                      "12D3KooWGHiJkLmNoPqRsTuVwXyZ123456789AbCdEfGhIjKlMnO"]

   This separation allows the system to: - *Optimize for capability
   queries* without requiring knowledge of data locations

   *  *Enable dynamic content replication* as peer availability changes

   *  *Support multiple storage strategies* for the same content across
      different peers

4.5.  DHT-Based Discovery Process

   The Distributed Hash Table stores and maintains both mapping layers
   across the network:

   ADS uses [Kad-DHT] [DHT] for server and content discovery by using
   the libp2p implementation that constitutes the IPFS core DHT
   [libp2p-kad-dht].








Muscariello & Polic      Expires 28 August 2026                [Page 18]

Internet-Draft                  agent-dir                  February 2026


                                +----------------+
                                |    DHT Node    |
                                | Content Index  |
                                +----------------+
                                       ^
                                       |
                      +----------------+-----------------+
                      |                |                |
              +-------v------+  +------v-------+  +-----v--------+
              | Server Node A |  | Server Node B|  | Server Node C|
              |   Content X  |  |   Content Y  |  |   Content Z  |
              +-------+------+  +------+-------+  +------+-------+
                      |               |                  |
                      |        Content Exchange          |
                      +---------------+------------------+
                                     |
                             Content Replication

   Flow:
   1. Servers register content with DHT
   2. DHT maintains content-to-server mappings
   3. Servers query DHT to locate content
   4. DHT returns list of servers hosting content
   5. Servers download content from peers

4.5.1.  Skill Registration

   When agents are published to the network:

   1.  *Capability Extraction*: The system parses OASF records to
       extract skills, domains, and modules

   2.  *DHT Updates*: Skills-to-CID mappings are distributed across DHT
       nodes using consistent hashing

   3.  *Location Registration*: Peer nodes register themselves as
       providers for specific CIDs

4.5.2.  Discovery Query Resolution

   Agent discovery follows a three-phase process:

   1.  *Capability Resolution*: Query "agents with skill X" resolves to
       a list of relevant CIDs via DHT lookup

   2.  *Location Resolution*: For each discovered CID, query DHT to find
       peer nodes storing the content




Muscariello & Polic      Expires 28 August 2026                [Page 19]

Internet-Draft                  agent-dir                  February 2026


   3.  *Result Aggregation*: Combine capability matches with location
       information to produce actionable discovery results

Discovery Flow:
Query: "natural_language_processing" AND "finance_and_banking"
   ↓
Phase 1: Skills → CIDs
   DHT["natural_language_processing"] → ["sha256:abc123...", "sha256:def456..."]
   DHT["finance_and_banking"] → ["sha256:abc123...", "sha256:yza567..."]
   Intersection → ["sha256:abc123..."]
   ↓
Phase 2: CIDs → Peer IDs
   DHT["sha256:abc123..."] → ["12D3KooW...", "12D3KooX..."]
   ↓
Result: Agent sha256:abc123... available from peers 12D3KooW... and 12D3KooX...

4.5.3.  Additional Tanomoxies

4.6.  Content Distribution via OCI Protocol

   Once discovery identifies the relevant CIDs and their hosting peers,
   the actual agent records are retrieved using the OCI distribution
   protocol:

4.6.1.  Peer-to-Peer Synchronization

   The discovered list of CIDs enables efficient content synchronization
   [OCI.Distribution] between peers:

   1.  *Content Negotiation*: Requesting peer queries hosting peers for
       available agent records

   2.  *OCI Pull Operations*: Standard OCI registry pull commands
       retrieve agent artifacts and metadata

   3.  *Incremental Sync*: Only missing or updated content is
       transferred, reducing bandwidth requirements

   4.  *Verification*: Content integrity is verified through
       cryptographic hash validation during transfer

4.6.2.  Distribution Strategies

   The system supports multiple distribution patterns, each with
   distinct trade-offs and operational considerations:

   *On-Demand Retrieval*: Records are pulled from remote peers only when
   specifically requested, minimizing local storage requirements.



Muscariello & Polic      Expires 28 August 2026                [Page 20]

Internet-Draft                  agent-dir                  February 2026


   _Trade-offs_: While this approach minimizes storage costs and ensures
   fresh content, it introduces several challenges:

   *  *Query Latency*: Each request requires network round-trips to
      locate and retrieve content, increasing response times

   *  *Network Cost*: Spurious or exploratory requests generate
      unnecessary network traffic and computational overhead

   *  *DoS Vulnerability*: The system becomes susceptible to denial-of-
      service attacks where malicious actors can trigger expensive
      content retrieval operations by flooding the network with requests
      for non-existent or rarely-accessed agents

   *  *Scalability Limits*: Performance degrades as the network grows
      due to increased query coordination overhead

   *Proactive Caching*: Popular or frequently accessed agents are
   automatically replicated to improve query response times.

   _Trade-offs_: This strategy offers significant scalability benefits
   but requires sophisticated management:

   *  *Performance Gains*: Dramatic reduction in query latency for
      popular content, enabling sub-second response times

   *  *Scalability*: Can handle high query volumes efficiently once
      popular content is cached locally

   *  *Popularity Measurement*: Requires implementing metrics collection
      and analysis to identify which agents warrant caching.  This
      includes tracking query frequencies, download patterns, and usage
      statistics across the network

   *  *Storage Requirements*: Needs sufficient local storage capacity to
      maintain cached copies of popular records

   *  *Cache Management*: Must implement cache eviction policies,
      freshness validation, and synchronization mechanisms

   *  *Administrator Oversight*: Proactive caching policies must be
      configured and monitored by agent directory node administrators to
      balance storage costs with performance benefits

   *Strategic Replication*: Critical agents can be replicated across
   multiple peers to ensure high availability and reduce single points
   of failure.




Muscariello & Polic      Expires 28 August 2026                [Page 21]

Internet-Draft                  agent-dir                  February 2026


   _Trade-offs_: This approach addresses availability concerns but
   introduces subjective complexity:

   *  *High Availability*: Ensures critical agents remain accessible
      even during peer failures or network partitions

   *  *Reduced Single Points of Failure*: Distributes risk across
      multiple storage locations

   *  *Subjective Criticality*: The definition of "critical" or "useful"
      agents varies significantly between users, organizations, and use
      cases.  What constitutes strategic value for financial services
      may be irrelevant for manufacturing applications

   *  *Administrative Burden*: Requires agent directory node
      administrators to make strategic decisions about which agents
      warrant replication, considering factors like:

      -  Organizational priorities and business requirements

      -  Compliance and regulatory considerations

      -  Cost-benefit analysis of storage versus availability

      -  Community consensus on agent importance

   *  *Resource Allocation*: Strategic replication consumes storage
      resources that could otherwise be used for proactive caching of
      popular content

   *Administrative Management*: Both Proactive Caching and Strategic
   Replication require active management by agent directory node
   administrators.  Administrators must:

   *  Configure caching policies based on local network characteristics
      and storage capacity

   *  Monitor popularity metrics and adjust caching strategies
      accordingly

   *  Define strategic replication criteria aligned with organizational
      objectives

   *  Balance resource allocation between different distribution
      strategies

   *  Implement governance policies for content lifecycle management




Muscariello & Polic      Expires 28 August 2026                [Page 22]

Internet-Draft                  agent-dir                  February 2026


   This architecture provides a scalable foundation for MAS data
   discovery that can efficiently handle large networks of distributed
   agents while maintaining low latency for capability-based queries.

4.7.  Agent Directory Record Examples

   The following examples illustrate the structure of OASF-compliant
   agent records stored in the directory:

{
  "content_id": "sha256:abc123...",
  "record": {
    "name": "BERT Sentiment Analyzer",
    "version": "1.0.0",
    "schema_version": "0.2.0",
    "description": "Multi-capability NLP agent providing sentiment analysis, text classification, and emotion detection",
    "skills": ["natural_language_processing"],
    "domains": ["finance_and_banking", "legal_and_compliance"],
    "modules": ["mcp", "observability"],
    "capabilities": {
      "threads": true,
      "interrupt_support": false,
      "callbacks": true,
      "streaming": ["text", "json"]
    }
  },
  "performance_metrics": {
    "tokens_per_second": 1000,
    "gpu_memory_mb": 4096,
    "latency_p99_ms": 150,
    "accuracy_score": 0.94
  },
  "evaluation_data": {
    "overall_rating": 4.2,
    "cost_per_million_tokens": 2.50
  },
  "registries": [
    "registry.example.com",
    "hub.agents.org"
  ],
  "last_updated": "2025-08-07T10:30:00Z"
}









Muscariello & Polic      Expires 28 August 2026                [Page 23]

Internet-Draft                  agent-dir                  February 2026


{
  "content_id": "sha256:jkl012...",
  "record": {
    "name": "YOLO Vision Agent",
    "version": "2.1.0",
    "schema_version": "0.2.0",
    "description": "Computer vision agent for object detection and scene understanding",
    "skills": ["images_computer_vision"],
    "domains": ["transportation_logistics_mobility", "manufacturing_and_industrial_operations"],
    "modules": ["agentspec", "observability"],
    "capabilities": {
      "threads": false,
      "interrupt_support": true,
      "callbacks": false,
      "streaming": ["image", "json"]
    }
  },
  "performance_metrics": {
    "inference_fps": 30,
    "gpu_memory_mb": 8192,
    "detection_accuracy_map": 0.89,
    "processing_latency_ms": 33
  },
  "evaluation_data": {
    "overall_rating": 4.7,
    "cost_per_image": 0.05
  },
  "registries": [
    "vision.agents.com",
    "registry.example.com"
  ],
  "last_updated": "2025-08-07T14:20:00Z"
}


















Muscariello & Polic      Expires 28 August 2026                [Page 24]

Internet-Draft                  agent-dir                  February 2026


{
  "content_id": "sha256:pqr678...",
  "record": {
    "name": "Mathematical Reasoning Agent",
    "version": "1.5.0",
    "schema_version": "0.2.0",
    "description": "Agent specialized in mathematical problem solving and analytical reasoning",
    "skills": ["analytical_skills", "natural_language_processing"],
    "domains": ["education", "finance_and_banking"],
    "modules": ["a2a", "evaluation"],
    "capabilities": {
      "threads": true,
      "interrupt_support": true,
      "callbacks": true,
      "streaming": ["text", "latex"]
    }
  },
  "performance_metrics": {
    "problems_per_minute": 12,
    "cpu_cores": 4,
    "memory_mb": 2048,
    "accuracy_on_gsm8k": 0.87
  },
  "evaluation_data": {
    "overall_rating": 4.5,
    "cost_per_problem": 0.10
  },
  "registries": [
    "math.agents.edu",
    "registry.example.com"
  ],
  "last_updated": "2025-08-07T16:45:00Z"
}

   These examples demonstrate how the DHT indexing system extracts
   skills and domains from agent records to populate the Skills-to-CID
   mappings, enabling efficient capability-based discovery across the
   distributed network.

4.8.  Security Model

   The OCI-based architecture provides multiple layers of security that
   address the unique challenges of distributed agent directories:

4.8.1.  Cryptographic Integrity

   ADS leverages the OCI layer's built-in cryptographic mechanisms to
   ensure data integrity:



Muscariello & Polic      Expires 28 August 2026                [Page 25]

Internet-Draft                  agent-dir                  February 2026


   *Automatic Hash Computation*: The OCI registry layer automatically
   computes SHA-256 hash digests for all stored artifacts.  These
   content identifiers are generated transparently during the push
   operation, ensuring that every agent record has a cryptographically
   verifiable fingerprint without additional overhead.

   *Tamper Detection*: Content addressing ensures immediate tamper
   detection through cryptographic hash verification.  Any modification
   to an agent record—whether malicious or accidental—results in a
   different hash digest, making unauthorized changes immediately
   detectable during retrieval operations.

   *End-to-End Verification*: Clients can independently verify that
   received content matches its advertised identifier, providing built-
   in protection against data corruption during transmission or storage
   without trusting intermediate network components.

4.8.2.  Content Provenance and Digital Signatures

   ADS integrates with Sigstore, a security framework for OCI storage,
   to provide comprehensive content provenance and authenticity
   guarantees:

   *Sigstore Integration*: The system leverages Sigstore's security
   framework to provide verifiable proof of when and by whom agent
   records were signed.  This creates an immutable audit trail that
   cannot be retroactively modified, enabling forensic analysis of agent
   deployment history.

   *Keyless Signing*: Sigstore's keyless signing approach eliminates the
   complexity and security risks associated with long-lived
   cryptographic keys:

   *  *Identity-Based Authentication*: Uses OpenID Connect (OIDC)
      [OpenID.Auth] tokens from trusted identity providers (GitHub,
      Google, Microsoft) to authenticate publishers at signing time

   *  *Short-Lived Certificates*: Issues ephemeral signing certificates
      valid only for minutes, reducing the window of potential key
      compromise

   *  *Automatic Key Rotation*: Eliminates the need for manual key
      management, distribution, and rotation procedures

   *  *Scalable Trust*: Publishers don't need to maintain or distribute
      public keys, making the system accessible to individual developers
      and large organizations alike




Muscariello & Polic      Expires 28 August 2026                [Page 26]

Internet-Draft                  agent-dir                  February 2026


   *Transparency and Verification*: All signatures are stored directly
   in OCI storage alongside the agent artifacts and public keys,
   providing:

   *  *Public Auditability*: Anyone can verify the signing history of
      agent records stored in accessible registries

   *  *Non-Repudiation*: Publishers cannot deny having signed records
      that are cryptographically linked to their identity

   *  *Supply Chain Security*: Enables detection of compromised or
      unauthorized agent publications

4.8.3.  Trust Boundaries and Isolation

   *Organizational Isolation*: Separate registries maintain security
   boundaries between different organizations, allowing each entity to
   control their own agent ecosystem while still participating in the
   broader federated network.

   *Content Verification*: Nodes can validate artifact integrity and
   signature authenticity without trusting transport layers or
   intermediate storage systems.  This zero-trust approach ensures
   security even when using untrusted storage infrastructure.

   *Reputation Systems*: The cryptographic foundation enables the
   development of reputation systems based on verifiable evidence rather
   than subjective claims.  Publishers with consistent signing practices
   and high-quality agents can build measurable trust over time.

4.8.4.  Threat Mitigation

   The security model addresses several key threats to distributed agent
   directories:

   *Supply Chain Attacks*: Sigstore integration and transparency logs
   make it difficult for attackers to inject malicious agents without
   detection, as all publications are cryptographically signed and
   publicly auditable.

   *Data Integrity Attacks*: Automatic hash verification prevents
   tampering with agent records during storage or transmission, ensuring
   users receive authentic content.

   *Identity Spoofing*: OIDC-based keyless signing prevents attackers
   from impersonating legitimate publishers without compromising their
   identity provider credentials.




Muscariello & Polic      Expires 28 August 2026                [Page 27]

Internet-Draft                  agent-dir                  February 2026


   *Availability Attacks*: The distributed nature of the system,
   combined with content replication across multiple registries,
   provides resilience against denial-of-service attacks targeting
   individual nodes.

4.8.5.  Access Control

   *  *Registry-level permissions* control who can publish and retrieve
      agent records

   *  *Fine-grained policies* can restrict access to specific agent
      categories or capability types

   *  *Audit trails* leverage existing registry logging capabilities to
      track access patterns

4.8.6.  Trust Boundaries

   *  *Organizational isolation* through separate registries maintains
      security boundaries

   *  *Content verification* allows nodes to validate artifact integrity
      without trusting transport layers

   *  *Reputation systems* can build on cryptographic proofs of past
      agent performance

4.9.  Performance Optimizations

   The architecture incorporates several optimizations for the specific
   requirements of agent discovery:

4.9.1.  Bandwidth Optimization

   *  *Incremental updates* use OCI layer semantics to transmit only
      changed portions of agent records

   *  *Content compression* reduces storage and transmission costs for
      large agent definitions

   *  *Selective replication* based on query patterns minimizes
      unnecessary data transfer

4.9.2.  Scalability Architecture

   The system scales horizontally through several mechanisms:





Muscariello & Polic      Expires 28 August 2026                [Page 28]

Internet-Draft                  agent-dir                  February 2026


   *  *Registry sharding* distributes storage load across multiple OCI
      registry instances

   *  *Index partitioning* in the DHT allows query load to scale with
      the number of participating nodes

   *  *Lazy loading* defers retrieval of detailed agent specifications
      until actually needed

   This architecture provides a robust foundation for a decentralized
   agent directory that can scale to support the growing ecosystem of AI
   agents while maintaining the security and reliability requirements of
   production systems.

5.  IANA Considerations

   This document has no IANA actions.

6.  References

6.1.  Normative References

   [AGNTCY-OASF]
              Community, A., "Open Agent Schema Framework (OASF)", n.d.,
              <https://github.com/agntcy/oasf>.

   [OCI.Artifact]
              Initiative, O. C., "OCI Artifacts Guidance Specification",
              n.d., <https://github.com/opencontainers/image-
              spec/blob/v1.1.1/artifacts-guidance.md>.

   [OCI.Distribution]
              Initiative, O. C., "OCI Distribution Specification", n.d.,
              <https://github.com/opencontainers/distribution-spec>.

   [OCI.Image]
              Initiative, O. C., "OCI Image Format Specification", n.d.,
              <https://github.com/opencontainers/image-spec>.

   [OCI.Manifest]
              Initiative, O. C., "OCI Image Manifest Specification",
              n.d., <https://github.com/opencontainers/image-
              spec/blob/v1.1.1/manifest.md>.

   [OpenID.Auth]
              Foundation, O., "OpenID Authentication 2.0 - Final", n.d.,
              <https://openid.net/specs/openid-authentication-2_0.txt>.




Muscariello & Polic      Expires 28 August 2026                [Page 29]

Internet-Draft                  agent-dir                  February 2026


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6920>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

6.2.  Informative References

   [AGNTCY-ADS]
              Muscariello, L., Pandey, V., and R. Polic, "The AGNTCY
              Agent Directory Service: Architecture and Implementation",
              2025, <https://arxiv.org/abs/2509.18787>.

   [AI-Registry-Evolution]
              Singh, A., Ehtesham, A., Lambe, M., Grogan, J. J., Singh,
              A., Kumar, S., Muscariello, L., Pandey, V., Sauvage De
              Saint Marc, G., Chari, P., and R. Raskar, "Evolution of AI
              Agent Registry Solutions: Centralized, Enterprise, and
              Distributed Approaches", 2025,
              <https://arxiv.org/abs/2508.03095>.

   [DHT]      Maymounkov, P. and D. Mazieres, "Kademlia: A peer-to-peer
              information system based on the xor metric", IPTPS '01 ,
              2001.

   [libp2p-kad-dht]
              Community, libp2p., "go-libp2p-kad-dht: A Kademlia DHT
              implementation on go-libp2p", n.d.,
              <https://github.com/libp2p/go-libp2p-kad-dht>.

   [Oracle-AgentSpec]
              Oracle, "Open Agent Spec Documentation", n.d.,
              <https://oracle.github.io/agent-spec/index.html>.

   [Sigstore] Foundation, C. N. C., "Sigstore: A New Standard for
              Signing, Verifying and Protecting Software", n.d.,
              <https://www.sigstore.dev>.

Authors' Addresses




Muscariello & Polic      Expires 28 August 2026                [Page 30]

Internet-Draft                  agent-dir                  February 2026


   Luca Muscariello
   Cisco
   Email: lumuscar@cisco.com


   Ramiz Polic
   Cisco
   Email: rpolic@cisco.com











































Muscariello & Polic      Expires 28 August 2026                [Page 31]


