# drafts

name: draft-jiang-seat-dynamic-attestation
rev: 00
title: Dynamic Attestation for AI Agent Communication
time: 2025-11-13T08:45:40Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-17T08:45:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.751926+00:00
source: ietf
abstract:
  This document describes a use case for conveying remote attestation
     information in association with Transport Layer Security (TLS)
     sessions in the context of AI agent communication.  It focuses on
     long-lived secure channel sessions where an AI agent runtime posture,
     covering the platform Trusted Computing Base (TCB), agent manifest
     (models, tools and policies) and committed runtime context, can
     change frequently and unpredictably.  The document highlights
     requirements for dynamic attestation so that relying parties can base
     authorization decisions on the current runtime posture of the
     communicating agent.

full_text:
  SEAT                                                            Y. Jiang
  Internet-Draft                                                          
  Intended status: Informational                                   D. Wang
  Expires: 17 May 2026                                    13 November 2025


               Dynamic Attestation for AI Agent Communication
                  draft-jiang-seat-dynamic-attestation-00

  Abstract

     This document describes a use case for conveying remote attestation
     information in association with Transport Layer Security (TLS)
     sessions in the context of AI agent communication.  It focuses on
     long-lived secure channel sessions where an AI agent runtime posture,
     covering the platform Trusted Computing Base (TCB), agent manifest
     (models, tools and policies) and committed runtime context, can
     change frequently and unpredictably.  The document highlights
     requirements for dynamic attestation so that relying parties can base
     authorization decisions on the current runtime posture of the
     communicating agent.

  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 17 May 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



  Jiang & Wang               Expires 17 May 2026                  [Page 1]


  Internet-Draft        Dynamic Attestation for SEAT         November 2025


     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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Dynamic Attestation for AI Agent Communication  . . . . . . .   3
       3.1.  AI Agent Runtime Attestation  . . . . . . . . . . . . . .   3
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   4
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     Many deployed systems involve relatively static workloads, where
     software and configuration change primarily at onboarding or planned
     maintenance events.  In contrast, AI agents may alter effective
     behavior by updating their models, tools, and policies on timescales
     that are not necessarily aligned with TLS session establishment or
     traditional maintenance cycles.  Such updates may occur while long-
     lived TLS sessions remain open, or between sessions that are resumed
     or quickly re-established, raising security and privacy concerns
     about authorizing sensitive actions based on stale assumptions.

     Remote attestation (RA), as described in the Remote Attestation
     Procedures (RATS) architecture [RFC9334], allows a relying party to
     obtain information about the software and hardware state of a remote
     endpoint and to assess whether that state satisfies local policy.
     When combined with a secure channel protocol such as TLS 1.3
     [RFC8446], attestation information can be bound to a specific,
     authenticated session so that authorization decisions reflect the
     peer's current runtime posture (e.g., platform TCB plus an agent
     manifest covering model, tools and policy), rather than only the
     state at connection establishment.

     This document describes a use case for dynamic attestation in AI
     agent communication scenarios and outlines requirements for obtaining
     fresh, channel-bound attestation information without unnecessarily
     disrupting existing connections, allowing relying parties to base
     authorization on agent state at the time of use.





  Jiang & Wang               Expires 17 May 2026                  [Page 2]


  Internet-Draft        Dynamic Attestation for SEAT         November 2025


  2.  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 RFC
     8174 [RFC8174] when, and only when, they appear in all capitals, as
     shown here.

     This document uses the terminology defined in the RATS architecture
     [RFC9334] and in TLS 1.3 [RFC8446], including "Attestation", "Relying
     Party", "Evidence" and "Attestation Results".

     Trusted Computing Base (TCB) of a device, is used to refer to
     security-relevant components: hardware, firmware, software, and their
     respective configurations.

     Runtime posture denotes the set of attestation-relevant claims about
     the communicating endpoint at the time of use, sufficient for a
     relying party to appraise policy.  Its exact composition is
     deployment- specific and may include claims about the platform,
     execution environment, configuration, or context.

  3.  Dynamic Attestation for AI Agent Communication

     Goal: Support remote attestation for AI agent communication over
     secure channel sessions where the software and configuration on at
     least one endpoint can change on timescales that are not aligned with
     connection establishment or traditional maintenance cycles (for
     example, while long-lived sessions remain open or between sessions
     that are resumed), while the endpoint continues to exchange traffic
     with multiple network peers.

  3.1.  AI Agent Runtime Attestation

     Use case: AI Agent Runtime Attestation.  An AI agent service
     communicates with other network nodes over TLS 1.3, invoking tools
     that can access sensitive data or change network state.  The agent's
     model, tools, and policies may be updated dynamically according to
     operator policy, and these updates are not guaranteed to align with
     TLS session boundaries or a fixed maintenance schedule.  Peers
     therefore need assurance that, at the time of a high-impact
     operation, the agent runs on an acceptable platform and uses an
     approved combination of model, code, and policy.








  Jiang & Wang               Expires 17 May 2026                  [Page 3]


  Internet-Draft        Dynamic Attestation for SEAT         November 2025


     *  Requirement 1 (fresh, channel-bound attestation): Before executing
        a high-impact operation over an existing secure channel, a peer
        MUST be able to obtain fresh attestation evidences that are
        cryptographically bound to that session and that reflect both the
        platform and the current agent-level state relevant to
        authorization, as determined by local policy.

     *  Requirement 2 (dynamic attestation): The mechanism used to obtain
        such attestation evidences SHOULD support lightweight, dynamic
        attestation without necessarily requiring a full new TLS
        handshake, so that changes to the runtime posture become visible
        to relying parties when required by local policy.

  4.  Security Considerations

     Any mechanism that supports dynamic attestation for AI agent
     communication should ensure that attestation evidences are strongly
     bound to the TLS session for which they are intended, so that they
     cannot be replayed or relayed to another session or endpoint.

     Because the agent software stack can change rapidly, attestation
     evidences should be sufficiently fresh for the relying party's
     policy.  Implementations should provide a way to limit the validity
     period of evidences for a given session and to trigger attestation
     when that period expires or when relevant changes are detected.

  5.  IANA Considerations

     This document has no IANA actions.

  6.  References

  6.1.  Normative References

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", May 2017,
                <https://datatracker.ietf.org/doc/html/rfc8174>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", August 2018,
                <https://datatracker.ietf.org/doc/html/rfc8446>.

     [RFC9334]  Birkholz, H., Fossati, T., Hardjono, T., and N. Smith,
                "Remote Attestation Procedures Architecture", January
                2023, <https://datatracker.ietf.org/doc/html/rfc9334>.

  6.2.  Informative References




  Jiang & Wang               Expires 17 May 2026                  [Page 4]


  Internet-Draft        Dynamic Attestation for SEAT         November 2025


     [RFC9261]  Sullivan, N. and C. A. Wood, "Exported Authenticators in
                TLS and DTLS", July 2022,
                <https://datatracker.ietf.org/doc/html/rfc9261>.

  Authors' Addresses

     Yuning Jiang
     Singapore
     Email: jiangyuning2@h-partners.com


     Donghui Wang
     China
     Email: wangdonghui124@huawei.com





































  Jiang & Wang               Expires 17 May 2026                  [Page 5]


name: draft-gaikwad-woa
rev: 00
title: The Web of Agents (WoA)
time: 2025-11-30T01:42:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-03T01:42:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.756134+00:00
source: ietf
abstract:
  This document defines the Web of Agents (WoA), a minimal JSON based
     description format and invocation convention that allows HTTP hosts
     to advertise AI agents and for clients to invoke those agents in a
     uniform way.  A WoA document is typically served from a well known
     location on an HTTP origin and uses JSON Schema to describe agent
     inputs and outputs.  WoA does not define a discovery protocol itself
     but is designed to be used as a host level primitive by higher level
     discovery systems.

full_text:
  Independent Submission                                        M. Gaikwad
  Internet-Draft                                           1 December 2025
  Intended status: Experimental                                           
  Expires: 4 June 2026


                          The Web of Agents (WoA)
                            draft-gaikwad-woa-00

  Abstract

     This document defines the Web of Agents (WoA), a minimal JSON based
     description format and invocation convention that allows HTTP hosts
     to advertise AI agents and for clients to invoke those agents in a
     uniform way.  A WoA document is typically served from a well known
     location on an HTTP origin and uses JSON Schema to describe agent
     inputs and outputs.  WoA does not define a discovery protocol itself
     but is designed to be used as a host level primitive by higher level
     discovery systems.

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




  Gaikwad                    Expires 4 June 2026                  [Page 1]


  Internet-Draft                     WoA                     December 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
       2.1.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  WoA Document Schema . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Agent Objects . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  JSON Schema Usage for Inputs and Outputs  . . . . . . . .   6
       4.3.  Transport Configurations  . . . . . . . . . . . . . . . .   6
         4.3.1.  REST Transport  . . . . . . . . . . . . . . . . . . .   7
         4.3.2.  MCP Transport . . . . . . . . . . . . . . . . . . . .   7
         4.3.3.  Private Transports  . . . . . . . . . . . . . . . . .   8
     5.  Invocation  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.  Invocation Envelope . . . . . . . . . . . . . . . . . . .   8
       5.2.  REST Transport Invocation . . . . . . . . . . . . . . . .   8
       5.3.  MCP Transport Invocation  . . . . . . . . . . . . . . . .   9
     6.  Authorization . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.  Caching . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
       8.1.  Transport Security  . . . . . . . . . . . . . . . . . . .  10
       8.2.  Server Side Request Forgery and Origin Validation . . . .  10
       8.3.  Indirect Prompt Injection . . . . . . . . . . . . . . . .  11
       8.4.  Agent Output Trust  . . . . . . . . . . . . . . . . . . .  11
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
       9.1.  Well Known URI Registration . . . . . . . . . . . . . . .  11
       9.2.  Media Type Registration . . . . . . . . . . . . . . . . .  11
       9.3.  WoA Transport Registry  . . . . . . . . . . . . . . . . .  12
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  12
     11. Informative References  . . . . . . . . . . . . . . . . . . .  14
     Appendix A: Example Use with SOUTH (Non-Normative)  . . . . . . .  14
     Appendix B: Complete Example WoA Flow (Non-Normative) . . . . . .  16
       Example WoA Document  . . . . . . . . . . . . . . . . . . . . .  16
       Client Fetches WoA Document . . . . . . . . . . . . . . . . . .  17
       Client Invokes the Agent  . . . . . . . . . . . . . . . . . . .  18
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

  1.  Introduction

     AI agents are increasingly exposed as network reachable services,
     such as text based large language model interfaces, task specific
     tools, and composite workflows that call other services.  Today these
     agents are typically documented using ad hoc JSON documents or
     provider specific formats.  This makes it difficult for generic
     clients to discover which agents exist on a given origin and to
     invoke them in a predictable way.

     The Web of Agents (WoA) defines:



  Gaikwad                    Expires 4 June 2026                  [Page 2]


  Internet-Draft                     WoA                     December 2025


     *  a JSON based document format, usually served from a well known
        path on an origin, that lists agents and their properties

     *  a JSON Schema based description of agent inputs and outputs

     *  a small set of transport configuration objects that define how a
        client constructs an invocation request

     *  a simple invocation envelope used by some transports

     WoA is intentionally small in scope.  It does not attempt to define a
     global discovery system or a capability vocabulary.  It is designed
     to complement such systems by providing a host level primitive that
     discovery mechanisms can fetch, cache, and index.  For example, a
     cross platform discovery system such as [CUI-AGENT-DISCOVERY] could
     use WoA documents as one of its inputs when building a search index.

     This document is targeted at the Independent Submission Stream with
     category "exp".  The intent is to provide a concrete and
     implementable format that can be experimented with by client and host
     implementers.

  2.  Conventions and 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.

     This document uses the JSON data model defined in [RFC8259] and HTTP
     terminology from [RFC9110].

  2.1.  Terms

     WoA document  A JSON document served by an HTTP origin that describes
        one or more agents and their transport configurations according to
        this specification.

     Agent  A logical AI powered capability exposed by a host.  An agent
        has an identifier, a human readable name and description, a JSON
        Schema based input and output description, and one or more
        transport options that describe how to invoke it.

     Host  An HTTP origin that serves a WoA document and optionally
        implements one or more transports for agents described in that
        document.




  Gaikwad                    Expires 4 June 2026                  [Page 3]


  Internet-Draft                     WoA                     December 2025


     WoA Client  A component that retrieves the WoA document and invokes
        agents.  A WoA client may be a user facing application, an
        orchestration engine, or another independent agent, enabling agent
        to agent (A2A) interactions.

     Transport  A named mechanism that defines how a client constructs and
        sends an invocation request.  This document defines the "rest" and
        "mcp" transports.  Additional transports may be registered in the
        WoA Transport Registry.

  3.  Architecture

     A typical deployment has an HTTP origin that serves a WoA document at
     a well known path, and one or more transports that accept invocation
     requests.

     +-----------+         GET /.well-known/woa.json        +-----------+
     |           | ---------------------------------------> |           |
     |   Client  |                                          |    Host   |
     |           | <--------------------------------------- |           |
     +-----------+         200 application/woa+json         +-----------+
           |
           |  Select agent and transport
           v
     +-----------+       HTTP POST (REST transport)         +-----------+
     |           | ---------------------------------------> |           |
     |   Client  |                                          |    Host   |
     |           | <--------------------------------------- |           |
     +-----------+             JSON response                +-----------+

                     Figure 1: High Level WoA Architecture

     A client fetches the WoA document from a host, selects an agent,
     chooses a transport supported by both client and host, constructs an
     invocation request according to the transport rules, and processes
     the response.  Higher level discovery systems may crawl or index WoA
     documents but are out of scope for this specification.

  4.  WoA Document Schema

     A WoA document is a single JSON object with the following top level
     fields:

     *  woa_version: A string identifying the WoA document version.  For
        this specification the value MUST be the string "1".

     *  agents: An array of agent objects as defined in Section 4.1.




  Gaikwad                    Expires 4 June 2026                  [Page 4]


  Internet-Draft                     WoA                     December 2025


     *  transports: An object whose keys are transport names and whose
        values are transport configuration objects as defined in
        Section 4.3.

  4.1.  Agent Objects

     Each element of the agents array is an object with the following
     fields:

     *  id (string, REQUIRED): A token that uniquely identifies the agent
        within the WoA document.  The value MUST match the following ABNF
        (using [RFC5234]):

     agent-id = 1*( ALPHA / DIGIT / "-" / "_" )

     *  name (string, REQUIRED): A short, human readable name for the
        agent.

     *  description (string, REQUIRED): A human readable description of
        what the agent does.  Clients MUST treat this field as untrusted
        input for security reasons (see Section 8).

     *  version (string, OPTIONAL): A version identifier for the agent
        implementation, such as "1.0.0".

     *  capabilities (array of strings, OPTIONAL): A list of capability
        identifiers.  This specification does not define a controlled
        vocabulary.  Implementations MAY use URIs (for example,
        "https://example.com/capability/summarization") or URN like
        identifiers as long as they are stable.

     *  inputs (object, REQUIRED): A JSON Schema document that describes
        the expected request body when invoking the agent.  See
        Section 4.2.

     *  outputs (object, REQUIRED): A JSON Schema document that describes
        the successful response body produced by the agent.

     *  transports (array of strings, REQUIRED): Names of transport
        configurations (keys in the top level transports object) that can
        be used to invoke this agent.

     *  operations (array of objects, OPTIONAL): A list of operation
        descriptors for agents that support multiple logical operations
        via a single transport endpoint.  If operations is not present,
        the agent is considered to have a single unnamed operation.

     Each operation object in the operations array has:



  Gaikwad                    Expires 4 June 2026                  [Page 5]


  Internet-Draft                     WoA                     December 2025


     *  name (string, REQUIRED): A token naming the operation.

     *  description (string, REQUIRED): Human readable description of the
        operation.

     *  inputs (object, OPTIONAL): JSON Schema overriding the agent level
        inputs for this operation.

     *  outputs (object, OPTIONAL): JSON Schema overriding the agent level
        outputs for this operation.

     Clients MUST NOT assume that two agents with the same id on different
     origins have the same behavior or schema.

  4.2.  JSON Schema Usage for Inputs and Outputs

     The inputs, outputs, and any operation level inputs or outputs fields
     MUST be valid JSON Schema documents compliant with the JSON Schema
     2020-12 core and validation specifications [JSON-SCHEMA-CORE]
     [JSON-SCHEMA-VAL].

     At minimum, implementations MUST support JSON Schema documents whose
     root is an object with:

     *  a type of "object"

     *  a properties object describing named properties

     *  an optional required array naming required properties

     More advanced JSON Schema features such as oneOf, allOf, and format
     MAY be used by hosts and SHOULD be ignored by clients that do not
     understand them, as long as the client can still construct a
     conforming request.

     Hosts SHOULD provide concise and accurate JSON Schema documents to
     enable static validation and tooling.  Clients MAY validate request
     bodies locally against the inputs schema before sending them and MAY
     validate successful responses against the outputs schema.

  4.3.  Transport Configurations

     The top level transports object maps transport names to configuration
     objects.  Transport names are strings.  This document defines the
     rest and mcp transports.  Additional transports MAY be defined and
     registered in the WoA Transport Registry (see Section 9.3).





  Gaikwad                    Expires 4 June 2026                  [Page 6]


  Internet-Draft                     WoA                     December 2025


  4.3.1.  REST Transport

     A rest transport configuration object MUST contain:

     *  base (string, REQUIRED): An absolute HTTPS URL that identifies the
        base of the REST API.  The URL scheme MUST be "https" and the
        server SHOULD support TLS 1.3 [RFC8446].

     *  invoke_path (string, REQUIRED): An absolute path beginning with
        "/" that, when combined with base, yields the invocation URL
        template.  The path MAY contain a query component.  Within the
        path, the case sensitive substring "{agent_id}" MAY appear as a
        placeholder.

     To construct the invocation URL, the client concatenates the base URL
     and the invoke_path value.  If the invoke_path contains the case
     sensitive substring "{agent_id}", the client MUST replace it with the
     target agent's id value.

     Clients invoking an agent via the REST transport MUST use HTTP POST
     and MUST send a request body encoded as JSON with media type
     application/json.  The request body for the REST transport is defined
     in Section 5.  Hosts using the REST transport MUST respond with JSON
     and SHOULD use the application/problem+json media type for errors as
     specified in [RFC9457].

  4.3.2.  MCP Transport

     A mcp transport configuration object describes how an agent is
     exposed via a Model Context Protocol (MCP) server [MCP].  The
     configuration object MUST contain:

     *  server (string, REQUIRED): An identifier or URL for the MCP server
        endpoint.  The exact format is defined by the MCP specification.

     *  tool_namespace (string, REQUIRED): A string that identifies the
        logical namespace of tools on the MCP server.

     *  tool_field (string, REQUIRED): The name of the field in the
        invocation envelope that contains the tool name for this MCP
        server.

     When using the MCP transport, the client translates the WoA
     invocation envelope into the appropriate MCP tool invocation as
     defined by the MCP specification [MCP].  For example, if tool_field
     is "agent", the client MAY pass the value of the envelope's agent
     field as the tool name.




  Gaikwad                    Expires 4 June 2026                  [Page 7]


  Internet-Draft                     WoA                     December 2025


  4.3.3.  Private Transports

     Hosts MAY define private transport names for experimental use.
     Private transport names MUST use a reverse DNS prefix, such as
     "com.example.mytransport", to avoid collisions with registered
     transports.  Private transports MUST NOT be registered in the WoA
     Transport Registry.

  5.  Invocation

     This section describes the invocation envelope and how it is used
     with the REST and MCP transports.  Other transports MAY define their
     own invocation rules.

  5.1.  Invocation Envelope

     When a transport uses a JSON request body that contains metadata
     about the invocation in addition to the agent specific input object,
     this document refers to that JSON object as the "invocation
     envelope".

     For the REST transport defined in this document, the invocation
     envelope is an object with the following fields:

     *  agent (string, REQUIRED): The agent identifier as listed in the
        WoA document.

     *  operation (string, OPTIONAL): The operation name, if the agent
        defines an operations array.  If omitted for an agent that defines
        operations, the name "default" is RECOMMENDED as the implied
        operation.

     *  input (object, REQUIRED): A JSON object that MUST conform to the
        JSON Schema specified in the selected operation's inputs schema,
        or to the agent level inputs if there is no per operation
        override.

     Transports MAY add additional fields to the invocation envelope as
     long as they do not conflict with the fields defined above.

  5.2.  REST Transport Invocation

     When using the REST transport, the client constructs the invocation
     URL as described in Section 4.3.1 and sends an HTTP POST request with
     media type application/json and a request body containing the
     invocation envelope.





  Gaikwad                    Expires 4 June 2026                  [Page 8]


  Internet-Draft                     WoA                     December 2025


     The agent field in the envelope MUST match the intended agent's id.
     If the REST invocation URL template includes an "{agent_id}"
     placeholder, the host can infer the agent from the URL.  In that
     case:

     *  If the host derives an agent identifier from the URL and the agent
        field is absent in the envelope, the host MAY use the identifier
        from the URL.

     *  If the host derives an agent identifier from the URL and the
        envelope contains an agent field with a different value, the host
        MUST reject the request with HTTP status 400 (Bad Request).  The
        host SHOULD return a application/problem+json body explaining the
        mismatch.

     On success, the host MUST return a 2xx status code and a JSON
     response body that conforms to the JSON Schema specified in the
     selected operation's outputs schema, or the agent level outputs
     schema if there is no per operation override.

     On error, the host SHOULD return a 4xx or 5xx status code and a
     response body using the problem details format defined in [RFC9457]
     with media type application/problem+json.  Problem type URIs and
     error code taxonomies are deployment specific.

  5.3.  MCP Transport Invocation

     When using the MCP transport, the client translates the invocation
     envelope into the appropriate MCP tool invocation.  The exact mapping
     is defined by the MCP specification [MCP] and is not repeated here.
     As a typical pattern, the agent or operation fields of the envelope
     may map to tool names and the input object may map to MCP tool
     arguments.

     WoA does not define the wire protocol for MCP and does not impose
     additional security requirements beyond those defined by the MCP
     specification.  The security considerations in Section 8 still apply
     to the host that publishes the WoA document.

  6.  Authorization

     WoA deliberately separates the question of "which agent exists and
     how can it be invoked" from "who is allowed to invoke this agent".
     The WoA document format does not contain access tokens and does not
     mandate a particular authorization protocol.  Hosts MAY use OAuth 2.0
     [RFC6749], mutual TLS, or other mechanisms to protect invocation
     endpoints.




  Gaikwad                    Expires 4 June 2026                  [Page 9]


  Internet-Draft                     WoA                     December 2025


     A host MAY include additional metadata in the WoA document to help
     clients understand the authorization expectations for an agent.  For
     example, a deployment using the SOUTH stochastic authorization
     protocol [I-D.gaikwad-south-authorization] might include an authz
     object with pointers to policy endpoints.  Such metadata is
     deployment specific and out of scope for the core WoA specification.

  7.  Caching

     WoA documents are likely to be fetched frequently by clients and
     discovery systems.  Hosts SHOULD include HTTP caching headers, such
     as ETag, Last-Modified, and appropriate Cache-Control directives, on
     responses that carry a WoA document to reduce unnecessary network
     traffic.  Clients SHOULD honor these headers when polling for
     updates.

  8.  Security Considerations

     WoA is a descriptive format and does not execute code by itself, but
     it is used in contexts where agents may execute untrusted input or
     perform sensitive actions.  Both hosts and clients need to consider
     the following security aspects.

  8.1.  Transport Security

     Hosts that serve WoA documents and implement REST transports MUST use
     HTTPS.  The underlying TLS version SHOULD be TLS 1.3 [RFC8446].
     Clients MUST validate server certificates according to normal HTTPS
     rules.  Plain HTTP MUST NOT be used for WoA documents or REST
     invocations on the open Internet.

  8.2.  Server Side Request Forgery and Origin Validation

     A malicious WoA document could advertise transport URLs that point to
     internal or otherwise sensitive endpoints.  Automated clients that
     unconditionally invoke agents based on WoA documents risk being used
     as a vector for server side request forgery.

     Clients SHOULD validate that transport URLs provided in a WoA
     document resolve to allowed domains or IP address ranges before
     invoking agents.  In particular, clients SHOULD NOT automatically
     send invocation requests to URLs that resolve to private or link
     local address ranges, such as those defined in [RFC1918], unless
     explicitly configured to do so by an administrator.  Clients SHOULD
     also be cautious of HTTP redirects that change the authority
     component of the URL and SHOULD apply the same validation to the
     redirect target.




  Gaikwad                    Expires 4 June 2026                 [Page 10]


  Internet-Draft                     WoA                     December 2025


  8.3.  Indirect Prompt Injection

     The name and description fields of an agent are free form strings
     controlled by the host.  Clients that use a large language model to
     reason about or select agents based on these fields MUST treat them
     as untrusted input.  A malicious host could embed text that attempts
     to influence the client side model in ways that bypass user intent, a
     pattern sometimes referred to as indirect prompt injection.

     Implementers SHOULD design any agent selection logic that uses LLMs
     with appropriate input isolation, such as explicit system level
     instructions that describe which fields are trusted and which are
     untrusted, and with guardrails that restrict the actions that can be
     taken based on WoA content.

  8.4.  Agent Output Trust

     WoA itself does not provide integrity or authenticity guarantees for
     agent outputs.  Clients SHOULD treat agent responses as untrusted
     data and apply appropriate validation, sandboxing, and authorization
     checks before using them to take actions such as executing code,
     issuing network requests, or changing external state.

  9.  IANA Considerations

  9.1.  Well Known URI Registration

     This document requests registration of a new well known URI suffix in
     the "Well Known URIs" registry as defined in [RFC8615].

     The registration template is:

     URI suffix: woa.json
     Change controller: IETF
     Specification document: This document
     Status: permanent
     Related information: none

  9.2.  Media Type Registration

     This document requests registration of the application/woa+json media
     type in the "Media Types" registry according to [RFC6838].

     The registration template is:







  Gaikwad                    Expires 4 June 2026                 [Page 11]


  Internet-Draft                     WoA                     December 2025


     Type name: application
     Subtype name: woa+json
     Required parameters: none
     Optional parameters: none
     Encoding considerations: binary
       WoA documents are encoded as UTF-8 JSON text.
     Security considerations: See Section 7 of this document.
     Interoperability considerations: none
     Published specification: This document.
     Applications that use this media type:
       WoA hosts and clients that exchange WoA documents.
     Fragment identifier considerations: none
     Additional information: none
     Person & email address to contact:
       Madhava Gaikwad <gaikwad.madhav@gmail.com>
     Intended usage: COMMON
     Restrictions on usage: none
     Author: Madhava Gaikwad <gaikwad.madhav@gmail.com>
     Change controller: IETF

  9.3.  WoA Transport Registry

     This document requests the creation of a new registry titled "WoA
     Transport Registry".  The registry records transport names used in
     the top level transports object of WoA documents.

     Each entry in the registry has the following fields:

     *  Transport name: a short string identifying the transport.

     *  Reference: a stable specification that defines the transport.

     Registration policy for the WoA Transport Registry is "Specification
     Required" as defined in [RFC8126].

     This document registers the following initial entries:

     Transport name: rest
     Reference: This document

     Transport name: mcp
     Reference: Model Context Protocol specification [MCP]

  10.  Normative References







  Gaikwad                    Expires 4 June 2026                 [Page 12]


  Internet-Draft                     WoA                     December 2025


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

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

     [RFC8259]  Bray, T., "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>.

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

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

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/info/rfc8615>.

     [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
                Specifications and Registration Procedures", BCP 13,
                RFC 6838, DOI 10.17487/RFC6838, January 2013,
                <https://www.rfc-editor.org/info/rfc6838>.

     [RFC9457]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
                for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
                <https://www.rfc-editor.org/info/rfc9457>.

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

     [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234,
                DOI 10.17487/RFC5234, January 2008,
                <https://www.rfc-editor.org/info/rfc5234>.

     [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/info/rfc8126>.



  Gaikwad                    Expires 4 June 2026                 [Page 13]


  Internet-Draft                     WoA                     December 2025


     [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
                and E. Lear, "Address Allocation for Private Internets",
                BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
                <https://www.rfc-editor.org/info/rfc1918>.

     [JSON-SCHEMA-CORE]
                Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
                Schema: A Media Type for Describing JSON Documents",
                December 2020,
                <https://json-schema.org/draft/2020-12/json-schema-core>.

     [JSON-SCHEMA-VAL]
                Wright, A., Andrews, H., and B. Hutton, "JSON Schema
                Validation: A Vocabulary for Structural Validation of
                JSON", December 2020, <https://json-schema.org/draft/2020-
                12/json-schema-validation>.

     [I-D.gaikwad-south-authorization]
                Gaikwad, M., "SOUTH: Stochastic Authorization for Agent
                and Service Requests", Work in Progress, Internet-Draft,
                draft-gaikwad-south-authorization, October 2025,
                <https://datatracker.ietf.org/doc/draft-gaikwad-south-
                authorization/>.

  11.  Informative References

     [CUI-AGENT-DISCOVERY]
                Cui, Y., Chao, Y., and C. Du, "HTTP-Based AI Agent
                Discovery and Invocation Protocol", Work in Progress,
                Internet-Draft, draft-cui-ai-agent-discovery-invocation,
                October 2025, <https://datatracker.ietf.org/doc/draft-cui-
                ai-agent-discovery-invocation/>.

     [MCP]      Anthropic, "Model Context Protocol Specification",
                November 2024, <https://modelcontextprotocol.io>.

  Appendix A: Example Use with SOUTH (Non-Normative)

     This appendix sketches how a deployment might combine WoA with the
     SOUTH stochastic authorization protocol
     [I-D.gaikwad-south-authorization].  It is non-normative and does not
     modify the core WoA format.

     A host could add an authz object at the top level of the WoA document
     or within an agent object that points to a SOUTH policy endpoint.
     For example:





  Gaikwad                    Expires 4 June 2026                 [Page 14]


  Internet-Draft                     WoA                     December 2025


     {
       "woa_version": "1",
       "agents": [
         {
           "id": "summarizer",
           "name": "Document Summarizer",
           "description": "Summarizes English text.",
           "version": "1.0.0",
           "capabilities": [
             "https://example.com/capability/summarization"
           ],
           "inputs": { "...": "JSON Schema elided" },
           "outputs": { "...": "JSON Schema elided" },
           "transports": ["rest"],
           "authz": {
             "scheme": "south",
             "policy_uri":
               "https://authz.example.com/south/policies/summarizer",
             "token_header": "Authorization"
           }
         }
       ],
       "transports": {
         "rest": {
           "base": "https://api.example.com",
           "invoke_path": "/agents/{agent_id}/invoke"
         }
       }
     }

     A client that understands SOUTH could first obtain a token from the
     SOUTH authorization server according to
     [I-D.gaikwad-south-authorization] and then include it as a SOUTH
     token in the HTTP request:

     POST /agents/summarizer/invoke HTTP/1.1
     Host: api.example.com
     Content-Type: application/json
     Authorization: SOUTH eyJhbGciOi...

     {
       "agent": "summarizer",
       "operation": "default",
       "input": {
         "text": "Long document text here..."
       }
     }




  Gaikwad                    Expires 4 June 2026                 [Page 15]


  Internet-Draft                     WoA                     December 2025


     The details of how SOUTH evaluates policies and issues tokens are
     defined in [I-D.gaikwad-south-authorization] and are not repeated
     here.

  Appendix B: Complete Example WoA Flow (Non-Normative)

     This appendix provides a complete example showing a WoA document, a
     client fetching it, invoking an agent via the REST transport, and
     receiving a successful response.

  Example WoA Document

     Consider a host at https://api.example.com that serves the following
     WoA document at https://api.example.com/.well-known/woa.json using
     the application/woa+json media type.

     {
       "woa_version": "1",
       "agents": [
         {
           "id": "summarizer",
           "name": "Document Summarizer",
           "description": "Summarizes English text.",
           "version": "1.0.0",
           "capabilities": [
             "https://example.com/capability/summarization"
           ],
           "inputs": {
             "$schema": "https://json-schema.org/draft/2020-12/schema",
             "type": "object",
             "properties": {
               "text": {
                 "type": "string",
                 "description": "Input document text in English."
               },
               "max_words": {
                 "type": "integer",
                 "minimum": 10,
                 "maximum": 500,
                 "description": "Maximum number of words in the summary."
               }
             },
             "required": ["text"]
           },
           "outputs": {
             "$schema": "https://json-schema.org/draft/2020-12/schema",
             "type": "object",
             "properties": {



  Gaikwad                    Expires 4 June 2026                 [Page 16]


  Internet-Draft                     WoA                     December 2025


               "summary": {
                 "type": "string",
                 "description": "The generated summary."
               }
             },
             "required": ["summary"]
           },
           "transports": ["rest"],
           "operations": [
             {
               "name": "default",
               "description": "Default summarization operation."
             }
           ]
         }
       ],
       "transports": {
         "rest": {
           "base": "https://api.example.com",
           "invoke_path": "/agents/{agent_id}/invoke"
         }
       }
     }

  Client Fetches WoA Document

     A client fetches the WoA document:

     GET /.well-known/woa.json HTTP/1.1
     Host: api.example.com
     Accept: application/woa+json, application/json

     The host responds:

     HTTP/1.1 200 OK
     Content-Type: application/woa+json
     ETag: "abc123"
     Cache-Control: max-age=300

     { ... JSON from previous section ... }

     The client parses the JSON, locates the agent with id "summarizer",
     and notes that it supports the rest transport.








  Gaikwad                    Expires 4 June 2026                 [Page 17]


  Internet-Draft                     WoA                     December 2025


  Client Invokes the Agent

     The client constructs the invocation URL by concatenating the base
     and invoke_path values and substituting "{agent_id}" with
     "summarizer":

     https://api.example.com/agents/summarizer/invoke

     The client then builds an invocation envelope that conforms to the
     agent's inputs schema:

     {
       "agent": "summarizer",
       "operation": "default",
       "input": {
         "text": "The IETF is an open community of designers.",
         "max_words": 40
       }
     }

     The client sends the HTTP request:

     POST /agents/summarizer/invoke HTTP/1.1
     Host: api.example.com
     Content-Type: application/json
     Accept: application/json

     {
       "agent": "summarizer",
       "operation": "default",
       "input": {
         "text": "The IETF is an open community of designers.",
         "max_words": 40
       }
     }

     The host validates the request against the JSON Schema in inputs,
     performs the summarization, and returns a response that matches the
     outputs schema:

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

     {
       "summary": "The IETF is a community focused on Internet evolution."
     }





  Gaikwad                    Expires 4 June 2026                 [Page 18]


  Internet-Draft                     WoA                     December 2025


     The client MAY validate the response body against the outputs schema
     and then present the summary to the user or feed it into subsequent
     processing.

  Author's Address

     Madhava Gaikwad
     Email: gaikwad.madhav@gmail.com











































  Gaikwad                    Expires 4 June 2026                 [Page 19]


name: draft-ietf-lisp-nexagon
rev: 57
title: Geo-Intelligence Network Based On H3 and LISP
time: 2025-09-23T12:45:25Z
group_uri: /api/v1/group/group/1751/
expires: 2026-03-27T12:45:25Z
shepherd: /api/v1/person/email/ggx@gigix.net/
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.761383+00:00
source: ietf
abstract:
  Lisp-Nexagon is a geospatial intelligence network protocol designed
  to support physical-world applications such as transportation, public
  safety, and logistics. It combines the Locator/ID Separation Protocol
  (LISP) with the H3 spatial indexing system to enable distributed
  agents to report, aggregate, and disseminate geospatial state
  information.

full_text:
  LISP Working Group                                           S. Barkai
  Internet-Draft                                               Oterra.ai
  Intended status: Informational                       B. Fernandez-Ruiz
  Expires: March 24, 2026                                    Nexar Inc.
                                                                R. Tamir
                                                                Ariga.io
                                                      A. Rodriguez-Natal
                                                                F. Maino
                                                           Cisco Systems
                                                    A. Cabellos-Aparicio
                                                   J. Paillisse-Vilanova
                                    Universitat Politecnica de Catalunya
                                                            D. Farinacci
                                                             lispers.net
                             September 24, 2025


               Geo-Intelligence Network Based On H3 and LISP
                        draft-ietf-lisp-nexagon-57.txt


  Abstract

  Lisp-Nexagon is a geospatial intelligence network protocol designed 
  to support physical-world applications such as transportation, public
  safety, and logistics. It combines the Locator/ID Separation Protocol
  (LISP) with the H3 spatial indexing system to enable distributed 
  agents to report, aggregate, and disseminate geospatial state 
  information.






  Barkai, et al.          Expires March 24, 2026             [Page 1]



  Internet-Draft                     LISP              September 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 October 1,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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

  Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   5
   3.  Deployment Assumptions  . . . . . . . . . . . . . . . . . . .   7
   4.  Clients-Agents Networking . . . . . . . . . . . . . . . . . .   8
   5.  Mobility Unicast and Multicast  . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
  10.  Normative References  . . . . . . . . . . . . . . . . . . . .  18
  Authors' Addresses   . . . . . . . . . . . . . . . . . . . . . . .  19

  Barkai, et al.          Expires March 24, 2026             [Page 2]



  Internet-Draft                     LISP              September 2025

  1.  Introduction

  Lisp-Nexagon is a geospatial intelligence network protocol designed 
  to support physical-world applications such as transportation, public
  safety, and logistics. It combines the Locator/ID Separation Protocol
  (LISP) with the [H3] spatial indexing system to enable distributed 
  agents to report, aggregate, and disseminate geospatial state 
  information.

  The system models geospatial data flow and control after the 
  management planes found in digital infrastructure to facilitate
  autonomous systems support in physical environments. Geospatial 
  intelligence is organized by H3 tiles at varying resolutions. High-
  resolution (small-area) tiles are used to represent specific 
  environmental and infrastructural conditions such as road status,
  vegetation coverage, fire activity, weather, and physical
  obstructions. Data for these tiles is produced by interoperating
  sources and collected by geo-aggregation agents.

  Each aggregation agent is assigned a low-resolution (large-area) H3
  tile that defines its jurisdiction. This jurisdiction is associated
  with a LISP Endpoint Identifier (EID), which acts as the routing and
  addressing point for intelligence updates. Agents receive input from
  data sources within their jurisdiction and provide processed
  information or notifications to clients authorized to query or 
  subscribe to state data.

  Lisp-Nexagon provides a framework for structured, addressable, and 
  jurisdiction-based geospatial coordination using existing LISP 
  mechanisms and H3 spatial semantics.

  Barkai, et al.          Expires March 24, 2026            [Page 3]



  Internet-Draft                     LISP             September 2025


  The network requires a formal provisioning step for sources, 
  clients, and agents. For sources and destinations, this step 
  involves an authentication, authorization, and accounting (AAA) 
  procedure through which endpoints request and renew EIDs and LISP
  tunnel-routers (XTR) to interact through.
                                   ___
                                 /     \
                        EID >>    States  >> EID
                        Upload   \ ___ /     Channels
                         /\     Functions()      \/

                          Figure 1:H3-LISP Agents


     Off-Peak EID 
    Condensed Allocation
     _  _    _  _
    / \/ \  / \/ \   n+1
    \_/\_/  \_/\_/  ----         Peak allocation for same EID
    / \/ \  / \/ \  ----       Spread on more compute locations
    \_/\_/  \_/\_/  ----       _  _    _  _    _  _    _  _    n+1
    / \/ \  / \/ \  ----      / \/ \  / \/ \  / \/ \  / \/ \  ----
    \_/\_/  \_/\_/  ----      \_/\_/  \_/\_/  \_/\_/  \_/\_/  ----
    / \/ \  / \/ \  ----      / \/ \  / \/ \  / \/ \  / \/ \  ----
    \_/\_/  \_/\_/  ----      \_/\_/  \_/\_/  \_/\_/  \_/\_/  ----

     Site   Site               Site    Site    Site    Site  

           Figure 2: Dynamic allocation per activity



  Barkai, et al.          Expires March 24, 2026           [Page 4]



  Internet-Draft                     LISP            September 2025


  2. Definition of Terms

    Based on [RFC9300][RFC9301]

    H3AgentEID: H3AgentEID is an EID-addressable Geolocation agent,
      also known as a nexagon. It serves as a designated destination for
      Geolocation aggregation and an (S,G) source of multicast themed
      channels. It has a LISP data-plane stack to encapsulate
      packets via ServerXTR.

    ServerXTR: ServerXTR is a data-plane only LISP protocol stack
      implementation that is co-located with the H3AgentEID process. It
      encapsulates and decapsulates packets to and from EdgeRTRs.

    MobilityClient: MobilityClient is an application that may be a part
      of a driving system or mobility application, It has a LISP data-
      plane stack to encapsulate packets via ClientXTR.

    MobilityClientEID: MobilityClientEID is the IPv6 EID used by 
      Mobility Clients. The destination of such packets are H3AgentEIDs.
      The EID is assigned as part of the MobilityClient network AAA.

    ClientXTR: ClientXTR is a data-plane only LISP protocol stack
      implementation co-located with the Mobility Client application. 
      It encapsulates and decapsulates packets to and from EdgeRTRs.

    EdgeRTR: The EdgeRTR network is responsible for connecting Mobility 
      Clients to Agents and managing MobilityClientEIDs multicast 
      registrations [RFC8378]. The network achieves this by using 
      encapsulation to aggregate Mobility Clients and Geolocation 
      Agents, making it easier to access the mobility network from 
      hosting providers and mobile providers.

  The RTRs within the EdgeRTR network re-encapsulate packets from 
  ClientXTRs, ServerXTRs, and remote RTRs. During packet decapsulation, 
  EdgeRTRs glean H3 agent EIDs and MobilityClientEIDs and store them 
  along with route locations (RLOCs) in map-caches. These mappings are
  then registered to the LISP mapping system [RFC9301] and are 
  provisioned when Geolocation Agents are assigned to EdgeRTRs.
  It's key to note that EdgeRTRs do not register MobilityClientEIDs. 
  Enterprises can provide their own EdgeRTRs to protect the geo-privacy. 




  Barkai, et al.          Expires March 24, 2026          [Page 5]



  Internet-Draft                     LISP           September 2025
                                 
                            ___                                  ___
     H3AgentEIDs     ___  /     \           H3AgentEIDs   ___  /     \
              ___  /     | h3.rB |                 ___  /     | h3.rB |
            /     | h3.rB \ ___ /                /     | h3.rB \ ___ /
           | h3.rB \ ___ /  sXTR                | h3.rB \ ___ /  sXTR
            \ ___ /  sXTR   ||                   \ ___ /  sXTR    ||
              sXTR   ||     ||                    sXTR     ||     ||
               ||    ||     ||                      ||     ||     ||
               ||    ||     ||                      ||     ||     ||
                          EdgeRTR                EdgeRTR 
                             (                      )
                            (    Underlay Cloud      )
                             (                      )
                           EdgeRTR               EdgeRTR 
                           ||                    ||
                           ||                    ||
              MobilityClientA::cXTR   cXTR::MobilityClientB  
                  |          ___    ___    ___     |              
                 App       /     \/     \/     \ Source
                            h3.rS  h3.rS  h3.rS    
                           \ ___ /\ ___ / \ __ /
       
       
                         Figure 3: H3-LISP Network

    - MobilityClientA source detections used by MobilityClientB app
    - Sources share information only through the Geolocation agents
    - ClientXTR (cXTR):encapsulates packets over access to EdgeRTR
    - ServerXTR (sXTR):encapsulates packets over metro area to EdgeRTR
    - Notifications: from Geolocation agents replicated by EdgeRTRs


  Barkai, et al.          Expires March 24, 2026          [Page 6]



  Internet-Draft                     LISP           September 2025

  3.  Deployment Assumptions
   
  The authorization of Mobility Clients to the mobility network is 
  renewed while driving. The AAA procedure described below can be used
  as an example for obtaining EIDs and EdgeRTRs, and for enabling the
  use of the network. Diameter [RFC6733] based AAA can be used:  
     1) obtain the address of the mobility-network AAA using DNS
     2) obtain MobilityClientEIDs and EdgeRTRs from AAA procedure
     3) renewed periodically from AAA while using the network

       MobilityClient DomainNameServer    AAA Server   MobilityEdgeRTR
       |                    |                   |                    |
       | lookup AAA Server  |                   |                    |
       |------------------->|                   |                    |
       |<-------------------|                   |                    |
       |   AAA  Server IP   |                   |                    |
       |                    |                   |                    |
       |  Client identifier and credentials     |                    |
       |--------------------------------------->|                    |
       |                    |                   |Provision Client EID|
       |                    |                   |------------------->|
       |                    |                   |<-------------------|
       |                    |                   | Ack Provisioned EID|
       |  Send ClientEID,EdgeRTR RLOC           |                    |
       |<---------------------------------------|                    |
       .                                                             .
       .       Use The H3-LISP Geolocation Mobility Network          .
       .                                                             .
       |<----------------------------------------------------------->|
       .    Renew AAA ClientEID and EdgeRT provisioning              .   

          Figure 4: Example AAA procedure for mobility clients

    Detections are enumerated in 16 fields x 16 enumerations. Nibbles
    named using hexadecimal index according to the position where most
    significant nibble has index 0. Enumerations defined in section 8.

      0       1       2       3       4       5       6       7
      +-------+-------+-------+-------+-------+-------+-------+-------+
      |-0-|-1-|-2-|-3-|-4-|-5-|-6-|-7-|-8-|-9-|-A-|-B-|-C-|-D-|-E-|-F-|
      |012301230123012301230123 Index  01230123012301230123012301230123
      +---------------------------------------------------------------+
              Figure 5: Nibble based detection enumeration

  Barkai, et al.          Expires March 24, 2026          [Page 7]



  Internet-Draft                     LISP           September 2025


  4. Clients-Agents Networking

   The mobility network functions as a standard LISP overlay that
   delivers unicast and multicast packets across data plane XTRs, which
   are used in the stack of each mobility client and server. ClientXTRs
   and ServerXTRs are associated with EdgeRTRs, which allows
   MobilityClients to "show up" at any location within the mobility
   network, regardless of the network provider or network address
   translation domain. This structure also enables any H3 agent EID to
   be instantiated, delegated, or failed over to any compute location.
   In this specification, we assume a semi-random association between
   ClientXTRs and EdgeRTRs assigned by the AAA procedure, with a pool of
   EdgeRTRs, which can be dynamically allocated, distributing the load
   of MobilityClients within a given metro area. We also assume that
   EdgeRTRs are topologically equivalent and use LISP to encapsulate
   traffic to and from other EdgeRTRs. It is possible for there to be
   more than one ClientEID in the same process using the same ClientXTR.
   The implementation of such multiplexing is not specified.

            H3AgentEID == ServerXTR        ServerXTR == H3AgentEID
           (Encryption Decryption)         (Encryption Decryption)
                                    ^     ^
                               EdgeRTR X EdgeRTR
                                    v     v
              (Encryption Decryption)     (Encryption Decryption)
        MobilityClient <> ClientXTR        ClientXTR <> MobilityClient

    Figure 6: LISP network connecting MobilityClients and H3AgentEIDs

    Encode HID to EID:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           AFI = 16387         |     Rsvd1     |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |               |            Length = 8         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             HID (high-order)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             HID (low-order)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 7: Encoding HIDs in H3AgentEIDs

  Barkai, et al.          Expires March 24, 2026          [Page 8]



  Internet-Draft                     LISP           September 2025

  5. Mobility Unicast and Multicast

   The day in a life of unicast road-segment mapping upload:

    1. A client detects condition of interest using AI camera
    2. The client uses its GPS to establish its h3.rS location
    3. It then estimates the h3.rS location of the detection
    4. Detection h3.rS center is used to calculate h3.rB => H3ServerEID
    5. Client sends (encrypted) location-detection via its ClientXTR

      Outer Header src/dest: ClientXTR RLOC, EdgeRTR RLOC
      Inner Header src/dest: ClientEID, H3AgentEID

    6. EdgeRTR gleans and caches ClientEID and ClientXTR RLOC
    7. EdgeRTR resolves RLOC of remote EdgeRTR, and re-encapsulates:

      Outer Header src/dest: EdgeRTR RLOC, remote EdgeRTR RLOC
      Inner Header src/dest: ClientEID, H3AgentEID

    8. Remote EdgeRTR lookups H3ServerEID ServerXTR RLOC, 
       re-encapsulates:

      Outer Header src/dest: EdgeRTR RLOC, ServerXTR RLOC
      Inner Header src/dest: ClientEID, H3AgentEID

    9. ServerXTR delivers ClientEID message to H3AgentEID

   The detection message headers consist of the following fields:

    - Outer headers size = 40 (IPv6) + 8 (UDP) + 8 (LISP) = 56
    - Inner headers size = 40 (IPv6) + 8 (UDP) + 4 (Nexagon Header) = 52
    - 1500 (MTU) - 56 - 52 = 1392 bytes of effective payload size


  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
  |  Type         |gzip |        Reserved         | Pair Count = X |NXGN
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

                      Figure 8: Nexagon header format

   Nexagon Header allows for key-value (kv) tuples or value-key,key
   ...(vkkk) using the same formats of key and value outlined bellow:



  Barkai, et al.          Expires March 24, 2026          [Page 9]



  Internet-Draft                     LISP           September 2025

   Nexagon Header Type 0:reserved (*)
   Type 1:key-value, key-value.. 1392 / (8 + 8) = 87 pairs
   Type 2:value, key,key,key.. (1392 - 8) / 8 = 173 h3.rS IDs
   Type 3-255: unassigned
   Nexagon Header GZIP field: 0x000 no compression, or(**) GZIP version.
   Nexagon Header Reserved bits
    Nexagon Header key and value count (in any format kv or vkkk)

  (*)  Reserved fields are specified as being set to 0 on transmission,
         ignored when received.
  (**) GZIP refers to entire kv or vkkk payload and major GZIP version,
         packets with unsupported GZIP version are dropped
































  Barkai, et al.          Expires March 24, 2026         [Page 10]



  Internet-Draft                     LISP           September 2025



   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
  |Version| Traffic Class |           Flow Label                  |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |         Payload Length        |  Next Header  |   Hop Limit   |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  |
  +                                                               +  |
  |                                                               |  |
  +                    Source MobilityClientEID                   +  |
  |                                                               | IPv6
  +                                                               +  |
  |                                                               |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  |
  +                                                               +  |
  |                                                               |  |
  +                       Dest H3AgentEID                         +  |
  |                                                               |  |
  +                                                               +  |
  |                                                               | /
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Source Port = xxxx      |       Dest Port = xxxx        | \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
  |           UDP Length          |        UDP Checksum           | /
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
  |  Type         |gzip |        Reserved         | Pair Count =  | NXGN
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
  |                                                               |
  +                       64bit h3.rS ID                        +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                       64bit State                            +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 9: Uploaded detections packet format



  Barkai, et al.          Expires March 24, 2026         [Page 11]



  Internet-Draft                     LISP           September 2025


   Each H3Agent is also an IP Multicast Source used to update
   subscribers on the state of the h3.rS tiles in the h3.rB area.
   We use [RFC8378] signal-free multicast to implement overlay channels.
   Mobility-networks have many channels with thousands subscribers each.
   MobilityClients driving through/subscribing to an h3.rB area issue
   group address report based on any mechanism supported by [RFC8378].
   Example report formats are specified in [RFC4604]. It is advised that
   clients establish a ring of objects on their areas of interest.
   Report messages are encapsulated between ClientXTRs and EdgeRTRs.

   The day in a life of multicast notification update:

   1. H3AgentEID determines change or timing requiring an update

   2. H3AgentEID sends (S,G) update message via its ServerXTR

       Outer Header src/dest: ServerXTR RLOC, EdgeRTR RLOC
       Inner Header (S,G): H3ServerEID, EID chosen for theme

   3. EdgeRTR resolves subscribed remote EdgeRTRs, replicates

       Outer Header src/dest: EdgeRTR RLOC, remote EdgeRTR RLOC
       Inner Header (S,G): H3ServerEID, EID chosen for theme

   4. EdgeRTRs lookups ClientEIDs ClientXTRs RLOCs, replicates

       Outer Header src/dest: EdgeRTR RLOC, ClientXTR RLOC
       Inner Header (S,G): H3ServerEID, EID chosen for theme

   5. ClientXTR delivers multicast channel update message to clientEID













  Barkai, et al.          Expires March 24, 2026         [Page 12]



  Internet-Draft                     LISP           September 2025




  Multicast update packets are of the following structure:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
  |Version| Traffic Class |           Flow Label                  |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |         Payload Length        |  Next Header  |   Hop Limit   |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  |
  +                                                               +  |
  |                                                               |  |
  +                      Source H3AgentEID                   +  |
  |                                                               | IPv6
  +                                                               +  |
  |                                                               |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  |
  +                                                               +  |
  |                                                               |  |
  +                          Group Address                        +  |
  |                                                               |  |
  +                                                               +  |
  |                                                               | /
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       Source Port = xxxx      |       Dest Port = xxxx        | \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
  |           UDP Length          |        UDP Checksum           | /
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
  |                                                               |NXGN
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
  ~                            Nexagons Payload                   ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 10: multicast update packet header






  Barkai, et al.          Expires March 24, 2026         [Page 13]



  Internet-Draft                     LISP           September 2025




   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
  |  Type =   1   |gzip |        Reserved         | Pair Count = X|NXGN
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
  |                                                               |
  +                       64bit h3.rS ID                        +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                       64bit State                            +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                       64bit h3.rS ID                        +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                       64bit State                            +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 11: multicast update payload, key-value, key-value..


















  Barkai, et al.          Expires March 24, 2026        [Page 14]



  Internet-Draft                     LISP          September 2025


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
  |  Type =   2   |gzip |     Reserved            |H3R15 Count = X|NXGN
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
  |                                                               |
  +                       64bit State                            +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                       64bit h3.rS ID                        +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                       64bit h3.rS ID                        +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                       64bit h3.rS ID                        +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 12: multicast update payload, value, key, key.. 




















  Barkai, et al.          Expires March 24, 2026        [Page 15]



  Internet-Draft                     LISP          September 2025



  6.  Security Considerations

   The LISP mobility-network is inherently secure and private.
   All information is conveyed to clients using provisioned Geolocation
   agents. MobilityClients receive information only via geospatial
   channels originating at provisioned agents, replicated by EdgeRTRs.
   All traffic is carried over encrypted encapsulation.

  7.  Privacy Considerations

   In the mobility network, MobilityClients obtain temporary clientEIDs
   and RLOCs of EdgeRTRs through an AAA process in order to access the
   network for a certain period. The interface between MobilityClients
   and EdgeRTRs is the most sensitive from a privacy perspective, as the
   EdgeRTR can determine the client RLOC and the h3.rB area that the
   client is engaged with based on header information, even though the
   traffic on this interface is tunneled and the detection content is
   encrypted between ClientXTR and EdgeRTR. Enterprises such as vehicle
   OEMs or carriers can use their own EdgeRTRs (BYO_RTRs), which are 
   pre-provisioned to use the mapping system and are approved by other
   EdgeRTRs. Beyond the client to EdgeRTR hop, the mapping system does
   not hold MobilityClientEID information and remote EdgeRTRs are only
   aware of clients' temporary EIDs. H3AgentEIDs decrypt and parse
   actual h3.rS detections, taking into account MobilityClientEID
   credentials encoded in the client EID and assigned by AAA to avoid
   poorly made or localized detections.

   In summary the privacy risk mitigations are:
   (1) tapping: all communications are through tunnels therefore
     may be encrypted using IP-Sec or other supported point to point
     underlay standards.
   (2) spoofing: it is very hard to guess a MobilityClientEID valid for
     a short period of time. Clients and H3Agents EIDs are provisioned
     in EdgeRTRs, Clients using the AAA procedure, H3Agents via dev-ops.
   (3) credibility: the interface crowd-sources and does not assume to
     trust single detections. Credit history track MobilityClient
     aggregate scores from all agents are delivered to AAA subsystem 
   (4) geo-privacy: Only EdgeRTRs are aware of both clients' RLOC and
     geo-location, only AAA is aware of client IDs credentials and 
     credit but not geo-location. Ongoing client credit adjustments span
     all H3Agents administratively to AAA without specific geo-source.

  Barkai, et al.          Expires March 24, 2026        [Page 16]



  Internet-Draft                     LISP          September 2025

  8.  Acknowledgments

   We would like to kindly thank Joel Halperin for helping structure the
   AAA section and Geo-Privacy provisions, Luigi Lannone for promoting
   such LISP based Compute Aware Networking use-cases, helping structure
   the IANA section, and shepherding this draft to completion. We would
   like to thank George Ericson from Dell, Lei Zhong from Toyota, Mikael
   Klein from Ericsson, Leifeng Ruan from Intel, Ririn Andarini from NTT,
   for helping with Geolocation and Dataflow Virtualization terminology
   and key-issues during joint work at the AECC. We would like to thank
   Professor Trevor Darrel and Professor Fisher Yu of BDD for reviewing
   IANA enumerations for detections-consolidations feasible by visionAI
   and Edge Computing. We would like to thank Isaac Brodsky, Nick
   Rabinowitz, David Ellis, and AJ Friend of the H3 steering committee
   for reviewing the use of the H3 grid in the lisp-nexagon network.





























  Barkai, et al.          Expires March 24, 2026        [Page 17]



  Internet-Draft                     LISP          September 2025

  9.  IANA Considerations
  In accordance with BCP 26 [RFC8126].IANA is asked to create a registry
  named NEXAGON with the following sub registries.
  +----------+------------------+----------+---------------------------+
  +----------+------------------+----------+---------------------------+
  | Type     | nexagon-type     | 0-7      | Type of key-value encoding|
  | gzip     | nexagon-gzip     | 8-10     | gzip major version used   |
  | PairCount| nexagon-paircount| 24-31    | key-value pair count      |
  +----------+------------------+----------+---------------------------+


  Barkai, et al.          Expires March 24, 2026        [Page 18]



  Internet-Draft                     LISP          September 2025


  10.  Normative References


   [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
       Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)",
       RFC 9300, DOI 10.17487/RFC9300,
       October 2022, <https://www.rfc-editor.org/info/rfc9300>.

   [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed.,
       "Locator/ID Separation Protocol (LISP) Control Plane",
        RFC 9301, DOI 10.17487/RFC9301,
       October 2022, <https://www.rfc-editor.org/info/rfc9301>.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
       Group Management Protocol Version 3 (IGMPv3) and Multicast
       Listener Discovery Protocol Version 2 (MLDv2) for Source-
       Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
       December 2006, <https://www.rfc-editor.org/info/rfc4604>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
       Ed., "Diameter Base Protocol", RFC 6733,
       DOI 10.17487/RFC6733, October 2012,
       <http://www.rfc-editor.org/info/rfc6733>.

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

   [RFC8378]  Farinacci, D., Moreno, V., "Signal-Free Locator/ID
      Separation Protocol (LISP) Multicast", RFC8378,
      DOI 10.17487/RFC8378, May 2018,
      <https://www.rfc-editor.org/info/rfc8378>.

   [H3] Uber Technologies Inc. [n.d.]. H3: Ubers Hexagonal
       Hierarchical Spatial Index, May 2021,
       <https://eng.uber.com/h3>.


  Barkai, et al.          Expires March 24, 2026        [Page 19]



  Internet-Draft                     LISP          September 2025


    Authors' Addresses

     Sharon Barkai
     Oterra
     CA
     USA

     Email: sbarkai@gmail.com


     Bruno Fernandez-Ruiz
     Nexar
     London
     UK

     Email: b@getnexar.com


     Rotem Tamir
     Ariga
     Israel

     Email: r@ariga.io

     Alberto Rodriguez-Natal
     Cisco Systems
     170 Tasman Drive
     San Jose, CA
     USA

     Email: natal@cisco.com

     Fabio Maino
     Cisco Systems
     170 Tasman Drive
     San Jose, CA
     USA

     Email: fmaino@cisco.com





  Barkai, et al.          Expires March 24, 2026        [Page 20]



  Internet-Draft                     LISP          September 2025



     Albert Cabellos-Aparicio
     Universitat Politecnica de Catalunya
     Barcelona
     Spain

     Email: acabello@ac.upc.edu

     Jordi Paillisse-Vilanova
     Universitat Politecnica de Catalunya
     Barcelona
     Spain

     Email: jordip@ac.upc.edu

     Dino Farinacci
     lispers.net
     San Jose, CA
     USA

     Email: farinacci@gmail.com






















  Barkai, et al.          Expires March 24, 2026          [Page 21]


name: draft-cosmos-protocol-specification
rev: 00
title: The Cosmos Protocol Specification (Trust-Native Semantic Protocol)
time: 2026-01-02T07:13:44Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-06T07:13:44Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.766321+00:00
source: ietf
abstract:
  The Cosmos Protocol (Trust-Native Semantic Protocol) defines a badge-
     based identity and communication system intended for deployments that
     prefer not to rely on external consensus or blockchain
     infrastructure.  Cosmos supports trust-native communication and
     decentralized identity management through cryptographically signed
     badges that operate without mandatory external trust systems.  The
     protocol also supports passwordless authentication flows using badge-
     based credentials and biometric authenticators, reducing reliance on
     traditional password mechanisms.

     The Cosmos Protocol introduces several foundational innovations that
     together form an integrated identity-native communication substrate.
     These include: (1) Badge-Based Identity -- cryptographically signed,
     capability-bearing identifiers designed to operate without requiring
     blockchain or distributed ledger infrastructure, while allowing
     deployments to integrate such systems if desired; (2) Trust Scoring
     -- reputation-anchored trust models (domain-bound for DNS networks,
     star-bound for Cosmos-native networks) that enable cross-star
     capability granting and trust-based authorization without requiring
     new badges; (3) Lumen Encryption -- uses post-quantum candidate
     cryptographic primitives (see [RFC-XXXX-Lumen]), badge-native
     encryption designed to support forward secrecy; (4) Echo Grammar --
     semantic message structures that provide intent clarity, UI hints,
     and agent compatibility; (5) Capsule System -- universal, encrypted
     containers for communication and storage; (6) Slipstream Transport
     (TNTP) -- a trust-native transport protocol with badge-based
     sessions, intent-aware routing, and the ability to operate without
     blockchain or external consensus dependencies; (7) Ramp and SDFF
     Serialization -- deterministic text and binary formats that provide
     canonical structure for all Cosmos data; (8) Profile System --
     portable, domain-scoped user profiles with badge-based access
     control; and (9) Productivity Protocols -- standardized scheduling,
     contacts, and calendaring protocols (Comet, Nebula, Nova) that
     provide a badge-native model that can serve as an alternative to
     multiple legacy standards.

     Cosmos badges are Ramp (Slope Data Format, SDF) documents with
     optional DID compatibility, allowing integration with existing
     decentralized identity systems while preserving the protocol's self-
     contained architecture within Cosmos deployments.  The badge system
     addresses key limitations in current identity approaches, including
     the lack of enterprise-grade lifecycle management, star-bound trust
     establishment, and the ability to operate independently of external
     infrastructure in constrained or disconnected environments.

     The protocol provides a viable alternative to complex identity stacks
     while maintaining interoperability with existing standards, making it
     suitable for both greenfield deployments and integration with
     existing systems.

full_text:
  Network Working Group                                       A. Hernandez
  Internet-Draft                                        Varlil Corporation
  Intended status: Standards Track                          1 January 2026
  Expires: 5 July 2026


     The Cosmos Protocol Specification (Trust-Native Semantic Protocol)
                   draft-cosmos-protocol-specification-00

  Abstract

     The Cosmos Protocol (Trust-Native Semantic Protocol) defines a badge-
     based identity and communication system intended for deployments that
     prefer not to rely on external consensus or blockchain
     infrastructure.  Cosmos supports trust-native communication and
     decentralized identity management through cryptographically signed
     badges that operate without mandatory external trust systems.  The
     protocol also supports passwordless authentication flows using badge-
     based credentials and biometric authenticators, reducing reliance on
     traditional password mechanisms.

     The Cosmos Protocol introduces several foundational innovations that
     together form an integrated identity-native communication substrate.
     These include: (1) Badge-Based Identity -- cryptographically signed,
     capability-bearing identifiers designed to operate without requiring
     blockchain or distributed ledger infrastructure, while allowing
     deployments to integrate such systems if desired; (2) Trust Scoring
     -- reputation-anchored trust models (domain-bound for DNS networks,
     star-bound for Cosmos-native networks) that enable cross-star
     capability granting and trust-based authorization without requiring
     new badges; (3) Lumen Encryption -- uses post-quantum candidate
     cryptographic primitives (see [RFC-XXXX-Lumen]), badge-native
     encryption designed to support forward secrecy; (4) Echo Grammar --
     semantic message structures that provide intent clarity, UI hints,
     and agent compatibility; (5) Capsule System -- universal, encrypted
     containers for communication and storage; (6) Slipstream Transport
     (TNTP) -- a trust-native transport protocol with badge-based
     sessions, intent-aware routing, and the ability to operate without
     blockchain or external consensus dependencies; (7) Ramp and SDFF
     Serialization -- deterministic text and binary formats that provide
     canonical structure for all Cosmos data; (8) Profile System --
     portable, domain-scoped user profiles with badge-based access
     control; and (9) Productivity Protocols -- standardized scheduling,
     contacts, and calendaring protocols (Comet, Nebula, Nova) that
     provide a badge-native model that can serve as an alternative to
     multiple legacy standards.





  Hernandez                  Expires 5 July 2026                  [Page 1]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     Cosmos badges are Ramp (Slope Data Format, SDF) documents with
     optional DID compatibility, allowing integration with existing
     decentralized identity systems while preserving the protocol's self-
     contained architecture within Cosmos deployments.  The badge system
     addresses key limitations in current identity approaches, including
     the lack of enterprise-grade lifecycle management, star-bound trust
     establishment, and the ability to operate independently of external
     infrastructure in constrained or disconnected environments.

     The protocol provides a viable alternative to complex identity stacks
     while maintaining interoperability with existing standards, making it
     suitable for both greenfield deployments and integration with
     existing systems.

  Note

     This document is in draft status and represents a proposed standard
     for the Cosmos Protocol specification.

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

  Copyright Notice

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











  Hernandez                  Expires 5 July 2026                  [Page 2]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     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.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
       2.2.  Solution Overview . . . . . . . . . . . . . . . . . . . .   5
       2.3.  Why Not Existing Solutions? . . . . . . . . . . . . . . .   7
         2.3.1.  Why Not Decentralized Identifiers (DIDs)? . . . . . .   7
         2.3.2.  Why Not LDAP or Active Directory? . . . . . . . . . .   8
     3.  Scope and Applicability . . . . . . . . . . . . . . . . . . .   9
     4.  Requirements Language . . . . . . . . . . . . . . . . . . . .  10
     5.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .  13
       6.1.  Core Principles . . . . . . . . . . . . . . . . . . . . .  13
       6.2.  Architecture Overview . . . . . . . . . . . . . . . . . .  13
       6.3.  Component Relationships . . . . . . . . . . . . . . . . .  15
       6.4.  Cosmos as Network Stack Evolution . . . . . . . . . . . .  15
         6.4.1.  TCP/IP Stack Comparison . . . . . . . . . . . . . . .  16
     7.  Badge System  . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.  Manifest  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
     9.  Policy Substrate (Governance Substrate) . . . . . . . . . . .  18
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  19
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  20
       13.2.  Informative References . . . . . . . . . . . . . . . . .  20
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

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




  Hernandez                  Expires 5 July 2026                  [Page 3]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


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

  2.  Introduction

     This document specifies the Cosmos Protocol, a trust-native, badge-
     based identity and communication system designed for enterprise
     deployment without requiring blockchain or distributed ledger
     infrastructure.  The protocol provides a viable alternative to
     existing decentralized identity solutions by combining identity
     management, trust scoring, encryption, and communication in a
     unified, self-contained system within Cosmos deployments.

     This document does not obsolete or update any existing RFCs.  It
     defines a new protocol specification intended for use in enterprise
     identity and communication systems, decentralized applications, and
     environments that can operate without external consensus or
     blockchain infrastructure.

  2.1.  Problem Statement

     Current decentralized identity and communication systems face
     fundamental limitations that prevent widespread adoption and
     practical deployment:

     *Infrastructure Dependencies*: Most decentralized identity solutions
     require complex infrastructure dependencies including blockchain
     networks, distributed ledgers, or specialized consensus mechanisms.
     These dependencies create barriers to deployment, especially in
     constrained environments, enterprise settings, or scenarios requiring
     rapid deployment.

     *Trust Quantification Challenges*: Existing systems lack effective
     mechanisms for quantifying trustworthiness between entities.  Without
     reliable trust metrics, users cannot make informed decisions about
     communication partners, leading to either excessive caution or
     inappropriate trust.

     *Enterprise Integration Gaps*: Current solutions often focus on
     individual identity management but fail to address enterprise
     requirements such as lifecycle management, organizational
     hierarchies, domain-based policies, and integration with existing
     infrastructure.






  Hernandez                  Expires 5 July 2026                  [Page 4]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     *Communication Fragmentation*: Identity and communication systems are
     typically separate, requiring complex integration work and creating
     security gaps between authentication and messaging.

     *Walled Garden Communication*: Modern communication platforms create
     walled gardens where users on different platforms cannot communicate
     effectively.  This forces users to rely on email systems for cross-
     platform communication, even when other chat and messaging solutions
     may be preferred.  Users must maintain multiple accounts across
     different platforms, fragmenting their communication and social
     graph.  Cross-platform interoperability is limited or non-existent,
     preventing users from choosing preferred communication tools while
     maintaining universal connectivity.

     *Profile Data Fragmentation and Lock-in*: User profiles are
     fragmented across multiple platforms, each with its own data silo.
     Users must recreate their profiles on each platform, losing their
     social graph and content when switching providers.  Profile data is
     locked into individual platforms with no portability, preventing
     users from migrating their profiles, content, and relationships.
     Users lack control over their profile data and privacy settings
     across platforms, leading to data silos and vendor lock-in.

     *Scalability Limitations*: Many decentralized systems struggle with
     scalability, either requiring significant computational resources or
     failing to handle enterprise-scale deployments effectively.

     *Password-Based Authentication Weaknesses*: Traditional password-
     based authentication systems suffer from fundamental security
     weaknesses including password reuse, weak passwords, password theft,
     phishing attacks, and the burden of password management.  Users are
     forced to create, remember, and manage passwords across multiple
     services, leading to security vulnerabilities and poor user
     experience.  Password-based systems also lack built-in identity
     verification and trust establishment mechanisms, requiring external
     trust systems.

  2.2.  Solution Overview

     The Cosmos Protocol addresses these challenges through a
     comprehensive badge-based identity and communication system that
     supports the following capabilities:









  Hernandez                  Expires 5 July 2026                  [Page 5]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     *Infrastructure Independence*: Cosmos can operate without blockchain,
     distributed ledgers, or external consensus mechanisms.  The protocol
     is self-contained within Cosmos deployments and can be deployed in
     any environment, including constrained environments and enterprise
     data centers, without external consensus or blockchain
     infrastructure.

     *Star-bound Trust Scoring*: A trust algorithm designed to reduce
     manipulation risks that quantifies trustworthiness using star
     reputation, network effects, and behavioral patterns, enabling
     informed trust decisions without centralized authorities.

     *Enterprise-ready Identity Management*: Lifecycle management for
     badge issuance, renewal, revocation, and organizational hierarchies,
     designed for enterprise deployment scenarios.

     *Productivity Protocols*: Integrated scheduling, contacts, and
     calendar protocols (Comet, Nebula, Nova) that interoperate with the
     badge-based identity system, reducing security gaps between
     authentication and communication.

     *Cross-Provider Interoperability*: Interlink enables cross-provider
     interoperability for participating platforms.  Users can communicate
     seamlessly across different providers while each provider maintains
     their unique features and user experience.  This enables users to use
     preferred chat and messaging solutions for cross-platform
     communication while maintaining connectivity across participating
     platforms.  Users maintain a single identity and social graph that
     works across participating providers.

     *Profile System*: The Cosmos Profile System is designed to support
     portability across participating providers, subject to provider
     implementation and policy.  Cosmos reduces fragmentation by defining
     a consistent profile format with domain-scoped data spaces.  Users
     maintain a single canonical profile that functions across
     participating providers, reducing duplication and data silos.  Domain
     spaces allow each service to store its own data within the user's
     profile, while users retain full control over privacy settings and
     migration.  Users may migrate their profiles, content, and social
     graph between participating providers without data loss, subject to
     provider support.  Profiles are private by default and require
     explicit user action to make public, ensuring user-controlled
     visibility.

     *Scalability*: The architecture is intended to support deployments
     ranging from small installations to large multi-service environments,
     with design considerations for maintaining performance and security
     across varying scales.



  Hernandez                  Expires 5 July 2026                  [Page 6]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     *Passwordless Authentication*: Cosmos authentication flows are
     designed to minimize password usage by supporting badge-based
     credentials and FIDO2/Passkey-compliant biometric authenticators.
     Badge-based authentication reduces reliance on passwords and
     mitigates common password-related vulnerabilities such as password
     reuse, weak passwords, password theft, and phishing attacks.  Badge-
     based authentication also provides built-in identity verification and
     trust establishment within Cosmos deployments without requiring
     external trust systems.

  2.3.  Why Not Existing Solutions?

  2.3.1.  Why Not Decentralized Identifiers (DIDs)?

     DIDs [W3C-DID] provide a flexible decentralized identity model.
     Cosmos focuses on a different deployment profile by emphasizing self-
     contained operation and integrated trust scoring.  The following
     differences highlight Cosmos's approach:

     *Infrastructure Complexity*: DIDs require complex resolver
     infrastructure, method-specific implementations, and often depend on
     blockchain or distributed ledger technology.  This creates deployment
     barriers and operational complexity that Cosmos avoids through its
     self-contained design within Cosmos deployments.

     *Trust Quantification Gap*: DIDs provide cryptographic verification
     but lack built-in trust scoring mechanisms.  Cosmos includes star-
     bound trust scoring that supports informed decisions about
     communication partners without relying on external trust systems.

     *Enterprise Lifecycle Management*: DIDs focus on individual identity
     but do not provide enterprise features such as organizational
     hierarchies, star-based policies, or integrated lifecycle management,
     which Cosmos is designed to support.

     *Communication Integration*: DIDs are primarily identity-focused and
     require separate integration with communication systems.  Cosmos
     provides unified identity and communication protocols, reducing
     integration complexity and security gaps between identity and
     communication systems.

     *Deployment Flexibility*: DIDs often require specific infrastructure
     choices (blockchain, resolver networks) that limit deployment
     options.  Cosmos can be deployed in any environment without
     infrastructure dependencies.






  Hernandez                  Expires 5 July 2026                  [Page 7]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     *Badge-DID Compatibility*: Cosmos badges are Ramp (Slope Data Format,
     SDF) [RFC-XXXX-Ramp] documents with optional DID [W3C-DID]
     compatibility, allowing integration with existing decentralized
     identity systems while preserving the protocol's self-contained
     architecture within Cosmos deployments.  This enables Cosmos
     deployments to interoperate with DID ecosystems without depending on
     external DID infrastructure.

     The Cosmos approach provides an integrated, enterprise-oriented
     solution that addresses practical deployment needs while maintaining
     interoperability with existing decentralized identity standards.

  2.3.2.  Why Not LDAP or Active Directory?

     LDAP [RFC4511] and Active Directory provide mature directory
     services.  Cosmos targets scenarios that require integrated trust
     scoring, badge-based authentication, and unified communication
     semantics.  The following differences highlight Cosmos's approach:

     *Password-Based Authentication*: All LDAP implementations (including
     Active Directory, OpenLDAP, 389 Directory Server, Apache Directory
     Server, FreeIPA, eDirectory, and other LDAP-based directory services)
     rely on password-based authentication, which is vulnerable to
     password reuse, weak passwords, password theft, and phishing attacks.
     Cosmos uses badge-based authentication with FIDO2/Passkey-compliant
     biometric authentication, eliminating the need for passwords within
     standard Cosmos authentication flows and providing cryptographic
     proof of identity.

     *Centralized Architecture*: LDAP and Active Directory are centralized
     systems with single points of failure, domain controller
     dependencies, and global catalog bottlenecks.  Cosmos supports
     distributed, edge-based deployment models that reduce single-point-
     of-failure risks, enabling global distribution and automatic scaling.

     *Trust Establishment Gap*: LDAP and Active Directory lack effective
     mechanisms for establishing and quantifying trust between entities.
     Cosmos includes star-bound trust scoring that enables informed
     decisions about communication partners without requiring external
     trust systems.

     *Communication Integration*: LDAP and Active Directory are primarily
     identity/directory-focused and require separate integration with
     communication systems.  Cosmos provides unified identity and
     communication protocols, reducing integration complexity and security
     gaps between authentication and messaging systems.





  Hernandez                  Expires 5 July 2026                  [Page 8]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     *Directory Scope Limitation*: LDAP is purely a directory query
     protocol for hierarchical data structures.  Cosmos is an integrated
     identity and communication protocol that includes directory-like
     query capabilities (Manifest) as one component of a broader system
     that integrates identity, trust, encryption, messaging, and
     productivity protocols into a unified, badge-native system.

     *Key Advantages*: Cosmos provides passwordless authentication, trust-
     based access control, integrated communication, distributed
     architecture, cryptographic verification, cross-star federation,
     intended post-quantum resistance, platform-agnostic enforcement, and
     real-time policy updates.  Cosmos implementations can integrate with
     existing LDAP/Active Directory infrastructure through adapter layers,
     enabling gradual migration.

  3.  Scope and Applicability

     This specification defines the full Cosmos Protocol, including:

     *  Badge-based identity system with DID compatibility

     *  Domain-bound trust scoring algorithm

     *  Lumen encryption system [RFC-XXXX-Lumen] with intended post-
        quantum resistance

     *  Echo grammar [RFC-XXXX-Echo] for semantic messaging

     *  Capsule system [RFC-XXXX-Capsules] for encrypted communication and
        storage

     *  Slipstream Transport Protocol (TNTP) [RFC-XXXX-Slipstream]

     *  Ramp (Slope Data Format, SDF) [RFC-XXXX-Ramp] and SDFF (Self-
        Describing Field Format) [RFC-XXXX-SDFF] for data serialization

     *  Profile system [RFC-XXXX-Profile]

     *  Productivity suite protocols (Comet [RFC-XXXX-Comet], Nebula
        [RFC-XXXX-Nebula], Nova [RFC-XXXX-Nova])

     The protocol is applicable to:

     *  Enterprise identity and communication systems

     *  Decentralized applications requiring trust-native communication





  Hernandez                  Expires 5 July 2026                  [Page 9]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     *  Constrained environments that can operate without external
        consensus or blockchain infrastructure

     *  Systems requiring deployments ranging from small installations to
        large multi-service environments

     *  Environments requiring gradual migration from legacy systems

     *  Complete network replacement scenarios (future work, requires
        separate transport protocol specification)

  4.  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 BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  5.  Terminology

     This document defines the following key terms:

     *Protocol Name vs. Brand Name*:

     The relationship between "TNSP" (Trust-Native Semantic Protocol) and
     "Cosmos" follows the same pattern as IEEE 802.11 and WiFi, or IEEE
     802.15.1 and Bluetooth:

     *  *TNSP (Trust-Native Semantic Protocol)*: The technical protocol
        specification name used in RFCs, technical documentation, and
        protocol implementations.  TNSP is the formal network-layer
        protocol in the Cosmos stack, providing an identity-native
        alternative to IP.

     *  *Cosmos*: The brand/marketing name used in user-facing
        documentation, product names, and marketing materials.  Cosmos is
        the user-friendly name for the complete protocol ecosystem.

     *  *Relationship*: TNSP is the technical protocol specification (like
        IEEE 802.11), and Cosmos is the brand name (like WiFi).  When
        referring to the technical protocol specification, use "TNSP" or
        "Trust-Native Semantic Protocol".  When referring to the brand,
        ecosystem, or user-facing aspects, use "Cosmos".

     *  *Usage Guidelines*:





  Hernandez                  Expires 5 July 2026                 [Page 10]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


        -  Use "TNSP" in technical contexts: RFCs, protocol
           specifications, code comments, technical documentation, network
           layer discussions

        -  Use "Cosmos" in brand/marketing contexts: user documentation,
           product names, marketing materials, ecosystem discussions

        -  This document uses "Cosmos Protocol" in the title and abstract
           for brand recognition, but refers to "TNSP" when discussing the
           technical network layer protocol specification

     *  *Badge*: A cryptographically signed identifier that serves as
        identity, capability, and trust container in the Cosmos Protocol.
        Badges are self-contained and do not require external
        infrastructure for validation.

     *  *Manifest*: The core authority service in the Cosmos ecosystem
        that consolidates certificate authority, authentication service,
        and token/authorization service functions into a single unified
        service.

     *  *Star*: A Cosmos-native entity identified by a domain name (e.g.,
        "example.com") that serves as the trust anchor and authority
        boundary in the Cosmos Protocol.  Stars are Cosmos-implemented
        entities with badge-based identity, trust scoring, and Cosmos-
        native protocols.  The term "star" emphasizes the authority and
        trust anchor role: stars have gravity (authority), and all things
        around stars naturally gravitate toward them.

     *  *Domain*: The domain name that a star uses as its primary
        identifier (e.g., "example.com").  A star is identified by its
        domain name, which follows familiar TCP/IP domain naming
        conventions.

     *  *Accretion*: A bilateral trust relationship between stars where
        both sides must agree.  Accretion is a coordinated event, not
        automatic, and can be reversed.  With enough accretions, a star
        becomes a constellation (super node).

     *  *Constellation*: A star that has achieved super node status
        through sufficient accretion relationships.  When a star has
        enough accretions, it becomes a constellation with high gravity
        (trust), making it a preferred path in routing decisions.  Routing
        algorithms consider constellation relationships when selecting
        optimal paths, but routing itself is performed by service layer
        instances.





  Hernandez                  Expires 5 July 2026                 [Page 11]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     *  *Trust Score*: A computed metric that quantifies the
        trustworthiness of a star based on star reputation, network
        effects, and behavioral patterns.  The Cosmos Protocol defines two
        trust-scoring modes: domain-bound trust scoring, which derives
        signals from DNS-native sources (e.g., DNS records, TLS history,
        email reputation) when operating over DNS-addressed networks; and
        star-bound trust scoring, which uses Cosmos-native signals such as
        accretions, badge stability, and Manifest behavior when operating
        within Cosmos-native addressing and federation.  The trust-scoring
        model is extensible: any star MAY implement custom trust-scoring
        algorithms for its own use cases, and trust scores MAY be applied
        beyond network routing to authorization decisions, service
        selection, and other trust-based operations, but MUST NOT be
        treated as absolute indicators of identity legitimacy.

     *  *Lumen Encryption*: The badge-based encryption system used in the
        Cosmos Protocol that uses post-quantum candidate cryptographic
        primitives (see [RFC-XXXX-Lumen]) and is designed to support
        forward secrecy.

     *  *Echo Grammar*: The semantic message structure system in the
        Cosmos Protocol that provides UI hints and agent compatibility for
        structured communication.

     *  *Capsule*: A general-purpose encrypted container in the Cosmos
        Protocol that provides secure communication and storage
        capabilities with badge-based access control.

     *  *Interlink*: Optional social networking protocol that enables
        cross-provider interoperability for participating platforms.
        Interlink formalizes how existing Cosmos components work together
        for social networking, defining standard Echo Grammar structures
        for posts, comments, and social interactions.

     *  *Corona*: The star's outward identity surface and distributed
        presence layer.  Corona provides a minimal, canonical interface to
        the star without exposing the Manifest directly.  Corona instances
        sit between Wormhole (routing) and Manifest (authority), allowing
        stars to appear in multiple locations while remaining anchored to
        a single sovereign Manifest.  Corona exposes the star's basic
        metadata, trust hints, and canonical service endpoints.










  Hernandez                  Expires 5 July 2026                 [Page 12]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


  6.  Protocol Overview

     *Implementation Note*: Protocol versioning and evolution rules,
     including deprecation lifecycle, version compatibility, and version
     negotiation procedures, are defined in
     [RFC-XXXX-Protocol-Versioning].  This document provides only a high-
     level overview of the Cosmos Protocol primitives.

  6.1.  Core Principles

     The Cosmos Protocol is built on five fundamental principles:

     *Infrastructure Independence*: The protocol operates without
     requiring blockchain, distributed ledgers, or external consensus
     mechanisms, enabling deployment in any environment without external
     consensus or blockchain infrastructure.

     *Star-bound Trust*: Trust is established and managed at the star
     (domain) level through accretion relationships, providing natural
     organizational boundaries and policy enforcement.

     *Badge-centric Identity*: All identity, capability, and trust
     information is contained within cryptographically signed badges that
     are self-contained and verifiable.

     *Federated Communication*: Identity and communication systems are
     integrated, enabling cross-provider interoperability for
     participating platforms while maintaining security and reducing
     integration complexity.

     *Enterprise Readiness*: The protocol is designed for enterprise-scale
     deployment with comprehensive lifecycle management and organizational
     support.

  6.2.  Architecture Overview

     The Cosmos Protocol consists of several integrated components:

     *  *Badge System*: Cryptographically signed identifiers serving as
        self-contained identity, capability, and trust containers
        [RFC-XXXX-Badge]

     *  *Trust Scoring System*: Manipulation-resistant algorithm for
        quantifying trustworthiness [RFC-XXXX-Trust-Scoring]

     *  *Lumen Encryption*: Badge-based encryption using post-quantum
        candidate primitives [RFC-XXXX-Lumen]




  Hernandez                  Expires 5 July 2026                 [Page 13]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     *  *Echo Grammar*: Semantic message structures with UI hints
        [RFC-XXXX-Echo]

     *  *Capsule System*: General-purpose encrypted communication and
        storage containers [RFC-XXXX-Capsules]

     *  *Transport Layer*: Slipstream Transport Protocol (TNTP)
        [RFC-XXXX-Slipstream] with badge-based sessions

     *  *Corona*: The star's outward identity surface and distributed
        presence layer [RFC-XXXX-Corona], providing a minimal, canonical
        interface to the star without exposing Manifest directly

     *  *Profile System*: Universal profiles with domain spaces and
        privacy controls [RFC-XXXX-Profile]

     *  *Comet (Scheduling Protocol)*: Unified scheduling protocol that
        combines iTIP [RFC5546] and iMIP [RFC6047] with badge-based
        identity and trust scoring [RFC-XXXX-Comet]

     *  *Nebula (Contact Protocol)*: Unified contact management protocol
        that combines vCard [RFC6350] and CardDAV [RFC6352] with badge-
        based identity and trust scoring [RFC-XXXX-Nebula]

     *  *Nova (Calendar Protocol)*: Unified calendar protocol that
        combines iCalendar [RFC5545], CalDAV [RFC4791], iTIP [RFC5546],
        and iMIP [RFC6047] with badge-based identity and trust scoring
        [RFC-XXXX-Nova]

     *Implementation Scope Note*: While the protocol defines all
     components, different entities implement different parts based on
     their role:

     *  *Manifest Operators*: Implement badge system, trust scoring, and
        badge lifecycle management

     *  *Profile Providers*: Implement profile system and (optionally)
        Interlink

     *  *Service Providers*: Implement services using badges, profiles,
        and messaging as needed

     *  Entities can combine roles (e.g., a manifest operator can also
        operate as a profile provider)







  Hernandez                  Expires 5 July 2026                 [Page 14]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


  6.3.  Component Relationships

     All components work together to provide an integrated identity and
     communication system:

     *  Badges provide identity and authentication for all other
        components

     *  Trust scoring informs decisions across all communication and
        access control

     *  Lumen encryption secures all communication and storage

     *  Echo grammar structures all messages for semantic processing

     *  Capsules package all data for secure transmission and storage

     *  Transport layer provides secure networking consistent with Cosmos
        transport requirements

     *  Corona provides the star's identity surface and distributed
        presence, sitting between routing (Wormhole) and authority
        (Manifest) to protect Manifest and enable distributed presence

     *  Profiles manage user information and privacy

     *  Manifest-based resolution enables star discovery and capability
        verification

     *  Comet (Scheduling Protocol) enables badge-based scheduling with
        trust-scored permissions, designed for enterprise-scale
        deployments

     *  Nebula (Contact Protocol) enables badge-based contact management
        with trust-scored relationships and cross-star interoperability

     *  Nova (Calendar Protocol) enables badge-based calendar management
        with trust-scored access control, designed for enterprise-scale
        deployments

  6.4.  Cosmos as Network Stack Evolution

     The Cosmos Protocol provides trust-native, identity-aware networking
     that can operate over existing TCP/IP infrastructure or without IP
     infrastructure (see Deployment Phases).  Cosmos can operate in
     environments where TCP/IP infrastructure is available and can also
     operate without IP infrastructure for scenarios that can operate
     without external consensus or blockchain infrastructure (see Phase 4:



  Hernandez                  Expires 5 July 2026                 [Page 15]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     Independent Operation).

     These components operate as functional alternatives within Cosmos-
     native deployments; they do not require or mandate replacement of
     existing Internet protocols.

  6.4.1.  TCP/IP Stack Comparison

     Cosmos provides alternative protocols that correspond to layers of
     the TCP/IP network stack:

     *Layer 1-2 (Physical/Data Link):* Cosmos retains existing physical
     and data link layers (Ethernet, WiFi, Fiber, MAC addressing).  These
     layers remain unchanged as they provide fundamental hardware
     communication.

     *Layer 3 (Network):* Cosmos provides the Trust-Native Semantic
     Protocol (TNSP) as an alternative to IP.  Capsules serve as the
     fundamental unit of TNSP, analogous to IP packets at the network
     layer.  They operate at the application/identity layer with built-in
     trust, identity, and semantics.  In Phase 4 deployments, Badge IDs
     provide network-layer addressing as an alternative to IP addresses,
     and intent-based routing (defined in TNSP and service discovery
     protocols) provides an alternative to IP routing.

     *Layer 4 (Transport):* Cosmos provides Slipstream (Trust-Native
     Transport Protocol, TNTP) [RFC-XXXX-Slipstream] as an alternative to
     TCP/UDP.  Slipstream provides badge-based sessions, trust-aware flow
     control, and the ability to operate without external consensus or
     blockchain infrastructure.

     *Layer 5+ (Application):* Cosmos provides Manifest federation as an
     identity-native alternative to DNS within Cosmos-native deployments
     (see Deployment Phases).  DNS is still used for bootstrap Manifest
     discovery in early deployment phases.  BEAP (Badge-Enabled API
     Protocol) [RFC-XXXX-BEAP] with Echo Grammar provides an application
     protocol model for identity-addressed operations, badge-based
     authentication, and intent-aware routing, serving the role that HTTP/
     HTTPS plays in traditional web architectures.  Echo Grammar provides
     structured, semantic message formats in place of HTTP's unstructured
     payloads.  Badge IDs serve as identity anchors analogous to domain
     names, but with cryptographic trust semantics.

     *Implementation Note*: The complete Slipstream (Trust-Native
     Transport Protocol, TNTP) specification is defined in
     [RFC-XXXX-Slipstream].  Slipstream is the recommended transport
     protocol for Cosmos deployments and can operate both independently of
     IP (Layer 2 mode) and over IP networks (via UDP/TCP encapsulation).



  Hernandez                  Expires 5 July 2026                 [Page 16]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     Slipstream does not require blockchain or external consensus
     dependencies, but may require Manifest for badge validation in Cosmos
     deployments (see [RFC-XXXX-Slipstream] for standalone operation
     details).

  6.4.1.1.  Deployment Phases

     Cosmos can be deployed in phases, from operation over TCP/IP
     infrastructure to independent operation:

     *Phase 1 (TCP/IP Infrastructure):* Cosmos runs on TCP/IP
     infrastructure.  Slipstream (TNTP) is the recommended transport
     protocol and can operate over IP networks via UDP/TCP encapsulation.
     DNS is used for bootstrap Manifest discovery.  This enables immediate
     deployment without requiring infrastructure changes.

     *Phase 2 (Application Layer Alternatives):* Manifest federation
     provides an identity-native alternative to DNS resolution within the
     Cosmos substrate.  BEAP (Badge-Enabled API Protocol) [RFC-XXXX-BEAP]
     with Echo Grammar provides an application protocol model for
     identity-addressed operations and structured messaging, serving the
     role that HTTP/HTTPS plays in traditional web architectures.
     Capsules provide a structured, semantic alternative to HTTP content
     formats.  Slipstream (TNTP) operates over existing IP networks via
     UDP/TCP encapsulation, and Cosmos continues to use IP for the network
     layer during this phase.

     *Phase 3 (Transport Layer Alternatives):* Slipstream (Trust-Native
     Transport Protocol, TNTP) [RFC-XXXX-Slipstream] provides an
     alternative to TCP/UDP, providing badge-based sessions.  Cosmos
     continues to use IP for network layer.

     *Phase 4 (Independent Operation):* TNSP provides an alternative to IP
     at the network layer.  In Phase 4 deployments, Badge IDs provide an
     alternative to IP addresses (see [RFC-XXXX-Badge] for Badge ID
     structure and routing properties), and intent-based routing (defined
     in TNSP and service discovery protocols) provides an alternative to
     IP routing.  Slipstream (Trust-Native Transport Protocol, TNTP)
     operates directly over Layer 2 (Ethernet frames) or via TNSP
     capsules.  This enables deployment without external consensus or
     blockchain infrastructure, including environments where IP
     infrastructure is not available or desired.  Phase 4 deployments
     still require Manifest for badge validation and trust establishment
     (see [RFC-XXXX-Manifest]).







  Hernandez                  Expires 5 July 2026                 [Page 17]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


  7.  Badge System

     Cosmos implementations MUST use the Badge System as specified in
     [RFC-XXXX-Badge] for all identity, capability, and trust management
     operations.  Badges are cryptographically signed Ramp (Slope Data
     Format, SDF) [RFC-XXXX-Ramp] documents that serve as identity,
     capability, and trust containers without requiring blockchain or
     external infrastructure.

     *Implementation Note*: The complete Badge System specification,
     including detailed badge structure, badge types, lifecycle
     management, DID compatibility, group badges, and security
     considerations, is defined in [RFC-XXXX-Badge].  This document
     specifies only the requirement to use badges and the integration
     points with the Cosmos Protocol.

  8.  Manifest

     Each star participates in the Cosmos Protocol through its Manifest
     service, which acts as the star's authority for badge issuance,
     validation, and policy distribution.  Deployment models, availability
     strategies, and operational requirements for Manifest are defined in
     [RFC-XXXX-Manifest].

     *Note*: Detailed specifications for cross-domain registry hosting,
     including hosting relationships, federated service model, termination
     requirements, and high availability requirements, are defined in
     [RFC-XXXX-Manifest].  This document provides only a high-level
     overview of Manifest's role in the Cosmos Protocol.

  9.  Policy Substrate (Governance Substrate)

     The Policy Substrate is a network-wide governance layer that defines
     and enforces policies across all Cosmos components.  Unlike
     traditional policy systems that are component-specific, the Policy
     Substrate provides a unified governance model for Cosmos deployments
     where implemented (see [RFC-XXXX-Manifest] for Policy Substrate
     requirements and deployment models), covering access control,
     compliance, security, data management, and system configuration.

     *Implementation Note*: Detailed Policy Substrate specifications,
     including policy categories, network-wide enforcement mechanisms,
     compliance policies, security policies, data management policies, and
     Access Control Grammar, are defined in [RFC-XXXX-Manifest] (see
     Section 9).  This document provides only a high-level overview of the
     Policy Substrate's role in the Cosmos Protocol.





  Hernandez                  Expires 5 July 2026                 [Page 18]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


  10.  Security Considerations

     The Cosmos Protocol's security properties derive from cryptographic
     badge signatures, post-quantum encryption (Lumen; see
     [RFC-XXXX-Lumen]), domain-bound trust scoring, and the ability to
     operate without blockchain or external consensus dependencies.
     Cosmos provides confidentiality through post-quantum candidate
     primitives (see [RFC-XXXX-Lumen] for algorithm details and security
     considerations), integrity through cryptographic signatures,
     authentication through badge-based verification, authorization
     through badge capabilities and trust scores, and non-repudiation
     through cryptographically signed operations that include timestamp
     fields defined in the Badge specification (see [RFC-XXXX-Badge] for
     signature structure and validation requirements), subject to the
     security properties of the underlying algorithms.

     Key security considerations include: identity spoofing prevention
     through cryptographic verification, trust manipulation resistance
     through algorithms designed to reduce manipulation risks,
     communication interception protection through post-quantum candidate
     primitives (see [RFC-XXXX-Lumen]), and cross-domain security through
     domain-bound policies and cryptographic isolation.

     *Implementation Note*: Detailed security considerations, including
     threat models, attack resistance analysis, privacy protection
     mechanisms, single-point-of-failure analysis, and implementation
     security requirements, are defined in component RFCs.  See
     [RFC-XXXX-Badge] for badge security, [RFC-XXXX-Manifest] for Manifest
     security requirements and SPOF mitigation, [RFC-XXXX-Lumen] for
     encryption security, and [RFC-XXXX-Slipstream] for transport
     security.  This document provides only a high-level overview of the
     Cosmos Protocol's security properties.

  11.  IANA Considerations

     This document defines the Cosmos Protocol specification and uses
     existing DNS record types (TXT, SRV, CNAME).  The protocol defines
     transport-agnostic requirements and internal data structures and
     algorithms that do not require IANA registration.  This document
     defines no new IANA registries.  Transport protocols such as
     Slipstream define their own IANA considerations in separate
     documents.

     Badge types, trust levels, capabilities, and other protocol-internal
     elements are defined within this specification and do not require
     separate IANA registries.  Service discovery uses existing SRV record
     types.  Domain authority declaration uses existing TXT record types.




  Hernandez                  Expires 5 July 2026                 [Page 19]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     A separate specification document defines the COSMOS DNS record type,
     which will require IANA registration.  That specification contains
     the necessary IANA considerations for the new DNS record type.

     This document has no IANA actions.

  12.  Acknowledgments

     The authors would like to thank the contributors to the Cosmos
     Protocol specification and the broader decentralized identity
     community for their insights and feedback.

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

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

  13.2.  Informative References

     [RFC-XXXX-Badge]
                Hernandez, A., "The Cosmos Badge System", Work in
                Progress, Internet-Draft, draft-cosmos-badge-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-badge-
                00>.

     [RFC-XXXX-BEAP]
                Hernandez, A., "Badge-Enabled API Protocol (BEAP):
                Identity-Addressed, Intent-Aware API Standard", Work in
                Progress, Internet-Draft, draft-cosmos-beap-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-beap-
                00>.

     [RFC-XXXX-Capsules]
                Hernandez, A., "The Cosmos Capsule Protocol", Work in
                Progress, Internet-Draft, draft-cosmos-capsules-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-
                capsules-00>.






  Hernandez                  Expires 5 July 2026                 [Page 20]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     [RFC-XXXX-Comet]
                Hernandez, A., "The Cosmos Comet Scheduling Protocol",
                Work in Progress, Internet-Draft, draft-cosmos-comet-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-comet-
                00>.

     [RFC-XXXX-Corona]
                Hernandez, A., "The Cosmos Corona Protocol", Work in
                Progress, Internet-Draft, draft-cosmos-corona-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-
                corona-00>.

     [RFC-XXXX-Echo]
                Hernandez, A., "The Cosmos Echo Grammar Protocol", Work in
                Progress, Internet-Draft, draft-cosmos-echo-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-echo-
                00>.

     [RFC-XXXX-Lumen]
                Hernandez, A., "The Cosmos Lumen Encryption Protocol",
                Work in Progress, Internet-Draft, draft-cosmos-lumen-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-lumen-
                00>.

     [RFC-XXXX-Manifest]
                Hernandez, A., "The Cosmos Manifest (Badge Registry)
                Protocol", Work in Progress, Internet-Draft, draft-cosmos-
                manifest-00, <https://datatracker.ietf.org/doc/html/draft-
                cosmos-manifest-00>.

     [RFC-XXXX-Nebula]
                Hernandez, A., "The Cosmos Nebula Contact Protocol", Work
                in Progress, Internet-Draft, draft-cosmos-nebula-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-
                nebula-00>.

     [RFC-XXXX-Nova]
                Hernandez, A., "The Cosmos Nova Calendar Protocol", Work
                in Progress, Internet-Draft, draft-cosmos-nova-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-nova-
                00>.

     [RFC-XXXX-Profile]
                Hernandez, A., "The Cosmos Profile Protocol and
                Interlink", Work in Progress, Internet-Draft, draft-
                cosmos-profile-00, <https://datatracker.ietf.org/doc/html/
                draft-cosmos-profile-00>.




  Hernandez                  Expires 5 July 2026                 [Page 21]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     [RFC-XXXX-Protocol-Versioning]
                Hernandez, A., "Cosmos Protocol Versioning and Evolution",
                Work in Progress, Internet-Draft, draft-cosmos-protocol-
                versioning-00, <https://datatracker.ietf.org/doc/html/
                draft-cosmos-protocol-versioning-00>.

     [RFC-XXXX-Ramp]
                Hernandez, A., "Ramp: Slope Data Format (SDF)", Work in
                Progress, Internet-Draft, draft-ramp-00,
                <https://datatracker.ietf.org/doc/html/draft-ramp-00>.

     [RFC-XXXX-SDFF]
                Hernandez, A., "SDFF: Self-Describing Field Format", Work
                in Progress, Internet-Draft, draft-cosmos-sdff-00,
                <https://datatracker.ietf.org/doc/html/draft-cosmos-sdff-
                00>.

     [RFC-XXXX-Slipstream]
                Hernandez, A., "The Cosmos Slipstream Transport Protocol
                (TNTP)", Work in Progress, Internet-Draft, draft-cosmos-
                slipstream-00, <https://datatracker.ietf.org/doc/html/
                draft-cosmos-slipstream-00>.

     [RFC-XXXX-Trust-Scoring]
                Hernandez, A., "The Cosmos Trust Scoring Protocol", Work
                in Progress, Internet-Draft, draft-cosmos-trust-scoring-
                00, <https://datatracker.ietf.org/doc/html/draft-cosmos-
                trust-scoring-00>.

     [RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
                (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511,
                June 2006, <https://www.rfc-editor.org/info/rfc4511>.

     [RFC4791]  Daboo, C. and L. Desruisseaux, "Calendaring Extensions to
                WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March
                2007, <https://www.rfc-editor.org/info/rfc4791>.

     [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
                Core Object Specification (iCalendar)", RFC 5545,
                DOI 10.17487/RFC5545, September 2009,
                <https://www.rfc-editor.org/info/rfc5545>.

     [RFC5546]  Daboo, C., "iCalendar Transport-Independent
                Interoperability Protocol (iTIP)", RFC 5546,
                DOI 10.17487/RFC5546, December 2009,
                <https://www.rfc-editor.org/info/rfc5546>.





  Hernandez                  Expires 5 July 2026                 [Page 22]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     [RFC6047]  Daboo, C., "iCalendar Message-Based Interoperability
                Protocol (iMIP)", RFC 6047, DOI 10.17487/RFC6047, December
                2010, <https://www.rfc-editor.org/info/rfc6047>.

     [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
                DOI 10.17487/RFC6350, August 2011,
                <https://www.rfc-editor.org/info/rfc6350>.

     [RFC6352]  Daboo, C., "CardDAV: vCard Extensions to WebDAV",
                RFC 6352, DOI 10.17487/RFC6352, August 2011,
                <https://www.rfc-editor.org/info/rfc6352>.

     [W3C-DID]  Sporny, M., Longley, D., and M. Sabadello, "Decentralized
                Identifiers (DIDs) v1.0", July 2022,
                <https://www.w3.org/TR/did-core/>.

  Author's Address

     Antoine Hernandez
     Varlil Corporation
     Email: ahernan1@varlil.com






























  Hernandez                  Expires 5 July 2026                 [Page 23]


name: draft-kale-agntcy-federated-privacy
rev: 00
title: Privacy-Preserving Federated Learning Architecture for Multi-Tenant AI Agent Systems
time: 2026-01-08T03:28:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-12T03:28:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.831012+00:00
source: ietf
abstract:
  This document specifies a reference architecture for privacy-
     preserving federated learning in multi-tenant AI agent deployments.
     It addresses the challenge of enabling collaborative model training
     across organizational boundaries while maintaining formal privacy
     guarantees and tenant data isolation.  The architecture combines
     federated averaging, differential privacy mechanisms, and secure
     aggregation to enable cross-tenant knowledge transfer without
     exposing sensitive behavioral data.

full_text:
  Network Working Group                                           N. Kale
  Internet-Draft                                             Cisco Systems
  Intended status: Informational                             January 2026
  Expires: July 2026


        Privacy-Preserving Federated Learning Architecture for
                Multi-Tenant AI Agent Systems

                   draft-kale-agntcy-federated-privacy-00

  Abstract

     This document specifies a reference architecture for privacy-
     preserving federated learning in multi-tenant AI agent deployments.
     It addresses the challenge of enabling collaborative model training
     across organizational boundaries while maintaining formal privacy
     guarantees and tenant data isolation.  The architecture combines
     federated averaging, differential privacy mechanisms, and secure
     aggregation to enable cross-tenant knowledge transfer without
     exposing sensitive behavioral data.

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

  Kale                          Informational                     [Page 1]

  Internet-Draft        Federated Learning for Agents         January 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Relationship to AI Agent Protocol Work  . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
       4.1.  System Components . . . . . . . . . . . . . . . . . . . .   4
       4.2.  Data Flow . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Federated Learning Protocol . . . . . . . . . . . . . . . . .   6
       5.1.  Initialization  . . . . . . . . . . . . . . . . . . . . .   7
       5.2.  Local Training Phase  . . . . . . . . . . . . . . . . . .   7
       5.3.  Aggregation Phase . . . . . . . . . . . . . . . . . . . .   7
       5.4.  Weighting Strategies  . . . . . . . . . . . . . . . . . .   8
     6.  Privacy Mechanisms  . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Differential Privacy Definition . . . . . . . . . . . . .   8
       6.2.  Gaussian Mechanism  . . . . . . . . . . . . . . . . . . .   8
       6.3.  Privacy Budget Allocation . . . . . . . . . . . . . . . .   9
       6.4.  Gradient Clipping . . . . . . . . . . . . . . . . . . . .   9
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
       7.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   9
       7.2.  Attacks Not Addressed . . . . . . . . . . . . . . . . . .  10
       7.3.  Extensions for Stronger Security  . . . . . . . . . . . .  10
       7.4.  Compliance Considerations . . . . . . . . . . . . . . . .  10
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     Appendix A.  Example Configuration  . . . . . . . . . . . . . . .  12
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     AI agent systems increasingly operate in multi-tenant enterprise
     environments where behavioral data from user interactions could
     improve system performance through machine learning.  However,
     centralizing such data across organizational boundaries conflicts
     with privacy regulations (GDPR, HIPAA, CCPA), contractual data
     isolation requirements, and enterprise security policies.

     This document specifies a federated learning architecture that
     enables collaborative model training while ensuring:

     o  Tenant data isolation: Raw behavioral data never leaves tenant
        boundaries

     o  Formal privacy guarantees: Differential privacy bounds
        information leakage

  Kale                          Informational                     [Page 2]

  Internet-Draft        Federated Learning for Agents         January 2026


     o  Regulatory compliance: Architecture supports GDPR, HIPAA, and
        CCPA requirements

     o  Scalable deployment: Protocol supports large numbers of tenants
        with heterogeneous data distributions

     The architecture applies broadly to any multi-tenant machine
     learning deployment requiring privacy preservation, with particular
     relevance to AI agent systems operating across organizational
     boundaries.  This work builds on foundational research in federated
     learning [McMahan17] and differential privacy [Dwork14] [Abadi16],
     as well as recent advances addressing open problems in the field
     [Kairouz21] [Wang23].

  1.1.  Relationship to AI Agent Protocol Work

     This document complements ongoing work on AI agent protocols at the
     IETF, including frameworks for agent communication [Rosenberg25]
     and secure messaging for agentic AI [SLIM25].  The privacy-
     preserving aggregation mechanisms specified here address federated
     learning requirements that arise when AI agents operate across
     organizational boundaries and must learn from distributed behavioral
     data without centralizing sensitive information.

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

     Aggregation Server:  A central coordinator that receives model
        updates from tenants and computes aggregated models.

     Differential Privacy (DP):  A mathematical framework providing
        formal bounds on information leakage from statistical queries.

     Federated Learning (FL):  A machine learning approach where model
        training occurs on decentralized data without centralizing the
        data itself.

     Local Model:  A model trained on a single tenant's data.

     Global Model:  An aggregated model computed from multiple local
        model updates.

     Privacy Budget:  Parameters (epsilon, delta) that quantify the
        privacy guarantee provided by differential privacy mechanisms.

  Kale                          Informational                     [Page 3]

  Internet-Draft        Federated Learning for Agents         January 2026


     Tenant:  An organizational entity with isolated data and computing
        resources within a multi-tenant deployment.

  3.  Problem Statement

     Consider an AI agent system deployed across N organizational
     tenants.  Each tenant generates behavioral data from user
     interactions with the agent.  The system operator wishes to:

     1.  Train personalization models that adapt to user behavior

     2.  Leverage patterns across tenants to improve model quality

     3.  Maintain strict tenant data isolation

     4.  Comply with privacy regulations

     Traditional centralized machine learning requires aggregating data
     from all tenants, violating requirements 3 and 4.  Purely local
     training (each tenant trains independently) satisfies isolation but
     sacrifices the benefits of cross-tenant learning (requirement 2).

     This document specifies an architecture that satisfies all four
     requirements through federated learning with differential privacy.

  4.  Architecture Overview

  4.1.  System Components

     The architecture comprises the following components, illustrated in
     Figure 1:

     o  Local Data stores residing within each tenant boundary

     o  Local Model training infrastructure at each tenant

     o  Differential Privacy (DP) noise injection modules

     o  A central Aggregation Server for computing global model updates













  Kale                          Informational                     [Page 4]

  Internet-Draft        Federated Learning for Agents         January 2026


     +------------------+   +------------------+   +------------------+
     |    Tenant A      |   |    Tenant B      |   |    Tenant C      |
     |  +------------+  |   |  +------------+  |   |  +------------+  |
     |  | Local Data |  |   |  | Local Data |  |   |  | Local Data |  |
     |  +-----+------+  |   |  +-----+------+  |   |  +-----+------+  |
     |        |         |   |        |         |   |        |         |
     |  +-----v------+  |   |  +-----v------+  |   |  +-----v------+  |
     |  |Local Model |  |   |  |Local Model |  |   |  |Local Model |  |
     |  +-----+------+  |   |  +-----+------+  |   |  +-----+------+  |
     |        |         |   |        |         |   |        |         |
     |  +-----v------+  |   |  +-----v------+  |   |  +-----v------+  |
     |  |  DP Noise  |  |   |  |  DP Noise  |  |   |  |  DP Noise  |  |
     |  +-----+------+  |   |  +-----+------+  |   |  +-----+------+  |
     +--------+---------+   +--------+---------+   +--------+---------+
              |                      |                      |
              +----------------------+----------------------+
                                     |
                          +----------v-----------+
                          |  Aggregation Server  |
                          |  (Computes Global    |
                          |   Model Updates)     |
                          +----------+-----------+
                                     |
              +----------------------+----------------------+
              |                      |                      |
     +--------v---------+   +--------v---------+   +--------v---------+
     |    Tenant A      |   |    Tenant B      |   |    Tenant C      |
     |  Receives Global |   |  Receives Global |   |  Receives Global |
     |  Model Update    |   |  Model Update    |   |  Model Update    |
     +------------------+   +------------------+   +------------------+

                      Figure 1: Federated Architecture


















  Kale                          Informational                     [Page 5]

  Internet-Draft        Federated Learning for Agents         January 2026


  4.2.  Data Flow

     1.  Each tenant trains a local model on tenant-specific data

     2.  Model updates (not raw data) are computed

     3.  Differential privacy noise is added to updates

     4.  Noisy updates are transmitted to aggregation server

     5.  Server computes weighted average of updates

     6.  Global model is distributed back to tenants

     7.  Process repeats for specified number of rounds

  4.3.  Trust Model

     The architecture assumes:

     o  Aggregation server is honest-but-curious: It follows the
        protocol correctly but may attempt to infer information from
        received updates

     o  Tenants are honest: They train models correctly and do not
        attempt to poison the global model

     o  Communication channels are secure: TLS protects updates in
        transit

     Section 7 discusses extensions for stronger threat models.

  5.  Federated Learning Protocol

     This section specifies the federated learning protocol in detail.
     The protocol follows the FedAvg algorithm structure with
     modifications for differential privacy.















  Kale                          Informational                     [Page 6]

  Internet-Draft        Federated Learning for Agents         January 2026


  5.1.  Initialization

     The aggregation server MUST:

     1.  Generate initial global model parameters theta_0

     2.  Distribute theta_0 to all participating tenants

     3.  Specify privacy budget (epsilon, delta) for the training session

     4.  Specify number of training rounds T

  5.2.  Local Training Phase

     For each round t, each tenant i MUST:

     1.  Receive current global model theta_t from aggregation server

     2.  Train local model on tenant data for E local epochs:
         theta_i = LocalTrain(theta_t, D_i, E)

     3.  Compute model update: delta_i = theta_i - theta_t

     4.  Clip update to bound sensitivity:
         delta_i_clipped = Clip(delta_i, C) where C is the clipping bound

     5.  Add Gaussian noise for differential privacy:
         delta_i_dp = delta_i_clipped + N(0, sigma^2 * I)

     6.  Transmit delta_i_dp to aggregation server

  5.3.  Aggregation Phase

     The aggregation server MUST:

     1.  Receive noisy updates {delta_1_dp, ..., delta_n_dp} from tenants

     2.  Compute weighted average:
         delta_global = sum(w_i * delta_i_dp) where sum(w_i) = 1

     3.  Update global model: theta_{t+1} = theta_t + delta_global

     4.  Distribute theta_{t+1} to all tenants








  Kale                          Informational                     [Page 7]

  Internet-Draft        Federated Learning for Agents         January 2026


  5.4.  Weighting Strategies

     Tenant weights w_i MAY be computed based on:

     o  Population size: Larger tenants contribute proportionally more

     o  Data quality: Tenants with lower-variance updates receive higher
        weight

     o  Equal weighting: w_i = 1/n for all tenants

     The specific weighting strategy SHOULD be documented in the
     deployment configuration.

  6.  Privacy Mechanisms

  6.1.  Differential Privacy Definition

     A mechanism M satisfies (epsilon, delta)-differential privacy if
     for all datasets D and D' differing in one record, and all output
     sets S:

        Pr[M(D) in S] <= e^epsilon * Pr[M(D') in S] + delta

  6.2.  Gaussian Mechanism

     The Gaussian mechanism achieves (epsilon, delta)-DP by adding noise:

        sigma >= C * sqrt(2 * ln(1.25/delta)) / epsilon

     where C is the L2 sensitivity bound (clipping threshold).


















  Kale                          Informational                     [Page 8]

  Internet-Draft        Federated Learning for Agents         January 2026


  6.3.  Privacy Budget Allocation

     For T training rounds with subsampling rate q, the total privacy
     budget follows composition theorems.  Implementations SHOULD use
     advanced composition or Renyi differential privacy accounting for
     tighter bounds.

     Recommended privacy parameters for enterprise deployments:

        epsilon: 1.0 to 10.0 (depending on data sensitivity)
        delta: 1/n where n is the minimum tenant population size
        C (clipping bound): Determined empirically based on gradient
        norms

  6.4.  Gradient Clipping

     Before noise addition, model updates MUST be clipped:

        delta_clipped = delta * min(1, C / ||delta||_2)

     This bounds the sensitivity of individual data points, enabling
     precise privacy accounting.

  7.  Security Considerations

  7.1.  Threat Model

     This architecture protects against:

     o  Honest-but-curious aggregation server attempting to infer tenant
        data from model updates

     o  External attackers observing aggregated models

     o  Membership inference attacks against the global model
















  Kale                          Informational                     [Page 9]

  Internet-Draft        Federated Learning for Agents         January 2026


  7.2.  Attacks Not Addressed

     The basic architecture does NOT protect against:

     o  Malicious tenants submitting poisoned updates

     o  Collusion between aggregation server and tenants

     o  Model inversion attacks against the final trained model

  7.3.  Extensions for Stronger Security

  7.3.1.  Secure Aggregation

     To protect against curious aggregation servers, implementations MAY
     use secure aggregation protocols where the server learns only the
     sum of updates, not individual tenant contributions.  See
     [Bonawitz17] for protocol details.

  7.3.2.  Byzantine Fault Tolerance

     To protect against malicious tenants, implementations MAY use
     Byzantine-resilient aggregation methods such as coordinate-wise
     median or trimmed mean.

  7.4.  Compliance Considerations

     Implementations targeting GDPR compliance SHOULD:

     o  Document privacy budget selection rationale

     o  Maintain audit logs of aggregation operations

     o  Implement data subject access request procedures

     o  Specify data retention policies for model checkpoints
















  Kale                          Informational                    [Page 10]

  Internet-Draft        Federated Learning for Agents         January 2026


  8.  IANA Considerations

     This document has no IANA actions.

  9.  References

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

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

  9.2.  Informative References

     [Abadi16]  Abadi, M., Chu, A., Goodfellow, I., McMahan, H.B.,
                Mironov, I., Talwar, K., and L. Zhang, "Deep Learning
                with Differential Privacy", Proceedings of the 2016 ACM
                SIGSAC Conference on Computer and Communications
                Security, 2016.

     [Bonawitz17]
                Bonawitz, K., Ivanov, V., Kreuter, B., Marcedone, A.,
                McMahan, H.B., Patel, S., Ramage, D., Segal, A., and K.
                Seth, "Practical Secure Aggregation for Privacy-
                Preserving Machine Learning", Proceedings of the 2017
                ACM SIGSAC Conference on Computer and Communications
                Security, 2017.

     [Dwork14]  Dwork, C. and A. Roth, "The Algorithmic Foundations of
                Differential Privacy", Foundations and Trends in
                Theoretical Computer Science, Vol. 9, No. 3-4, 2014.

     [Kairouz21]
                Kairouz, P., McMahan, H.B., Avent, B., et al., "Advances
                and Open Problems in Federated Learning", Foundations
                and Trends in Machine Learning, Vol. 14, No. 1-2, 2021.

     [McMahan17]
                McMahan, H.B., Moore, E., Ramage, D., Hampson, S., and
                B. Aguera y Arcas, "Communication-Efficient Learning of
                Deep Networks from Decentralized Data", Proceedings of
                AISTATS, 2017.

  Kale                          Informational                    [Page 11]

  Internet-Draft        Federated Learning for Agents         January 2026


     [Rosenberg25]
                Rosenberg, J. and C. Jennings, "Framework, Use Cases and
                Requirements for AI Agent Protocols", Work in Progress,
                Internet-Draft, draft-rosenberg-aiproto-framework-00,
                October 2025.

     [SLIM25]   Muscariello, L., Papalini, M., Sardara, S., and S.
                Betts, "Secure Low-Latency Interactive Messaging
                (SLIM)", Work in Progress, Internet-Draft,
                draft-mpsb-agntcy-slim-00, October 2025.

     [Wang23]   Wang, J., Charles, Z., Xu, Z., Joshi, G., McMahan, H.B.,
                et al., "A Field Guide to Federated Optimization",
                arXiv:2107.06917, 2023.

  Appendix A.  Example Configuration

     Example deployment configuration for enterprise AI agent system:

     {
       "federated_learning": {
         "rounds": 100,
         "local_epochs": 5,
         "learning_rate": 0.01,
         "privacy": {
           "epsilon": 3.0,
           "delta": 1e-6,
           "clipping_bound": 1.0,
           "noise_multiplier": 1.1
         },
         "aggregation": {
           "method": "fedavg",
           "weighting": "population_proportional",
           "min_tenants_per_round": 10
         }
       }
     }














  Kale                          Informational                    [Page 12]

  Internet-Draft        Federated Learning for Agents         January 2026


  Author's Address

     Nik Kale
     Cisco Systems, Inc.
     3700 Cisco Way
     San Jose, CA 95134
     United States of America

     Email: nikkal@cisco.com










































  Kale                          Informational                    [Page 13]


name: draft-li-dmsc-inf-architecture
rev: 05
title: Dynamic Multi-agent Secured Collaboration Infrastructure Architecture
time: 2026-02-05T02:44:32Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-09T02:44:32Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.835434+00:00
source: ietf
abstract:
  This document presents an architectural framework for dynamic multi-
     agent collaboration from an infrastructure perspective.  It outlines
     the network requirements introduced by large-scale agents
     collaboration, and proposes a systematic approach to enabling Dynamic
     Multi-agent Secured Collaboration (DMSC) through infrastructure
     capabilities.  The architecture focuses on how network control and
     forwarding functions can actively participate in agent collaboration.

full_text:
  DMSC Working Group                                                 X. Li
  Internet-Draft                                                   A. Wang
  Intended status: Standards Track                           China Telecom
  Expires: 9 August 2026                                   5 February 2026


   Dynamic Multi-agent Secured Collaboration Infrastructure Architecture
                     draft-li-dmsc-inf-architecture-05

  Abstract

     This document presents an architectural framework for dynamic multi-
     agent collaboration from an infrastructure perspective.  It outlines
     the network requirements introduced by large-scale agents
     collaboration, and proposes a systematic approach to enabling Dynamic
     Multi-agent Secured Collaboration (DMSC) through infrastructure
     capabilities.  The architecture focuses on how network control and
     forwarding functions can actively participate in agent collaboration.

  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 9 August 2026.

  Copyright Notice

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











  Li & Wang                 Expires 9 August 2026                 [Page 1]


  Internet-Draft              DMSC Architecture              February 2026


     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 . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Network Requirements  . . . . . . . . . . . . . . . . . . . .   4
     5.  DMSC Architecture Overview  . . . . . . . . . . . . . . . . .   4
       5.1.  DMSC Infrastructure Architecture  . . . . . . . . . . . .   5
     6.  Infrastructure Functions Enabling Active Network
             Participation . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Agent Identification and Capability Directory . . . . . .   8
       6.2.  Infrastructure-Level Agent Discovery  . . . . . . . . . .   8
       6.3.  Semantic Routing  . . . . . . . . . . . . . . . . . . . .   8
       6.4.  Secure Collaboration Capability and Policy  . . . . . . .   9
       6.5.  Operational Visibility  . . . . . . . . . . . . . . . . .   9
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     Intelligent agents have evolved rapidly in recent years, driven by
     advances in artificial intelligence models, computing platforms, and
     network connectivity.  Early forms of agents were typically embedded
     within isolated systems and designed to perform narrowly defined
     tasks under predefined conditions.  Their interactions with external
     entities were limited and often mediated by tightly coupled
     application logic [IoA].












  Li & Wang                 Expires 9 August 2026                 [Page 2]


  Internet-Draft              DMSC Architecture              February 2026


     With the increasing availability of large-scale AI models, edge
     computing resources, and programmable network infrastructures, agents
     are becoming more autonomous, adaptive, and capable of operating
     across distributed environments.  Modern agents can perceive changes
     in their environment, make decisions based on local or shared
     information, and interact with other agents and tools in order to
     achieve complex objectives.  These interactions are no longer
     confined to static configurations or single administrative domains,
     but increasingly span devices, networks, and application platforms.

     As agents continue to proliferate, they are forming large-scale
     collaborative systems in which multiple agents dynamically discover
     each other, exchange information, and coordinate actions.  Such
     systems exhibit highly dynamic behavior, including frequent changes
     in agent population, roles, and interaction patterns.  The resulting
     agent ecosystems resemble an open, interconnected environment rather
     than a collection of isolated applications.

     The evolution toward large-scale, dynamic agent ecosystems introduces
     new challenges for the underlying network infrastructure.  While
     agents are capable of sophisticated reasoning and decision-making,
     their ability to collaborate effectively depends on the availability
     of common, scalable, and interoperable networking support.

     This document focuses on the architectural aspects of enabling
     dynamic multi-agent collaboration from a network and infrastructure
     perspective.  It examines how network control and forwarding
     functions can be extended to recognize agents as first-class entities
     and provide generic support for agent identification, discovery,
     semantic routing, and coordination.  The architecture is intended to
     support a wide range of agent types, including on-device agents,
     network-resident agents, and third-party agents, without imposing
     assumptions about their internal implementation.

     The scope of this document is limited to architectural concepts and
     functional building blocks.  It does not define specific protocols,
     data models, or security mechanisms, nor does it prescribe particular
     deployment scenarios or application workflows.  Instead, it provides
     a foundational framework upon which more detailed specifications,
     including protocol designs and security architectures, can be
     developed in subsequent documents.

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




  Li & Wang                 Expires 9 August 2026                 [Page 3]


  Internet-Draft              DMSC Architecture              February 2026


  3.  Terminology

     The following terms are defined in this draft:

     *  DMSC: Dynamic Multi-agent Secured Collaboration.  The framework
        and infrastructure enabling secure and efficient collaboration
        among dynamic agents.

     *  Agent: An autonomous software entity capable of perception,
        planning, decision-making, and execution.

     *  SemR: Semantic Routing.  The process of routing an Agent request
        based on the meaning or intent of the request, rather than solely
        on IP address.

  4.  Network Requirements

     The proliferation of intelligent agents fundamentally reshapes
     interaction patterns and control dynamics in future networks.  Agent
     interactions are typically short-lived, context-dependent, and driven
     by task semantics rather than static endpoints.  Moreover, agents may
     dynamically join or leave collaborative groups, migrate across
     administrative domains, or change roles over time.  These
     characteristics introduce new requirements for network
     infrastructures, including agent-level identity management,
     capability-aware communication, scalable registration and discovery,
     cross-domain collaboration support, and adaptive routing, as also
     reflected in [draft-yu-ai-agent-use-cases-in-6g].[usecase]

     Collectively, these requirements indicate that future networks must
     go beyond passive connectivity and actively support dynamic multi-
     agent collaboration.  The core idea of Dynamic Multi-agent Secured
     Collaboration (DMSC) is to elevate key collaboration-related
     functions into the network infrastructure.  Instead of embedding all
     coordination logic within applications or agent frameworks, DMSC
     leverages infrastructure-level capabilities exposed through control-
     plane and forwarding-plane functions.  This approach enables the
     network to recognize agents as first-class entities, maintain high-
     level collaboration context, and make informed decisions on
     discovery, routing, and coordination support in a scalable and
     interoperable manner.

  5.  DMSC Architecture Overview








  Li & Wang                 Expires 9 August 2026                 [Page 4]


  Internet-Draft              DMSC Architecture              February 2026


  5.1.  DMSC Infrastructure Architecture

     Figure 1 illustrates the overall architecture for dynamic multi-agent
     collaboration from an infrastructure-centric perspective.  The
     architecture positions the network infrastructure as an active
     participant in agent collaboration, while preserving the autonomy and
     task-level reasoning of individual agents.  In this architecture, the
     network does not execute agent logic or interpret task semantics.
     Instead, it provides generic support functions that enable agents to
     collaborate more efficiently and reliably.  Agents remain autonomous,
     while the network supplies shared infrastructure capabilities.

     From an infrastructure perspective, the architecture is organized
     into three logical layers:

     *  Management Plane: governs authentication, capability taxonomy,
        observability and policy aspects.

     *  Control Plane: Manages agent registration, discovery, invocation,
        lifecycle, and capability information maintenance and so on.

     *  Forwarding Plane: Supports semantic routing for agent
        interactions.




























  Li & Wang                 Expires 9 August 2026                 [Page 5]


  Internet-Draft              DMSC Architecture              February 2026


     +------------------------------------------------------------------------------------+
     |                         Management & Orchestration Plane                           |
     |  +--------------+   +-------------------+   +-----------------+  +--------------+  |
     |  |  Agent       |   |Capability Taxonomy|   | Observability & |  |Policy Manager|  |
     |  |Authentication|   |(Agent,Capability) |   | Analytics       |  | (Rules...)   |  |
     |  +--------------+   +-------------------+   +-----------------+  +--------------+  |
     +------------------------------------------------------------------------------------+
                                         |        ^
                                         v        |
  +-------------------------------------------------------------------------------------------+
  |                                  Network Infrastructure                                   |
  | +---------------------------------------------------------------------------------------+ |
  | |         Node 1                              Node 2                     Node 3 ...     | |
  | | +-------------------------+    +-------------------------+     +--------------------+ | |
  | | |      Control Plane      |    |      Control Plane      |     | Control Plane      | | |
  | | |-------------------------|    |-------------------------|     |--------------------| | |
  | | | - Agent Registration    |<-->| - Agent Registration    |<--> | ...                | | |
  | | | - Agent Invocation      |    | - Agent Invocation      |     |                    | | |
  | | | - Agent Discovery       |    | - Agent Discovery       |     |                    | | |
  | | | - Capability Directory  |    | - Capability Directory  |     |                    | | |
  | | +-------------------------+    +-------------------------+     +--------------------+ | |
  | |            | Control & Policy               | Control                   | Control     | |
  | |            v                                v & Policy                  v & Policy    | |
  | | +------------------------+     +-------------------------+      +-------------------+ | |
  | | | Forwarding Plane       |     |      Forwarding Plane   |      | Forwarding Plane  | | |
  | | |------------------------+     +-------------------------+      +-------------------+ | |
  | | | - Semantic  Routing    |     |    ...                  |      |  ...              | | |
  | | | - ...                  |     |                         |      |                   | | |
  | | +------------------------+     +-------------------------+      +-------------------+ | |
  | +---------------------------------------------------------------------------------------+ |
  +------------------^  ------------------------^ ------------------------------^ ------------+
                     |Registration              |  Registration                 |Registration
                     |                          |                               |
           +--------------------+     +--------------------+         +--------------------+
           |        Agent A     |     |        Agent B     |         |        Agent C     |
           |--------------------|     |--------------------|         |--------------------|
           | - Capabilities     |     | - Capabilities     |         | - Capabilities     |   ...
           | - Local Reasoning  |     | - Local Reasoning  |         | - Local Reasoning  |
           +--------------------+     +--------------------+         +--------------------+
     Figure 1 The infrastructure architecture of dynamic multi-agent collaboration

     On top of this architecture, agents engage in collaborative
     activities driven by task intents, shared goals, and capability
     information.  Agents are responsible for local reasoning, decision-
     making, and execution of task-specific logic.  The network does not
     interpret agent semantics or execute agent logic; instead, it
     provides common infrastructure capabilities that support efficient
     and scalable collaboration among agents.  Above the network



  Li & Wang                 Expires 9 August 2026                 [Page 6]


  Internet-Draft              DMSC Architecture              February 2026


     infrastructure, a Management and Orchestration Plane provides non-
     real-time management functions, including agent authentication, agent
     capability taxonomy management, policy management, observability and
     analytics.  This plane supplies policy, trust, and state-related
     inputs to the network infrastructure.

     The network infrastructure itself is composed of multiple network
     nodes, each implementing a common set of logical functions, and the
     nodes support hierarchical deployment.  Within each node, the Control
     Plane provides agent-aware control functions, including agent
     identity management, capability directory maintenance, registration,
     and discovery control.  These functions enable the network to
     recognize agents as first-class entities and maintain a consistent
     view of agent-related information across the infrastructure.  By
     decoupling agent identity from physical location through capability
     identifiers, the control plane supports dynamic agent lifecycle
     events such as mobility, instantiation, and termination.

     The Forwarding Plane supports semantic routing by forwarding requests
     based on capability identifiers—such as /capability/ocr—rather than
     static IP addresses.  When multiple instances of a capability are
     available, the forwarding plane may select a target based on real-
     time health and availability information—such as liveness or
     load—provided by the control plane.  In the event of failure, it can
     perform fast failover to an alternative instance within the same
     capability group, ensuring continuity of service.

     When an agent joins the network, it authenticates and obtains trusted
     authorization through network controller; only verified agents may
     register their capabilities—such as “supports high-precision OCR” or
     “performs GDPR-compliant de-identification”—which are stored locally
     to form a capability directory.  When another agent issues a
     capability-based discovery request (e.g., “find an OCR agent”), the
     local node either responds directly or securely synchronizes
     capability information with other nodes—including across domains or
     clouds—to locate eligible candidates.  Once a target is identified,
     the request is forwarded via semantic routing (e.g., using
     /capability/ocr) to the appropriate instance.

     Overall, this architecture establishes a clear division of
     responsibilities: agents focus on intelligent behavior and task
     execution, while the network infrastructure provides capability-based
     control, semantic forwarding, and secure coordination mechanisms.
     This separation enables dynamic multi-agent collaboration to scale
     across heterogeneous environments—on-premises, at the edge, or in the
     cloud—while allowing agents and the network to evolve independently.





  Li & Wang                 Expires 9 August 2026                 [Page 7]


  Internet-Draft              DMSC Architecture              February 2026


  6.  Infrastructure Functions Enabling Active Network Participation

  6.1.  Agent Identification and Capability Directory

     In large-scale dynamic multi-agent environments, agents cannot be
     effectively supported using traditional host- or service-based
     identifiers alone.  Agents may be instantiated dynamically, migrate
     across network locations, or operate concurrently on the same
     physical node.  As a result, the network requires a mechanism to
     identify agents as logical entities that are decoupled from network
     topology.

     The proposed architecture introduces network-visible agent
     identifiers that represent agents independently of their physical
     location or hosting environment.  These identifiers enable the
     network to consistently recognize agents across control and
     forwarding functions, even as underlying network bindings change.
     Beyond basic identification, the architecture supports forming an
     agent capability directory on nodes.

  6.2.  Infrastructure-Level Agent Discovery

     Agent discovery is a fundamental prerequisite for collaboration, yet
     traditional discovery mechanisms are typically designed for
     relatively static services or tightly scoped environments.  In
     contrast, multi-agent collaboration requires discovery mechanisms
     that can operate across heterogeneous platforms, adapt to dynamic
     agent populations, and respect administrative boundaries.

     In DMSC architecture, agent discovery is provided as an
     infrastructure-level function, rather than being entirely implemented
     within agent frameworks.  The network supports discovery queries
     based on agent identifiers, advertised capabilities.  This allows
     agents to locate suitable collaborators without requiring global
     knowledge or centralized coordination.

  6.3.  Semantic Routing

     Traditional routing mechanisms forward packets based on destination
     addresses without awareness of application intent.  In dynamic multi-
     agent collaboration, however, interactions are driven by *what* is
     needed—such as a specific capability—rather than *where* a fixed
     endpoint resides.  The DMSC architecture addresses this by
     introducing semantic routing: requests are expressed in terms of
     agent capabilities (e.g., "/capability/ocr").






  Li & Wang                 Expires 9 August 2026                 [Page 8]


  Internet-Draft              DMSC Architecture              February 2026


     Semantic routing enables flexible agent invocation without hard-coded
     endpoints.  A request for a given capability can be routed to any
     authorized and available instance that has declared that capability.
     If the selected instance becomes unavailable, the network may fail
     over to another instance within the same capability group, provided
     such redundancy exists.

  6.4.  Secure Collaboration Capability and Policy

     Effective collaboration among dynamic agents requires consistent
     handling of capabilities and policies, especially when interactions
     span multiple domains or network segments.  The DMSC architecture
     supports secure synchronization of capability declarations and policy
     constraints at the infrastructure level.

     Capability information associated with an agent—such as its declared
     functions (e.g., OCR, payment validation) and security attributes
     (e.g., GDPR compliance, authentication requirements)—can be
     registered with the control plane and synchronized across domains.
     Where appropriate, these capability descriptions may be bound to
     policy rules that govern access and interaction.  Security-related
     attributes, such as authorization scope or domain-specific
     constraints, can be attached to capability entries to ensure that
     interactions remain compliant with local regulations and trust
     boundaries.  In cross-domain scenarios, policy abstraction mechanisms
     support controlled translation or normalization to enable
     interoperability while respecting local governance.

  6.5.  Operational Visibility

     As multi-agent systems scale, gaining visibility into collaboration-
     level behavior becomes essential for effective operation and
     troubleshooting.  Traditional network observability focuses on flows
     and endpoints, offering limited insight into agent interactions and
     coordination dynamics.  The DMSC architecture introduces operational
     visibility at the collaboration level by enabling controlled
     observation of key interaction events.

     Observable entities may include:

     *  Agent registration and abstract capability advertisements.

     *  Capability-based discovery activities and outcomes.

     *  Semantic routing decisions and high-level invocation outcomes.

     *  Association with network resources and applied policy controls.




  Li & Wang                 Expires 9 August 2026                 [Page 9]


  Internet-Draft              DMSC Architecture              February 2026


     This visibility is not intended to expose agent internals or infer
     application logic, but to provide sufficient information for
     monitoring, auditing, root cause analysis, and performance
     optimization.  The collected telemetry can be used by management and
     orchestration systems to support long-term optimization—such as
     identifying underutilized capabilities or detecting policy
     violations.  It may also inform policy refinement and infrastructure
     planning, but does not drive real-time control-plane decisions or
     forwarding-plane behavior.  To address privacy and security concerns,
     exposure of observable data is controlled through policy mechanisms,
     ensuring that only authorized parties can access relevant
     information.

  7.  Security Considerations

     This architecture introduces several security considerations,
     including risks related to agent identity spoofing, capability
     misrepresentation, semantic routing manipulation, cross-domain trust
     inconsistencies, and information leakage through enhanced
     observability.  Detailed security mechanisms are outside the scope of
     this document.

  8.  IANA Considerations

     TBD

  9.  Acknowledgement

     TBD

  10.  Normative References

     [IoA]      L, J., "Internet of Agents – Definition, Architecture and
                Applications.
                https://aip.openatom.tech/explore/journalism/
                detail/501037383572131840", October 2025.

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

     [usecase]  Y, M., "AI Agent Use Cases and Requirements in 6G Network.
                draft-yu-ai-agent-use-cases-in-6g.
                <https://datatracker.ietf.org/doc/html/draft-yu-dmsc-ai-
                agent-use-cases-in-6g>", July 2025.





  Li & Wang                 Expires 9 August 2026                [Page 10]


  Internet-Draft              DMSC Architecture              February 2026


  Authors' Addresses

     Xueting Li
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: lixt2@foxmail.com


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

































  Li & Wang                 Expires 9 August 2026                [Page 11]


name: draft-liu-dmsc-gw-requirements
rev: 00
title: Gateway Requirements for Dynamic Multi-agents Secured Collaboration
time: 2026-01-16T12:31:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-20T12:31:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.840167+00:00
source: ietf
abstract:
  This document discusses the requirements for introducing Gateways
     into Dynamic Multi-agents Secured Collaboration for better
     scalability, communication efficiency, and security etc.  This
     document also discusses the gaps of current hardware/software
     gateways that could not fulfil the task, so that a new kind of
     entity, e.g. DMSC Gateway, is needed.

full_text:
  Network Working Group                                             B. Liu
  Internet-Draft                                       Huawei Technologies
  Intended status: Informational                           16 January 2026
  Expires: 20 July 2026


    Gateway Requirements for Dynamic Multi-agents Secured Collaboration
                     draft-liu-dmsc-gw-requirements-00

  Abstract

     This document discusses the requirements for introducing Gateways
     into Dynamic Multi-agents Secured Collaboration for better
     scalability, communication efficiency, and security etc.  This
     document also discusses the gaps of current hardware/software
     gateways that could not fulfil the task, so that a new kind of
     entity, e.g. DMSC Gateway, is needed.

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



  Liu                       Expires 20 July 2026                  [Page 1]


  Internet-Draft          DMSC Gateway Requirements           January 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Functional Requirements of DMSC Gateway . . . . . . . . . . .   3
       2.1.  Delegated Agent Discovery . . . . . . . . . . . . . . . .   3
         2.1.1.  ID-based Agent Location Resolution  . . . . . . . . .   3
         2.1.2.  Task-based Agent Searching  . . . . . . . . . . . . .   4
       2.2.  Agent Communication Access Control  . . . . . . . . . . .   5
       2.3.  Information Distribution among Agents . . . . . . . . . .   6
         2.3.1.  Point-to-Point Distribution . . . . . . . . . . . . .   6
         2.3.2.  Pub/Sub . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Gap Analysis of Current Gateways  . . . . . . . . . . . . . .   7
       3.1.  Hardware form Gateways  . . . . . . . . . . . . . . . . .   7
       3.2.  Software form Gateways  . . . . . . . . . . . . . . . . .   7
     4.  DMSC Gateway Implementation Considerations  . . . . . . . . .   8
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     The Internet of Agents (IoA) is driving a shift in the communication
     model from the traditional host-to-host (or client-server) model to
     an Agent-to-Agent interaction model.

     One of the core characteristics of an Agent is autonomy, which
     consequently generates a demand for highly dynamic networking.
     Introducing DMSC Gateways that acting as a crucial intermediary layer
     is a good approach to enable efficient Agent discovery, information
     distribution among Agents, Quality of Service (QoS) and security
     assurance for Agent communications.

     This document discusses the requirements for introducing DMSC
     Gateways into Agent-to-Agent communications in terms of what benefits
     could be brought by the DMSC Gateways.

     In theory, Agents could be interconnected without any intermidiate
     Agent-specific gateways.  However, significant chanllenges (including
     issues of scalability, security, communication efficiency etc.) could
     rise if Agents just interconnect in a fully open and un-managed way.








  Liu                       Expires 20 July 2026                  [Page 2]


  Internet-Draft          DMSC Gateway Requirements           January 2026


  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
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Functional Requirements of DMSC Gateway

  2.1.  Delegated Agent Discovery

     In dynamic, heterogeneous, and variable-scale AI Agent environments,
     traditional discovery and addressing mechanisms based on static
     configuration or simple service names are no longer sufficient to
     meet the demand.

     The complexity of Agent communication requires the DMSC Gateway to
     provide higher levels of abstraction and intelligent services.  This
     subsection discusses two critical enhanced discovery and addressing
     mechanisms: Agent ID based addressing and task decomposition based
     Agent discovery.

  2.1.1.  ID-based Agent Location Resolution

     In an Agent network, every Agent should be assigned a globally
     unique, persistent, and infrastructure-agnostic identifier, known as
     the Agent ID.  One of the core functions of the DMSC Gateway is to
     act as the resolver for this unified namespace, providing transparent
     addressing services for Agents:

     *  Agent ID Registration (Optional): Each Agent, upon startup, can
        delegate the ID registration task to the DMSC Gateway, thereby
        eliminating the need to specially implement a set of protocols and
        logic for communicating with a registration server.

     *  Addressing Request: When an Initiator Agent needs to communicate
        with a Target Agent, it does not need to know any network details
        of the target, such as its IP address.  It only needs to specify
        the Target Agent's ID in the communication request.

     *  Address Resolution: The DMSC Gateway receives the request and
        queries its local or external servers for the latest reachability
        information corresponding to the Agent ID.

     This mechanism offers the following benefits:





  Liu                       Expires 20 July 2026                  [Page 3]


  Internet-Draft          DMSC Gateway Requirements           January 2026


     *  Decoupling and Simplification: Agent developers can focus on their
        business logic without having to deal with network-layer IP
        address resolution, achieving complete decoupling between business
        logic and the communication infrastructure.

     *  Security and Policy Enforcement: The Gateway, acting as a central
        control point, can enforce security policies during the addressing
        resolution phase, such as verifying whether the initiator has
        permission to communicate with the target, thereby embedding
        security control at the very beginning of communication
        establishment.

  2.1.2.  Task-based Agent Searching

     In many collaborative scenarios, the Initiator Agent may not know
     which specific Agent it needs to interact with but rather has a high-
     level task objective to accomplish.  This necessitates the DMSC
     Gateway providing an Intent-Based or Capability-Based discovery
     mechanism:

     *  Capability Registration (Optional): In addition to the Agent ID,
        each Agent must declare a set of "capabilities" it provides to the
        Gateway upon registration.  These capabilities can be described
        using structured attributes and should follow a common capability
        model schema.

     *  Task Declaration: The Initiator Agent submits a task request to
        the Gateway, such as "translate this Chinese document into
        English" or "analyze the buildings in this satellite image."  This
        request is a declaration of the desired outcome, rather than a
        call to a specific service.

     *  Task Decomposition and Capability Matching: The DMSC Gateway
        either contains or can access a task decomposition engine.  For
        complex tasks, the gateway can break them down into a series of
        sub-tasks (e.g., "document parsing" -> "Chinese-to-English
        translation" -> "format re-structuring").  Subsequently, the
        gateway searches its registration repository for Agents whose
        capability descriptions match each (sub) task.

     *  Agent Recommendation or Orchestration: The Gateway returns the
        list of discovered Agents that can satisfy the task requirements
        to the Initiator Agent, which then selects one.  In a more
        automated mode, the Gateway can directly act as an Orchestrator,
        routing the task request to the most suitable Agent, or even
        coordinating multiple Agents to collectively complete a complex
        task chain.




  Liu                       Expires 20 July 2026                  [Page 4]


  Internet-Draft          DMSC Gateway Requirements           January 2026


     Gateway-based mechanism offers the following benefits:

     *  Flexibility for Local Collaboration: For Agents to break away from
        statically orchestrated workflows or service call chains, they
        usually rely on the inference and orchestration capabilities of
        Large Language Models (LLMs).  However, in certain security/
        privacy-sensitive or highly localized scenarios, some Agents may
        only be available locally.  LLMs cannot discover these Agents and
        thus cannot orchestrate their tasks.  By using a locally deployed
        Gateway, local Agents, once their capabilities are registered, can
        be automatically included in the scope of task consideration.
        This allows Agent ecosystems that are only deployed locally to
        dynamically adapt and evolve.

     *  Increased Abstraction Level: The interaction between Agents is
        elevated from the level of "how to call" to "what needs to be
        done," significantly simplifying the programming model for complex
        tasks.  This is equivalent to an Agentic upgrade of the
        traditional TCP/IP Socket interface.

  2.2.  Agent Communication Access Control

     The DMSC Gateway can implement fine-grained, context-based access
     control policies, ensuring that interactions only occur between
     authorized Agents and in permitted ways.  The execution of access
     control policies is based on context information across multiple
     dimensions:

     *  Identity-Based Access Control (IBAC): This is the most fundamental
        policy.  Policy rules can be defined as: "Agent A is allowed to
        communicate with Agent B," or "Agents belonging to 'Department X'
        are allowed to access Agents of 'Database Y'."  Before routing a
        message, the Gateway verifies whether the initiator ID and the
        target ID are within the allowed communication matrix.

     *  Capability-Based Access Control (CBAC): This policy introduces the
        dimensions of intent and capability on top of identity.  Policy
        rules can be more dynamic and semantic, for example: - Only Agents
        with the 'Financial Data Analysis' capability can access the 'Core
        Financial Database' Agent.  - An Agent requesting the 'Medical
        Diagnosis' capability must itself possess the capability tag for
        'Compliant Patient Data Handling' before it can call the
        corresponding diagnosis Agent.  This approach ensures that Agents
        are not only discoverable but are also used within the correct,
        authorized context.






  Liu                       Expires 20 July 2026                  [Page 5]


  Internet-Draft          DMSC Gateway Requirements           January 2026


     *  Attribute-Based Access Control (ABAC): This is a more generalized
        model that can make dynamic decisions by combining identity,
        capability, and environmental attributes (such as time,
        communication frequency, data sensitivity tags of the request,
        etc.).  For example: "Only Agents with 'High-Level' security
        certification, coming from a secure internal network, and
        operating during working hours, are allowed to call system
        administration Agents."

     Gateway-based mechanism offers the following benefits:

     *  Principle of Least Privilege: Through fine-grained policy
        definition, it is ensured that each Agent only possesses the
        minimum communication privileges necessary to complete its task,
        significantly reducing the attack surface.

     *  Dynamic Policy Enforcement: The Gateway, as the policy enforcement
        point, can intercept and evaluate every communication attempt in
        real-time, ensuring policy consistency in a dynamic environment.

     *  Enhanced Ecosystem Security: By shifting access control from the
        application layer down to the communication layer, a security
        perimeter near the edge is provided for the entire AI Agent
        ecosystem.  This manages risks at the source, thereby enhancing
        the security of the Agent network and simultaneously reducing the
        overall cost of protection.

  2.3.  Information Distribution among Agents

     This section describes the information distribution of AI agents from
     two dimensions.  One dimension is the number of communication
     participants, which is divided into Point-to-Point Communication (2
     AI agents) and Group Communication (3 or more AI agents), and the
     section is divided into two sub-sections based on this dimension.

     This section specifically discusses the content that DMSC Gateways
     are involved in both cases.

  2.3.1.  Point-to-Point Distribution

     In the Point-to-Point information distribution process, the typical
     processing performed by a gateway includes, but is not limited to:

     *  Application Layer Proxy (to facilitate monitoring/auditing of AI
        agent communication behavior, or to hide AI agent identity, etc.)

     *  Relay (to forward communication messages, making cross-domain
        communication easier, etc.)



  Liu                       Expires 20 July 2026                  [Page 6]


  Internet-Draft          DMSC Gateway Requirements           January 2026


     *  Traffic aggregation (to provide a tree-structured traffic
        regulation, improving communication efficiency).

  2.3.2.  Pub/Sub

     One AI agent publishes the information to the gateway, and the
     gateway then distributes the information to the subscribing Agents
     based on their Subscribe status.  At the application layer, Pub/Sub
     is a common and efficient method of information distribution,
     especially suitable for large-scale group communication scenarios.

  3.  Gap Analysis of Current Gateways

     Despite the existence of various forms of gateway devices and
     software in current networks, their primary design goals revolve
     around traditional network forwarding, network protocol translation,
     security isolation, and load balancing.  When faced with the unique
     requirements of AI Agent communication, these existing solutions
     exhibit significant shortcomings in both architecture and
     functionality.  This chapter will analyze why existing hardware and
     software gateways fail to meet the aforementioned Agent communication
     needs.

  3.1.  Hardware form Gateways

     Common hardware gateway forms include, but are not limited to:
     network routers/switches, firewalls, dedicated protocol translation
     gateways, and broadband access equipment (BRAS/BNG).  These devices
     are typically deployed as dedicated hardware, focusing on processing
     at the Network and Transport layers.

     The core limitation of hardware gateways lies in their low processing
     layer.  They focus on network packets rather than Agent entities
     possessing identity and intent, and thus lack the necessary
     abstraction and computational power to handle high-level semantics
     and dynamic relationships.  Hardware gateways often utilize processor
     architectures, such as Network Processors (NPs), that are optimized
     for network-layer computation.  Consequently, they are difficult, if
     not impossible, to extend to support the high-level, semantic-based
     logical operations required for Agent communication.

  3.2.  Software form Gateways

     Common software gateway forms include: API Gateways and Cloud Load
     Balancers.  These gateways are widely used in cloud-native
     environments and operate closer to the application layer, but their
     design paradigm remains tightly coupled with the architecture of
     services or API microservices.



  Liu                       Expires 20 July 2026                  [Page 7]


  Internet-Draft          DMSC Gateway Requirements           January 2026


     Software gateways are closer to meeting the requirements than
     hardware gateways, but their fundamental problem lies in the
     limitations of the fixed "service" paradigm.  They treat backends as
     relatively static services defined by APIs, rather than a dynamic
     collective of Agents possessing intent and collaborative
     capabilities.  Their security model and discovery mechanisms lack
     native support for the Agent's autonomy, dynamism, and capability
     semantics.

  4.  DMSC Gateway Implementation Considerations

     TBD.

  5.  Security Considerations

     TBD

  6.  IANA Considerations

     This document has no IANA actions.

  7.  Acknowledgements

     TBD

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

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

  Author's Address

     Bing Liu
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: leo.liubing@huawei.com







  Liu                       Expires 20 July 2026                  [Page 8]


name: draft-zhang-dmsc-mas-communication
rev: 00
title: Security Analysis of Multi-agents Secured Communication and Limitations of Existing Protocols
time: 2026-01-16T13:44:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-20T13:44:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.850271+00:00
source: ietf
abstract:
  Multi-agents systems (MAS) increasingly cooperate through workflow,
     orchestrated, and mesh communication patterns.  While existing
     Internet protocols provide confidentiality and endpoint
     authentication, they were not designed for agent-native semantics
     such as dynamic identity, computation-bounded requests, context
     integrity, and intermediary trust.  This document analyzes security
     risks in agent communication and identifies limitations in widely
     deployed protocols (TLS, HTTP, MQTT,A2A and etc.) and developer
     framework (AutoGen and etc.).  This document intend to establish a
     common problem statement and gap analysis to inform future IETF
     standardization.

full_text:
  DMSC Working Group                                              H. Zhang
  Internet-Draft                                             China Telecom
  Intended status: Standards Track                         16 January 2026
  Expires: 20 July 2026


  Security Analysis of Multi-agents Secured Communication and Limitations
                           of Existing Protocols
                   draft-zhang-dmsc-mas-communication-00

  Abstract

     Multi-agents systems (MAS) increasingly cooperate through workflow,
     orchestrated, and mesh communication patterns.  While existing
     Internet protocols provide confidentiality and endpoint
     authentication, they were not designed for agent-native semantics
     such as dynamic identity, computation-bounded requests, context
     integrity, and intermediary trust.  This document analyzes security
     risks in agent communication and identifies limitations in widely
     deployed protocols (TLS, HTTP, MQTT,A2A and etc.) and developer
     framework (AutoGen and etc.).  This document intend to establish a
     common problem statement and gap analysis to inform future IETF
     standardization.

  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 20 July 2026.

  Copyright Notice

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






  Zhang                     Expires 20 July 2026                  [Page 1]


  Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


     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 . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Core Communication Security Risks in MAS  . . . . . . . . . .   3
     5.  Limitations of Existing Protocols in Addressing Agent
             Communication Security  . . . . . . . . . . . . . . . . .   5
     6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   7
     10. Normative References  . . . . . . . . . . . . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     AI agents are autonomous software entities capable of interacting
     with other agents, tools, and services to perform multi-step
     reasoning and task execution.  Emerging MAS are deployed across
     heterogeneous infrastructures, often spanning administrative domains.
     Current Internet security mechanisms primarily protect communication
     channels and endpoints.  However, they do not fully address agent-
     specific security semantics, including dynamic identity, workload-
     based abuse, semantic context integrity, and trust in intermediaries.
     This document provides: [IoA].

     *  A brief threat analysis of agent communication based on
        collaboration patterns.

     *  A classification of core security risks.

     *  A gap analysis highlighting the limitations of protocols and
        developer framework.

     The scope of this document focuses on communication security for
     distributed AI agents, including:Agent-to-Agent (A2A), Agent-to-
     Orchestrator (A2O), Agent-to-Tool/Service (A2T).  It does not cover
     model training security, data governance, or ethical issues.



  Zhang                     Expires 20 July 2026                  [Page 2]


  Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


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

  3.  Terminology

     The following terms are defined in [architecture] .

     *  Agent: An autonomous software entity capable of perception,
        planning, decision-making, and execution.

     *  DMSC: Dynamic Multi-agent Secured Collaboration.  The framework
        and infrastructure enabling secure and efficient collaboration
        among dynamic agents.

  4.  Core Communication Security Risks in MAS

     MAS orchestration mechanisms include three primary patterns[IoA]:
     Workflows rely on predefined, linear, or conditional task sequences,
     exhibiting predictable sequential control flows and a pipeline
     topology; Hierarchical Planning utilizes a centralized orchestrator
     for task decomposition and intelligent routing, resulting in a star
     or tree topology with highly concentrated control and decision
     authority; and Multi-Agent Collaboration features a decentralized,
     peer-to-peer architecture where agents interact dynamically within a
     mesh or swarm topology, distributing both control flow and decision-
     making capabilities.

     From a security perspective, workflows face risks primarily related
     to context integrity, as communication is limited to adjacent agents,
     making the system vulnerable to payload injection or corruption
     despite clear identity boundaries.  Hierarchical Planning presents
     significant Single Point of Failure (SPOF) and Man-in-the-Middle
     (MITM) risks due to its centralized nature; a compromise of the
     orchestrator can lead to global impact, necessitating End-to-End
     Encryption (E2EE) and agent-payload binding.  Meanwhile, Multi-Agent
     Collaboration, characterized by fuzzy identity and trust boundaries,
     is susceptible to computational Denial of Service (DoS) attacks as
     well as context injection and pollution, requiring strict peer-level
     identity validation, context signing, and workload control.

     *  Identity and Trust Boundaries

     Agent-based systems rely on dynamically instantiated, short-lived
     entities whose identities are often assigned at runtime.  Unlike
     traditional services, agents do not map cleanly to long-lived hosts,



  Zhang                     Expires 20 July 2026                  [Page 3]


  Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


     domains, or organizational identities.  In collaborative or mesh
     topologies, agents may be created, delegated, or terminated on
     demand, and may act on behalf of other agents or users.  This
     introduces identity ambiguity and weak trust binding: it becomes
     unclear who an agent represents, what authority it has, and whether
     its identity is stable over time.

     *  Context Integrity and Semantic Consistency

     Agent communication is not limited to stateless requests; it often
     carries evolving conversational state, task context, intermediate
     reasoning artifacts, and shared memory objects.  While transport-
     layer security can protect messages in transit, it does not ensure
     that the semantic context remains intact across multiple hops,
     intermediaries, or storage layers.  In workflows and collaborative
     meshes alike, context can be truncated, reordered, injected, or
     selectively modified without cryptographic detection.  This creates
     risks of context poisoning, instruction injection, and silent
     manipulation of agent reasoning processes.

     *  Orchestrator and Broker Trust

     In hierarchical and brokered architectures, a central orchestrator or
     message broker mediates most or all communications.  This entity
     becomes a single point of failure and a powerful trust anchor.  If
     compromised, misconfigured, or simply overly privileged, the
     orchestrator can inspect, modify, suppress, or replay messages
     between agents.  Even when transport security is used, the
     orchestrator typically terminates connections and therefore has full
     access to plaintext.  This introduces MITM risks and undermines E2E
     security guarantees.

     *  Unpredictable Workload and Resource Exhaustion

     Agent interactions frequently involve expensive computation such as
     large-model inference, retrieval-augmented generation, or tool
     execution.  In collaborative and mesh settings, any peer may request
     high-cost operations from another agent.  Existing protocols do not
     account for computational asymmetry between requester and responder,
     nor do they provide mechanisms to express, negotiate, or enforce
     resource budgets.  As a result, agents are vulnerable to DoS attacks
     that exploit legitimate-looking but computationally expensive tasks.

     *  Architectural Amplification of Risk

     The above risks manifest differently across communication patterns.
     In sequential workflows, the primary concerns are identity binding
     and preservation of task context across hops.  In orchestrated



  Zhang                     Expires 20 July 2026                  [Page 4]


  Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


     systems, central control amplifies risks of message manipulation and
     single points of failure.  In decentralized collaboration, dynamic
     peer discovery and many-to-many communication exacerbate identity
     ambiguity, context pollution, and DoS exposure.  Together, these
     patterns demonstrate that agent communication security is not merely
     a transport problem, but an architectural and semantic one.

  5.  Limitations of Existing Protocols in Addressing Agent Communication
      Security

     This section analyzes why commonly used communication protocols and
     frameworks—specifically TLS, HTTP/gRPC, the A2A protocol, and
     AutoGen—do not adequately mitigate the risks identified in Section 4.
     As highlighted in draft-li-dmsc-inf-architecture-01 [architecture],
     multi-agent systems require network infrastructures to support agent-
     centric identity management, capability-aware communication, and
     cross-domain collaboration—requirements that existing protocols fail
     to address, leading to resource exhaustion risks.  The focus is not
     on implementation flaws, but on structural gaps between protocol
     assumptions and the requirements of agent-based systems.

     *  Inadequate Support for Dynamic Agent Identity

     TLS, HTTP/gRPC with OAuth or TLS authentication mechanisms bind
     identity to endpoints, certificates, or client identifiers.  These
     constructs assume relatively stable entities such as servers, users,
     or devices.  They do not natively support ephemeral, software-defined
     agents that are created on demand, act under delegated authority, or
     represent composite roles.  While the A2A protocol introduces
     explicit AgentID fields, these identifiers are transmitted without
     mandatory cryptographic binding to trust anchors, delegation chains,
     or verifiable credentials.  In AutoGen, agent identity is typically
     managed at the application layer using tokens or configuration files,
     lacking standardized, interoperable identity semantics.
     Consequently, none of these protocols provide a robust mechanism to
     express who an agent is, whom it represents, and under what authority
     it operates.

     *  Lack of End-to-End Context Protection

     Existing protocols prioritize transport security rather than message-
     level or context-level integrity.  TLS ensures confidentiality and
     integrity only between adjacent endpoints; once a message is
     decrypted, any intermediary, broker, or application layer can modify
     the payload without detection.  HTTP/gRPC similarly protect the
     channel but do not require payload signing or semantic validation.
     A2A defines structured message objects but does not mandate E2E
     encryption or cryptographic signing of context elements.  AutoGen



  Zhang                     Expires 20 July 2026                  [Page 5]


  Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


     inherits the properties of its underlying transports, with no built-
     in enforcement of message or context integrity.  As a result, none of
     these systems can guarantee that conversational state, instructions,
     or task context have not been altered across multiple hops.

     *  Over-Privileged Orchestrators and Brokers

     In orchestrated and brokered architectures, existing protocols
     implicitly assume that the intermediary is fully trusted.  TLS
     termination at a gateway, HTTP reverse proxies, MQTT brokers, and
     agent orchestrators in both A2A-based and AutoGen systems all have
     access to plaintext messages.  This means that the orchestrator or
     broker can become an undetectable MITM, contradicting the distributed
     trust assumptions often made in multi-agent designs.

     *  Absence of Computation-Aware Communication Controls

     None of the evaluated protocols incorporate concepts of computational
     cost, resource budgeting, or workload fairness.  A request that
     triggers a trivial database lookup and one that initiates a multi-
     step reasoning chain over a large language model are treated
     identically at the protocol level.  MQTT quality-of-service levels
     ensure delivery semantics, not execution cost.  A2A and AutoGen allow
     agents to request complex tasks from peers without standardized
     mechanisms to declare, negotiate, or enforce limits on CPU, memory,
     inference time, or external tool usage.  This structural blind spot
     leaves agents vulnerable to resource exhaustion attacks that appear
     legitimate at the message layer.

     *  Mismatch Between Agent Architectures and Protocol Assumptions

     Collectively, TLS, HTTP/gRPC and MQTT were designed around service-
     oriented or message-oriented paradigms in which endpoints are
     relatively stable, intermediaries are trusted, and payload semantics
     are outside the protocol’s scope.  Agent-based systems violate these
     assumptions: identities are fluid, trust is contextual and delegated,
     messages carry evolving semantic state, and computation itself
     becomes an attack surface.  The result is a systematic gap: even when
     these protocols are correctly implemented, they cannot provide the
     E2E identity assurance, context integrity, intermediary minimization,
     and resource-aware controls required for secure multi-agent
     communication.









  Zhang                     Expires 20 July 2026                  [Page 6]


  Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


  6.  Conclusion

     This document focuses on the communication security of multi-agent
     systems, systematically identifying critical gaps between existing
     communication protocols (such as TLS, HTTP/gRPC, MQTT, A2A, and
     AutoGen) and the security requirements of dynamic agent networks.
     Key issues identified include inadequate support for ephemeral and
     dynamic agent identities, lack of E2E semantic context protection,
     over-privileged intermediaries (brokers/orchestrators) leading to
     MITM risks, absence of computation-aware communication controls that
     render agents vulnerable to DoS attacks, and architectural
     amplification of these risks across different collaboration patterns
     (workflows, hierarchical planning, and decentralized mesh
     collaboration).  Collectively, these gaps demonstrate that secure
     communication in multi-agent systems is not merely a transport-layer
     problem but a systematic challenge involving identity semantics,
     context integrity, and resource management.

  7.  Security Considerations

     This document suggests that secure agent communication requires a new
     class of protocol capabilities that extend beyond traditional network
     and application-layer security.  These include: (1) agent identity
     semantics that support ephemeral and delegatable identities
     independent of hosts or domains; (2) computation-aware communication
     mechanisms that allow agents to declare, negotiate, and enforce
     resource consumption limits, mitigating high-cost request abuse; (3)
     semantic context protection, through mandatory signing and optional
     encryption of payloads and context windows to preserve integrity
     across multiple hops; and (4) end-to-end trust in mediated
     topologies, enabling brokers or orchestrators to route messages
     without accessing or modifying their contents.  Together, these
     directions outline a path for future standardization: defining agent-
     aware identity and delegation models, specifying message- and
     context-level security envelopes, and integrating resource governance
     into communication protocols.

  8.  IANA Considerations

     TBD

  9.  Acknowledgement

     TBD

  10.  Normative References





  Zhang                     Expires 20 July 2026                  [Page 7]


  Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


     [architecture]
                Li, X. and A. W, "draft-li-dmsc-inf-architecture-01", 9
                January 2026.

     [IoA]      Idan, H., "Securing-Agentic-Applications-Guide-1.0", 28
                July 2025.

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

  Author's Address

     Haodi Zhang
     China Telecom
     Tangxia Street, Tianhe District
     Guangzhou
     Guangzhou, 510000
     China
     Email: zhanghaodi@chinatelecom.cn






























  Zhang                     Expires 20 July 2026                  [Page 8]


name: draft-guy-bary-stamp-protocol
rev: 00
title: Secure Task-bound Agent Message Proof (STAMP) Protocol
time: 2025-11-03T07:09:24Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-29T15:52:38Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.855048+00:00
source: ietf
abstract:
  The Secure Task-bound Agent Message Proof (STAMP) protocol provides a
     cryptographically verifiable delegation and proof framework for AI-
     driven multi-agent systems. STAMP introduces task-bound access tokens
     and message-level proofs for agentic environments, binding tokens to
     specific user intents, tasks, and agent identities. STAMP tokens
     ensure that delegation, execution, and agent-to-agent communication
     comply with least-privilege and zero-trust security principles.
     STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of-
     possession (PoP) techniques, providing stronger security for dynamic,
     non-deterministic workflows involving autonomous agents.

full_text:
  Network Working Group                                         Guy Bary
  Internet-Draft                                      Intended status: Standards Track
  Expires: October 29, 2025                                          April 27, 2025


         Secure Task-bound Agent Message Proof (STAMP) Protocol
                   draft-guy-bary-stamp-protocol-00

  Abstract

     The Secure Task-bound Agent Message Proof (STAMP) protocol provides a
     cryptographically verifiable delegation and proof framework for AI-
     driven multi-agent systems. STAMP introduces task-bound access tokens
     and message-level proofs for agentic environments, binding tokens to
     specific user intents, tasks, and agent identities. STAMP tokens
     ensure that delegation, execution, and agent-to-agent communication
     comply with least-privilege and zero-trust security principles.
     STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of-
     possession (PoP) techniques, providing stronger security for dynamic,
     non-deterministic workflows involving autonomous agents.

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

  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 Simplified BSD License text as described in Section 4.e of
     the Trust Legal Provisions and are provided without warranty as
     described in the Simplified BSD License.


  Table of Contents

     1. Introduction
     2. Terminology
     3. Motivation and Use Cases
     4. Protocol Overview
     5. STAMP Token Format
     6. Task Handling (Short vs Long Tasks)
     7. Agent-to-Agent Delegation
     8. Cryptographic Primitives
     9. Message Flows
     10. Comparison to OAuth2 + DPoP and GNAP
     11. Security Considerations
     12. Privacy Considerations
     13. IANA Considerations
     14. References

  1. Introduction

     The rise of autonomous agents, especially AI-driven multi-agent
     systems, introduces complex delegation, communication, and
     authorization challenges. Agents often act independently, call peer
     agents, and dynamically decompose tasks into sub-tasks across system
     boundaries.

     Traditional delegation protocols such as OAuth 2.0 assume a static,
     client-server model and do not natively support task binding or
     dynamic delegation between autonomous entities. STAMP fills this gap
     by binding tokens not just to clients, but to *tasks*, and requiring
     proof-of-possession (PoP) for every resource request or agent-to-agent
     invocation.

     STAMP enables secure, verifiable delegation and task management,
     ensuring agents can operate under strict least-privilege conditions
     while maintaining a complete audit trail across workflows. In AI
     systems where actions are non-deterministic, STAMP provides an
     essential security and governance framework.

  2. Terminology

     Agent:  
        A software entity that performs tasks on behalf of a user or
        another agent.

     Resource Owner (User):  
        The human end-user authorizing tasks to be performed.

     Authorization Server (AS):  
        The entity that issues STAMP tokens to agents after user
        authorization and consent.

     Resource Server (RS):  
        The service or agent that validates STAMP tokens and processes
        secured resource requests.

     Task:  
        A user-defined or agent-defined unit of work. Each STAMP token is
        bound to a specific task context via a unique task identifier.

     STAMP Token:  
        A JWT or CBOR/COSE token that cryptographically binds agent
        identity, task intent, authorized scopes, and proof-of-possession
        material.

     Proof-of-Possession (PoP) Key:  
        An ephemeral asymmetric key pair associated with a STAMP token,
        used to prove possession during resource requests.

     Task Integrity Digest (TID):  
        A cryptographic checksum representing the original user request or
        task definition to detect tampering.

  3. Motivation and Use Cases

     Modern multi-agent systems exhibit dynamic task generation, subtask
     delegation, and high-volume agent-to-agent communication. Traditional
     bearer tokens are inadequate to secure these interactions because:

     - Agents may act outside their authorized task scopes if unchecked.
     - Tasks may mutate non-deterministically under LLM control.
     - Delegation chains may be ambiguous or unverifiable.
     - Revocation, replay prevention, and auditability are difficult.

     STAMP provides:

     - Task-bound authorization with explicit task IDs (TID).
     - PoP key binding per token to prevent token theft/replay.
     - Verifiable agent-to-agent delegation with audit chains.
     - Short-lived tokens for least-privilege and reduced attack window.
     - Support for OAuth 2.0 compatibility fallback when needed.

     Example real-world applications:

     - LLM-driven agent chains for travel planning, calendaring,
       procurement, where each sub-agent has task-specific rights.
     - Enterprise automation where delegated AI assistants interact with
       financial, CRM, and HR systems under zero-trust policies.
     - Multi-stage workflows with sensitive data (e.g., legal review,
       medical record access) requiring strict task-bound controls.

  4. Protocol Overview

     STAMP enhances existing delegation protocols by introducing the
     following primitives:

     - **Task Binding**: Every token explicitly carries a unique task
       identifier (tid) and associated integrity digest (TID).
     
     - **PoP Binding**: Every token carries a confirmation key (cnf.jwk)
       representing an ephemeral public key for proof-of-possession
       during each authorized operation.

     - **Short- and Long-Task Modes**:  
       Tokens can be short-lived (single operation) or support long-lived
       workflows with refresh or continuation proofs.
     
     - **Delegation Model**:  
       Agents can request new subordinate STAMP tokens for peer agents,
       inheriting the original task ID but with subsetted scopes.

     - **Proof Mechanism**:  
       All API or agent communication is accompanied by a cryptographic
       signature using the PoP key over standardized request components,
       preventing replay and enforcing freshness.

     - **OAuth 2.0 / GNAP Compatibility**:  
       STAMP tokens can be obtained via OAuth 2.0 Authorization Code
       Grant flows, Device Code flows, GNAP grants, or other secure
       grant/consent models.

     STAMP defines the lifecycle of a task:

     - A user initiates a task.
     - The agent requests a STAMP token scoped to that task.
     - Each API request proves task continuity.
     - Task completion (or cancellation) ends token validity.

  5. STAMP Token Format

     A STAMP token is a signed JWT (JSON Web Token) or a CBOR/COSE object
     issued by the Authorization Server (AS). It includes the following
     claims:

     - iss (Issuer):  
       The AS that issued the token.

     - sub (Subject):  
       Identifier of the resource owner (user).

     - aud (Audience):  
       Intended recipient(s) (e.g., Resource Servers).

     - tid (Task ID):  
       Unique identifier for the task context. Example: UUID v4.

     - agent (Agent ID):  
       Identifier of the requesting agent (e.g., client_id, DID).

     - scope:  
       List of authorized scopes for the agent under this task.

     - iat, nbf, exp:  
       Issued-at, not-before, and expiration timestamps.

     - jti (JWT ID):  
       Unique identifier for the token instance.

     - cnf (Confirmation Key):  
       Public key information (JWK or COSE key) binding the token to the
       agent's ephemeral PoP key.

     - parent (optional):  
       Identifier of the parent token if the token was obtained via
       delegation.

     - tid_integrity (optional):  
       A SHA-256 digest of the original user instruction (Prompt Integrity
       Digest), ensuring that the agent's actions align with the authorized
       task.

     Example (JWT payload):

     {
       "iss": "https://auth.example.com",
       "sub": "user12345",
       "aud": "https://api.example.com",
       "tid": "550e8400-e29b-41d4-a716-446655440000",
       "agent": "agent-A",
       "scope": "calendar:write email:send",
       "iat": 1700000000,
       "exp": 1700000600,
       "jti": "abc123",
       "cnf": {
         "jwk": {
           "kty": "EC",
           "crv": "P-256",
           "x": "...",
           "y": "..."
         }
       },
       "parent": "xyz7890",
       "tid_integrity": "SHA-256 checksum of task prompt"
     }

  6. Task Handling (Short vs Long Tasks)

  6.1 Short Tasks

     Short tasks involve immediate or short-lived operations that complete
     quickly (e.g., a single API call, minor data retrieval).

     For short tasks:

     - Token lifetimes are very brief (minutes or seconds).
     - Tokens are single-use or allow limited reuse.
     - Refresh tokens are unnecessary; the agent must request a new STAMP
       token for a new task.

     Best practices:

     - Use one STAMP token per short task.
     - Include strong timestamps and expiration (`exp` within 5-15 minutes).

  6.2 Long Tasks

     Long tasks involve workflows spanning multiple steps or prolonged
     durations (e.g., background job orchestration, model training).

     For long tasks:

     - Token lifetime may be extended (hours), but short-lived tokens are
       preferable.
     - Agents can refresh tokens by reauthenticating or presenting valid
       continuation proofs.
     - Continuation tokens MUST maintain the same `tid` and `scope`, with a
       refreshed `exp` and new `jti`.
     - Session binding mechanisms (e.g., nonce confirmation, re-signing)
       SHOULD be used for additional security.

     Best practices:

     - Enforce periodic refresh and re-authorization checkpoints.
     - Invalidate all tokens related to a `tid` if the user revokes consent.

  7. Agent-to-Agent Delegation

     In dynamic multi-agent systems, an agent (Agent A) may need to
     delegate a task or subtask to another agent (Agent B). STAMP
     formalizes this process to maintain verifiable authorization chains
     without privilege escalation.

  7.1 Delegation Process

     1. Agent A holds a valid STAMP token (T_A) bound to Task ID (tid_A).
     2. Agent A requests a new delegated token (T_B) from the Authorization
        Server (AS), presenting T_A as proof.
     3. The AS verifies T_A, confirms delegation is permitted, and issues
        T_B:
        - Same `tid` (or subtask identifier if hierarchical).
        - New `agent` claim identifying Agent B.
        - Scoped to a subset of Agent A's original `scope`.
        - Includes `parent` field linking T_B to T_A's `jti`.
     4. Agent B uses T_B to perform its operations, providing PoP proofs
        per standard STAMP rules.

  7.2 Delegation Constraints

     - The AS SHOULD enforce delegation policies such as:
       - Maximum delegation depth.
       - Approved agent identities.
       - Scope narrowing.

     - Agents SHOULD NOT forward tokens directly without AS mediation.

     - Audit systems MUST record delegation chains (`parent` field).

  8. Cryptographic Primitives

  8.1 Proof-of-Possession (PoP)

     - Agents MUST generate ephemeral ECDSA P-256 key pairs (or equivalent)
       for each STAMP token.
     - The public key is included in the token (`cnf.jwk`).
     - Each API call or message is signed using the private PoP key.

  8.2 Message Signing

     - The signature covers:
       - HTTP Method
       - Request URI
       - Timestamp
       - Nonce (optional for replay protection)
       - `tid` (task identifier)

     - Signature methods SHOULD comply with [I-D.ietf-httpbis-message-signatures].

     - Example:
       ```
       Signature-Input: sig1=("@method" "@path" "tid" "date");alg=ecdsa-p256-sha256
       Signature: sig1=:base64(signature):
       ```

  8.3 Algorithms

     - Mandatory to Implement:
       - ECDSA with SHA-256 (alg=ES256)
       - SHA-256 hashing
     - Recommended:
       - EdDSA (Ed25519) where available.
     - Deprecated:
       - RSA with SHA-1, HMAC without PoP binding.

  8.4 Replay and Freshness

     - Include timestamps (`date`) and optional nonces in signatures.
     - Servers MUST reject requests with stale timestamps or reused
       nonces.

  8.5 Key Management

     - PoP keys MUST be rotated per task or per significant token refresh.
     - Keys SHOULD be held in memory and cleared after use.

  9. Message Flows

  9.1 Token Acquisition Flow (via OAuth 2.0)

     1. User initiates a task via an agent (Agent A).
     2. Agent A requests authorization via OAuth 2.0 Authorization Code
        Grant or Device Code flow.
     3. Authorization Server (AS) authenticates the user and obtains
        consent.
     4. Agent A submits a PoP public key (cnf.jwk) during token request.
     5. AS issues a STAMP token bound to:
        - Agent A's identity
        - Task ID (tid)
        - Scope
        - PoP public key

  9.2 Resource Access Flow

     1. Agent A prepares an HTTP request to the Resource Server (RS).
     2. Agent A signs the request using its PoP private key.
     3. Agent A includes:
        - Authorization: Stamp <STAMP Token>
        - Signature-Input and Signature headers (per HTTP Message
          Signatures draft)
     4. RS verifies:
        - Token validity (issuer, audience, scope, expiry)
        - Proof-of-Possession signature
        - Task ID match
        - Freshness (timestamp, optional nonce)
     5. Upon successful validation, RS authorizes the request.

  9.3 Delegation Flow

     1. Agent A holds a valid STAMP token T_A.
     2. Agent A requests a delegated token T_B from AS for Agent B.
     3. AS issues T_B:
        - Same Task ID (tid)
        - Narrowed scopes
        - Parent link to T_A (parent field)
     4. Agent B uses T_B with its own PoP key to access resources.

  9.4 OAuth 2.0 Fallback Mode

     - If a Resource Server does not recognize STAMP-specific proof
       headers, Agent A MAY present the STAMP token as a Bearer token.
     - This fallback is discouraged unless absolutely necessary.

  10. Comparison to OAuth2 + DPoP and GNAP

     | Feature                     | OAuth2 + DPoP | GNAP   | STAMP       |
     |------------------------------|--------------|--------|-------------|
     | Token binding (PoP)          | Optional     | Yes    | Mandatory   |
     | Task identifier (tid)        | No           | No     | Yes         |
     | Agent-to-agent delegation    | Limited      | Partial| Full Chain  |
     | Non-determinism protection   | No           | No     | Yes         |
     | Short/long task modes        | Manual       | Partial| Built-in    |
     | OAuth2 compatibility fallback| N/A          | N/A    | Supported   |

  11. Security Considerations

     - Tokens are short-lived and PoP-bound to limit exposure.
     - All requests are cryptographically signed for authenticity.
     - Task ID (tid) prevents token misuse across unrelated contexts.
     - Delegation chains are auditable via `parent` claims.
     - Revocation can occur at token or task level by revoking Task ID.

  12. Privacy Considerations

     - Tokens should avoid including sensitive user data directly.
     - Task ID correlation across services should be minimized if not
       necessary.
     - PoP keys should be ephemeral and task-specific to reduce
       fingerprinting risks.
     - Servers should not expose token contents unnecessarily in errors.

  13. IANA Considerations

     This document has no actions for IANA at this time.

  14. References

     [RFC6749] D. Hardt, \"The OAuth 2.0 Authorization Framework\",
     October 2012.

     [RFC7519] M. Jones, \"JSON Web Token (JWT)\", May 2015.

     [RFC8705] B. Campbell, J. Bradley, N. Sakimura, \"OAuth 2.0 Mutual-
     TLS Client Authentication and Certificate-Bound Access Tokens\",
     February 2020.

     [RFC9449] D. Fett, J. Bradley, M. Jones, \"OAuth 2.0 Demonstrating
     Proof-of-Possession at the Application Layer (DPoP)\", November 2023.

     [RFC9635] J. Richer, \"Grant Negotiation and Authorization Protocol
     (GNAP)\", March 2024.

     [I-D.ietf-httpbis-message-signatures] C. Thomson, \"HTTP Message
     Signatures\", IETF Internet-Draft, work in progress.

  Author's Address

     Guy Bary
     Independent
     Email: bgauryy@gmail.com


name: draft-abaris-aicdh
rev: 01
title: AI Content Disclosure Header
time: 2026-01-30T09:56:22Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-03T09:56:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.859507+00:00
source: ietf
abstract:
  This document proposes a machine-readable Hypertext Transfer Protocol
     (HTTP) response header field, AI-Disclosure, to disclose the presence
     and degree of Artificial Intelligence (AI) generated or AI-assisted
     content in web responses.  The header is designed for compatibility
     with HTTP structured field syntax and provides metadata for user
     agents, bots, and archiving systems.  It supports layered disclosure
     strategies alongside human-readable and structured metadata formats.

full_text:
  Independent Submission                                         D. Abaris
  Internet-Draft                                    Individual Contributor
  Intended status: Informational                           30 January 2026
  Expires: 3 August 2026


                        AI Content Disclosure Header
                           draft-abaris-aicdh-01

  Abstract

     This document proposes a machine-readable Hypertext Transfer Protocol
     (HTTP) response header field, AI-Disclosure, to disclose the presence
     and degree of Artificial Intelligence (AI) generated or AI-assisted
     content in web responses.  The header is designed for compatibility
     with HTTP structured field syntax and provides metadata for user
     agents, bots, and archiving systems.  It supports layered disclosure
     strategies alongside human-readable and structured metadata formats.

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





  Abaris                    Expires 3 August 2026                 [Page 1]


  Internet-Draft            AI-Disclosure Header              January 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   3
     3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     4.  Field Definition  . . . . . . . . . . . . . . . . . . . . . .   3
     5.  Field Syntax  . . . . . . . . . . . . . . . . . . . . . . . .   4
       5.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
       5.2.  Field Keys  . . . . . . . . . . . . . . . . . . . . . . .   4
     6.  Semantics . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     As AI-generated content proliferates across the web, users
     [BV-Report], platforms, and regulators increasingly demand
     transparent disclosure of algorithmic involvement in content creation
     [PAI-Framework].  Existing approaches to disclosure (e.g., HTML
     disclaimers) lack machine-readability [GV-Prov], making automation,
     indexing, and compliance challenging.

     Regulatory initiatives like the EU Artificial Intelligence Act
     include transparency obligations for AI-generated or manipulated
     content, and the European Commission is developing a Code of Practice
     on marking and labelling AI-generated content to support compliance
     with those obligations EU-AI-Act [EC-CodePractice].  A lightweight,
     machine-readable HTTP signal can complement these efforts by enabling
     automated detection and disclosure in web delivery.

     This document defines the AI-Disclosure HTTP header field, providing
     a lightweight, machine-readable mechanism focused specifically on
     signaling the presence and mode of AI involvement in the generation
     of an HTTP response's content.  It utilizes HTTP Structured Fields
     [RFC9651] to offer a simple dictionary format directly within the
     HTTP response headers.

     The goal of AI-Disclosure is to offer a low-overhead, easily parsable
     signal primarily for automated systems like web crawlers, archiving
     tools, or user agents that may need a quick indication of AI usage
     without processing complex manifests.  This header is intended to be
     applied at the entire response level.



  Abaris                    Expires 3 August 2026                 [Page 2]


  Internet-Draft            AI-Disclosure Header              January 2026


     It is important to distinguish this mechanism from more comprehensive
     content provenance and authenticity frameworks like the Coalition for
     Content Provenance and Authenticity (C2PA) specification [C2PA-Spec].
     C2PA provides richer, cryptographically signed assertions about
     content provenance, potentially covering detailed creation/
     modification history and applying to specific regions within an asset
     ("Regions of Interest").  C2PA information can be linked via methods
     including the HTTP Link header [RFC8288] pointing to an associated
     manifest.

     AI-Disclosure can be seen as complementary to such systems within a
     layered disclosure strategy.  While C2PA offers strong, verifiable,
     and granular provenance, AI-Disclosure provides a simpler, advisory
     signal directly in the HTTP interaction for basic AI involvement
     awareness.  Systems requiring high assurance or sub-resource
     granularity should utilize frameworks like C2PA.

  2.  Terminology

  2.1.  Acronyms and Abbreviations

     AI: Artificial Intelligence

     HTTP: Hypertext Transfer Protocol

     C2PA: Content Provenance and Authenticity, refers to the
     specification developed by the Coalition for Content Provenance and
     Authenticity

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

  4.  Field Definition

     The AI-Disclosure field is defined as a Structured Field of type
     Dictionary, as described in [RFC9651].










  Abaris                    Expires 3 August 2026                 [Page 3]


  Internet-Draft            AI-Disclosure Header              January 2026


     +===============+==========+========+========+===========+=========+
     | Header Field  |Structured|Template|Protocol|Status     |Reference|
     | Name          |Type      |        |        |           |         |
     +===============+==========+========+========+===========+=========+
     | AI-Disclosure |Dictionary|(blank) |http    |provisional|[this    |
     |               |          |        |        |           |document]|
     +---------------+----------+--------+--------+-----------+---------+

                                   Table 1

  5.  Field Syntax

     The AI-Disclosure field value MUST conform to the syntax for
     Dictionary structures defined in Section 3.2 of [RFC9651].  Each key
     in the dictionary conveys a distinct aspect of AI disclosure.

  5.1.  Example

     AI-Disclosure: mode=ai-originated;
                    model="gpt-4";
                    provider="OpenAI";
                    reviewed-by="editorial-team";
                    date=@1745286896

  5.2.  Field Keys

          +=============+========+==================================+
          | Key         | Type   | Description                      |
          +=============+========+==================================+
          | mode        | Token  | Indicates the nature of AI       |
          |             |        | involvement: none, ai-modified,  |
          |             |        | ai-originated, machine-generated |
          +-------------+--------+----------------------------------+
          | model       | String | Identifier of the AI model used  |
          |             |        | (e.g., gpt-4)                    |
          +-------------+--------+----------------------------------+
          | provider    | String | Organization providing the AI    |
          |             |        | system                           |
          +-------------+--------+----------------------------------+
          | reviewed-by | String | Entity or team who reviewed the  |
          |             |        | AI content                       |
          +-------------+--------+----------------------------------+
          | date        | Date   | Generation timestamp as a        |
          |             |        | numeric epoch value, conforming  |
          |             |        | to RFC9651.                      |
          +-------------+--------+----------------------------------+

                                    Table 2



  Abaris                    Expires 3 August 2026                 [Page 4]


  Internet-Draft            AI-Disclosure Header              January 2026


  6.  Semantics

     The AI-Disclosure header field is an optional and advisory header
     providing information about the use of AI in generating the response
     content.  Its presence indicates voluntary disclosure by the server.
     Absence of the header implies nothing about AI usage.

     The meaning of the header is primarily defined by the mode key, whose
     possible values are described below:

      +===================+=============================================+
      | Mode Value        | Description                                 |
      +===================+=============================================+
      | none              | Indicates that AI was not used in the       |
      |                   | creation or substantive modification of the |
      |                   | content.                                    |
      +-------------------+---------------------------------------------+
      | ai-modified       | Indicates AI was used to assist with or     |
      |                   | modify content primarily created by humans. |
      |                   | The source material was not AI-generated.   |
      |                   | Examples include AI-based grammar checking, |
      |                   | style suggestions, or generating highlights |
      |                   | or summaries of human-written text.         |
      +-------------------+---------------------------------------------+
      | ai-originated     | Indicates the core content was initially    |
      |                   | generated by AI but subsequently reviewed,  |
      |                   | edited, or significantly guided by humans.  |
      |                   | This suggests human oversight for accuracy  |
      |                   | or appropriateness, even if the originality |
      |                   | for copyright purposes might be affected.   |
      +-------------------+---------------------------------------------+
      | machine-generated | Indicates the content was primarily or      |
      |                   | entirely generated by AI with minimal or no |
      |                   | human intervention or review post-          |
      |                   | generation.  AI may be responsible for      |
      |                   | substantive assertions or conclusions.      |
      +-------------------+---------------------------------------------+

                                    Table 3

     Other keys like model, provider, reviewed-by, and date provide
     optional, additional context about the AI model used, the provider,
     human review, or the generation time, respectively.

     Recipients should treat this header as informational only and refer
     to the Security Considerations (Section 7) regarding its
     trustworthiness.




  Abaris                    Expires 3 August 2026                 [Page 5]


  Internet-Draft            AI-Disclosure Header              January 2026


     *Note:* The AI-Disclosure header applies to the entire content of the
     HTTP response payload.  The ai-modified and ai-originated values
     indicate AI involvement, but this header does not provide information
     about specific locations or the exact nature of the partial
     involvement.  For expressing provenance information about specific
     parts of a resource, more comprehensive mechanisms such as C2PA
     [C2PA-Spec] should be used.  The distinction between ai-modified and
     ai-originated aims to address whether the foundational content was
     human or AI, reflecting concerns about originality and the nature of
     the transformation.  The distinction between ai-originated and
     machine-generated primarily reflects the level of human review or
     intervention post-generation.

  7.  Security Considerations

     The AI-Disclosure field is intended to provide advisory metadata
     about AI-generated or AI-assisted content and does not include any
     form of integrity protection.  As such, the field can be trivially
     spoofed or altered by intermediaries unless the response is delivered
     over a secure transport such as HTTPS.

     Clients and intermediaries MUST NOT rely on the presence, absence, or
     value of the AI-Disclosure field for making security-critical
     decisions.  The field is not authenticated and SHOULD be treated as
     untrusted input.

     This document does not define any mechanisms for cryptographic
     verification or provenance validation of the header's content.
     Implementations that require trustworthy disclosure metadata SHOULD
     rely on additional application-layer integrity mechanisms or signed
     metadata systems, such as those defined by C2PA [C2PA-Spec].

  8.  IANA Considerations

     IANA is requested to register the AI-Disclosure header field in the
     "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained
     at https://www.iana.org/assignments/http-fields/
     (https://www.iana.org/assignments/http-fields/), according to the
     procedures outlined in [RFC9110].












  Abaris                    Expires 3 August 2026                 [Page 6]


  Internet-Draft            AI-Disclosure Header              January 2026


     +==========+==========+===========+=========+==========+============+
     |Header    |Applicable|Status     |Reference|Structured|Notes       |
     |Field Name|Protocol  |           |         |Type      |            |
     +==========+==========+===========+=========+==========+============+
     |AI-       |http      |provisional|[this    |Dictionary|Discloses   |
     |Disclosure|          |           |document]|          |AI          |
     |          |          |           |         |          |involvement |
     |          |          |           |         |          |in content  |
     |          |          |           |         |          |creation    |
     +----------+----------+-----------+---------+----------+------------+

                                    Table 4

  9.  References

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

     [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
                DOI 10.17487/RFC8288, October 2017,
                <https://www.rfc-editor.org/rfc/rfc8288>.

     [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/rfc/rfc9110>.

     [RFC9651]  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>.

  9.2.  Informative References

     [BV-Report]
                Big Valley Marketing, "AI Disclosure and Transparency:
                Closing the Trust Gap", November 2024,
                <https://bigvalley.co/wp-content/uploads/2024/11/BV-AI-
                Research-Report.pdf>.





  Abaris                    Expires 3 August 2026                 [Page 7]


  Internet-Draft            AI-Disclosure Header              January 2026


     [C2PA-Spec]
                Coalition for Content Provenance and Authenticity (C2PA),
                "C2PA Specification Version 2.1", July 2024,
                <https://c2pa.org/specifications/specifications/2.1/specs/
                C2PA_Specification.html>.

     [EC-CodePractice]
                European Commission, "Code of Practice on marking and
                labelling of AI-generated content", 27 January 2026,
                <https://digital-strategy.ec.europa.eu/en/policies/code-
                practice-ai-generated-content>.

     [EU-AI-Act]
                European Union, "Regulation (EU) 2024/1689 (Artificial
                Intelligence Act)", 13 June 2024,
                <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

     [GV-Prov]  Hofmann, S., "Content Provenance and Disclosure
                Requirements for AI Generated Content on Digital and
                Traditional Media Platforms", 31 March 2025,
                <https://www.globalvoices.org.au/post/content-provenance-
                and-disclosure-requirements-for-ai-generated-content-on-
                digital-and-traditional-m>.

     [PAI-Framework]
                Partnership on AI, "PAI's Responsible Practices for
                Synthetic Media: A Framework for Collective Action", 27
                February 2023,
                <https://syntheticmedia.partnershiponai.org/>.

  Acknowledgments

     The author thanks Michael Andrews from Teradata for helpful comments
     and feedback on early staging of this document.

  Author's Address

     Dogu Abaris
     Individual Contributor
     Email: abaris@null.net











  Abaris                    Expires 3 August 2026                 [Page 8]


name: draft-sz-dmsc-iaip
rev: 00
title: Intent-based Agent Interconnection Protocol at Agent Gateway
time: 2026-02-10T02:50:13Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-14T02:50:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.870734+00:00
source: ietf
abstract:
  This document specifies the Intent-based Agent Interconnection
     Protocol (IAIP) operating at the Agent Gateways (AG), which defines
     the interaction mechanisms between AI Agents (at the Agent Domain)
     and the AG (at the Interconnection Services Domain).  This
     specification focuses on dynamic interconnection among agents based
     on semantic intent, rather than static network addressing alone.
     This protocols defines the mechanisms for agent registration via
     capability advertisement, Gateway Validation, Intent Resolution and
     Matching, Routing Decisions and Forwarding, enabling the discovery,
     selection and dispatching of intent queries based on agent
     capabilities and task requirements at AG.

full_text:
  DMSC Working Group                                                S. Sun
  Internet-Draft                                                  ICT, CAS
  Intended status: Standards Track                                X. Zhang
  Expires: 13 August 2026                                        CNIC, CAS
                                                             February 2026


        Intent-based Agent Interconnection Protocol at Agent Gateway
                           draft-sz-dmsc-iaip-00

  Abstract

     This document specifies the Intent-based Agent Interconnection
     Protocol (IAIP) operating at the Agent Gateways (AG), which defines
     the interaction mechanisms between AI Agents (at the Agent Domain)
     and the AG (at the Interconnection Services Domain).  This
     specification focuses on dynamic interconnection among agents based
     on semantic intent, rather than static network addressing alone.
     This protocols defines the mechanisms for agent registration via
     capability advertisement, Gateway Validation, Intent Resolution and
     Matching, Routing Decisions and Forwarding, enabling the discovery,
     selection and dispatching of intent queries based on agent
     capabilities and task requirements at AG.

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

  Copyright Notice

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






  Sun & Zhang              Expires 13 August 2026                 [Page 1]


  Internet-Draft                    IAIP                     February 2026


     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.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Problem Statement and Use Cases . . . . . . . . . . . . . . .   4
       4.1.  Limitations of Address-Based Static Interconnection . . .   4
       4.2.  Representative Use Case . . . . . . . . . . . . . . . . .   5
     5.  Function Components . . . . . . . . . . . . . . . . . . . . .   6
     6.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     7.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  10
     8.  Protocol Operation and Core Procedures  . . . . . . . . . . .  12
       8.1.  Illustrative Protocol Examples  . . . . . . . . . . . . .  12
         8.1.1.  Example A: Agent Registration (CAP_ADV) . . . . . . .  12
         8.1.2.  Example B: Intent Resolution Flow . . . . . . . . . .  12
         8.1.3.  Example C: Routing Feedback . . . . . . . . . . . . .  13
       8.2.  Agent Access Component (AAC) Operations . . . . . . . . .  13
         8.2.1.  Session Authentication and Integrity  . . . . . . . .  13
         8.2.2.  Ingress Validation  . . . . . . . . . . . . . . . . .  14
       8.3.  Local Capability Registry (LCR) Management  . . . . . . .  14
         8.3.1.  Profile Creation and Updates  . . . . . . . . . . . .  14
         8.3.2.  Lifecycle Maintenance . . . . . . . . . . . . . . . .  14
       8.4.  Intent Forwarding Routing Table (IFR) Decision Logic  . .  14
         8.4.1.  Candidate Retrieval . . . . . . . . . . . . . . . . .  14
         8.4.2.  Constraint-Based Filtering  . . . . . . . . . . . . .  15
         8.4.3.  Semantic Evaluation and Ranking . . . . . . . . . . .  15
         8.4.4.  Selection and Fallback  . . . . . . . . . . . . . . .  15
       8.5.  Forwarding and Loop Prevention  . . . . . . . . . . . . .  15
       8.6.  Reliability and Error Handling  . . . . . . . . . . . . .  15
       8.7.  Protocol Processing procedure at Agent Gateways . . . . .  16
     9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  18
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  18
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     12. Normative References  . . . . . . . . . . . . . . . . . . . .  18
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18







  Sun & Zhang              Expires 13 August 2026                 [Page 2]


  Internet-Draft                    IAIP                     February 2026


  1.  Introduction

     The emergence of agentic networks marks a fundamental shift from
     static, address-based networking to semantic, intent-driven
     interactions.  Autonomous agents powered by advanced artificial
     intelligence models are capable of reasoning, planning, and executing
     tasks on behalf of users or other agents.  Interactions are
     increasingly expressed in terms of high-level objectives or natural
     language intents, rather than predefined service endpoints or static
     interfaces.

     Traditional networking and service discovery mechanisms assume that
     communication targets are identified by fixed addresses, names, or
     service identifiers.  These assumptions no longer hold in agentic
     environments, where the appropriate execution entity for a request
     may depend on semantic interpretation, contextual constraints, and
     dynamic system conditions.  As a result, routing decisions based
     solely on static addressing or preconfigured bindings are
     insufficient to support flexible and scalable agent collaboration.

     Intent-based interconnection addresses this gap by enabling the Agent
     Gateway to resolve and forward requests according to their semantic
     intent, rather than their destination address.  By decoupling request
     dispatch from rigid topology and static identifiers, intent-based
     interconnection allows autonomous agents to be dynamically
     discovered, selected, and invoked based on their advertised
     capabilities.

     This document introduces the Intent-based Agent Interconnection
     Protocol (IAIP) to provide a standardized mechanism for capability-
     based registration and validation, intent-aware discovery and routing
     at AG.  IAIP is designed to operate as an application-layer protocol
     for interconnection service domain, complementing existing transport
     and networking infrastructure without requiring changes to underlying
     transport protocols.

  2.  Conventions

     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 <xref
     target="RFC2119"/>.

  3.  Terminology

     AI Agent  An agent is a software or hardware entity with autonomous





  Sun & Zhang              Expires 13 August 2026                 [Page 3]


  Internet-Draft                    IAIP                     February 2026


        decision-making and execution capabilities, capable of perceiving
        the environment, acquiring contextual information, reasoning, and
        learning.

     Agent Gateway (AG)  A Functional Component in the Interconnection
        Service Domain that possesses the capbilities of agent
        registration, capbility authentication, intent resolution and
        estabilishing interconnection betweens agents.

     Intent  A declarative expression of a desired outcome.  In the
        intent-driven routing protocol, intent is represented at three
        conceptual layers:

        *  *Human Intent:*A high-level, possibly ambiguous expression
           originating from a human user or application (e.g., natural
           language input).  Human Intent is out of scope for the
           protocol.

        *  *Task Intent:*An abstract, task-oriented description that
           captures the objective of a request, independent of any
           specific agent, algorithm, or execution plan.

        *  *Intent Descriptor:*A structured, machine-interpretable
           representation of Task Intent used within IAIP for routing and
           dispatching decisions.

     Leader Agent (LA)  Agent who issues tasks and launches interactions.
        There should only be one Leader Agent in a complete task execution
        process.

     Partner Agent (PA)  Agent who accepts tasks and provides services.
        After Partner Agent receives a task from the Leader Agent, it
        executes and returns the execution result.

  4.  Problem Statement and Use Cases

  4.1.  Limitations of Address-Based Static Interconnection

     Existing network interconnection and gateway mechanisms are
     predominantly organized around static identifiers, such as network
     addresses, domain names, or service labels.  At the application and
     service-dispatch layer, these mechanisms assume that the
     functionality associated with a agent behind a gateway is stable,
     explicitly addressable and functionally static.  While effective for
     traditional client-server and microservice architectures, this
     assumption becomes increasingly inadequate for the dynamic
     interconnection required by agentic networks.




  Sun & Zhang              Expires 13 August 2026                 [Page 4]


  Internet-Draft                    IAIP                     February 2026


     First, traditional interconnection protocols provide limited support
     for expressing semantic intent.  High-level requests such as "analyze
     this dataset" or "resolve a billing issue" do not naturally
     correspond to a single predefined endpoint.  Encoding semantic
     meaning into static addresses or service names requires manual
     configuration and tight coupling between task requesters and service
     providers, which undermines flexibility and scalability.

     Second, static interconnection lacks adaptability to dynamic
     lifecycle of AI Agents.  In the Agent Domain, agents may be
     instantiated, fine-tuned, or deprecated rapidly based on
     computational load or task requirements.  Static bindings or name-
     based resolution mechanisms are generally unable to reflect real-time
     changes in agent's availability or intent-processing capacity,
     leading to service selection or routing dispatch failures.

     Third, existing protocols offer limited support for intent-aware
     resolution.  When a request arrives at the gateway without a specific
     destination address, traditional gateway have no mechanism to parse
     the intent and match it against a local registry of vector-based
     capabilities.  This behavior is misaligned with agentic workflows,
     where ambiguous or underspecified intents are common and may require
     clarification, delegation, or escalation to more generalist agents.

     These limitations motivate the need for an intent-driven
     interconnection protocol specifically at the Agent Gateway that can
     manage registration and routing based on semantic intent and
     dynamically advertised capabilities, rather than relying solely on
     fixed addresses or static identifiers.  This protocol addresses these
     challenges by transforming the gateway from a static packet forwarder
     into a semantic ingress/egress point, enabling establishing agent
     interconnection while maintaining compatibility with the
     Interconnection Service Domain.

  4.2.  Representative Use Case

     The following example illustrates a typical use case of the Intent-
     based Agent Interconnection Protocol operating at the Agent Gateway.

     A Customer Service Dispatcher Agent, acting as the Leader Agent,
     transmits a user inquiry to the AG for intent resolution and service
     response.  Specialized Partner Agents (Billing, Technical Support,
     Sales) have previously registered their specific semantic domains
     with the AG.  For explicit queries like "My credit card was charged
     twice," the AG identifies a high-confidence semantic match and routes
     the request to the Billing Agent.  Upon completion, the AG relays the
     result back to the Leader Agent.  Conversely, when handling ambiguous
     inputs (e.g., "I'm having a bad experience") where semantic



  Sun & Zhang              Expires 13 August 2026                 [Page 5]


  Internet-Draft                    IAIP                     February 2026


     similarity scores fail to meet the required confidence threshold, the
     AG encapsulates the intent and forwards the intent to a Generalist
     Fallback Agent.  This mechanism ensures the request is constructively
     resolved via clarifying questions or human escalation, thereby
     preventing service failure.

  5.  Function Components

     Figure 1 illustrates the interaction diagram between AI agent and
     Agent Gateway.

    [Agent Domain]                [Interconnection Service Domain]
       +-----------+      IAIP       +---------------+
       |  AI Agent | <-------------> | Agent Gateway | <---> [Core Router]
       +-----------+                 +---------------+

       Figure 1: Interaction Diagram between AI Agent and Agent Gateway

     To support the interaction with AI Agents, the AG MUST implement the
     following specific Functional Components within the Interconnection
     Service Domain.

     *  *Local Capability Registry (LCR):*The LCR maintains a dynamic
        database of attached Agents.  The function of LCR is to store the
        Capability Profile of each registered agent.  When an Agent sends
        the capability updating request, the LCR updates the mapping.

     *  *Agent Access Component (AAC):*The AAC serves as the termination
        point for the interconnection session between the AI Agent and the
        Agent Gateway.  The function of AAC is to manage authentication,
        maintain session lifecycle, and verify message integrity.  When an
        AI Agent initiates a connection or transmits a message, the AAC
        validates the agent's identity credentials and establishes the
        interconnection for message forwarding.

     *  *Intent Forwarding Routing (IFR):*The IFR serves as the dynamic
        routing decision engine within the Agent Gateway for forwarding
        intent-based requests.  Its primary function is to map normalized
        intent vectors-derived from incoming task semantics-to a set of
        eligible Partner agents.  Based on real-time capability matching
        scores, performance metrics (e.g., latency, success rate, and
        resource availability), and policy constraints, the IFR selects
        the optimal next-hop Partner agent for request forwarding.

  6.  Protocol Overview

     The protocol functions in two primary phases.




  Sun & Zhang              Expires 13 August 2026                 [Page 6]


  Internet-Draft                    IAIP                     February 2026


     *  *Phase 1: Agent Registration & Capability Advertisement.*This
        phase establishes the trust domain and service mesh.  Both Leader
        Agents and Partner Agents MUST complete Identity Registration with
        the Agent Gateway (AG) to obtain the verifiable Agent Identity
        Code (AIC).  Following identity registration, Partner Agents (or
        agents acting in a service-provisioning role) MUST additionally
        perform Capability Advertisement to publish their functional
        profiles to the Local Capability Registry (LCR).

     *  *Phase 2: Intent-based Routing and Forwarding.*This phase
        establishes intent-based interconnection.  The Leader Agent
        submits its intent.  The AG resolves it against the LCR and IFR,
        selects suitable Partner Agents, and facilitates the connection.

     Figure 2 illustrates the updated two-stage processing pipeline
     between AI Agents and AG.



































  Sun & Zhang              Expires 13 August 2026                 [Page 7]


  Internet-Draft                    IAIP                     February 2026


    +--------------+      +------------------------+      +--------------+
    | Leader Agent |      |     Agent Gateway      |      | Partner Agent|
    |(Intent Init.)|      |(Interconnection Domain)|      |(Intent Exec.)|
    +------+-------+      +-----------+------------+      +-------+------+
           |                          |                           |
           |   Phase 1: Registration & Capability Advertisement   |
           |                          |                           |
           |--(1) Identity Reg ------>|                           |
           |      [ACP-IF-01]         |<------(1) Identity Reg ---|
           |                          |         [ACP-IF-01]       |
           |                          |                           |
           |                          |<------(2) Publish Cap ----|
           |                          |         [ACP-IF-06]       |
           |                          |                           |
           |                          |---(3) Sync to ADMgF ------|
           |                          |---(4) Trust Check (DTMgF)-|
           |                          |                           |
           |       Phase 2: Intent-based Routing & Execution      |
           |                          |                           |
           |--(5) Submit Intent ----->|                           |
           |      [Signed Vector]     |                           |
           |                          |---(6) Resolve Intent -----|
           |                          |       Match & Filter      |
           |                          |                           |
           |<-----(7) Cand. List -----|                           |
           |      [Ranked + Sig]      |                           |
           |                          |                           |
           |-(8) Verify & Select -----|                           |
           |                          |                           |
           |==========(9) Routing and Execution =================>|
           |          [E2E via ACP-IF-08/09]                      |
           |======================================================|

                 Figure 2: Two-Stage Processing Flow of IAIP

     *Phase 1: Agent Registration & Capability Advertisement*

     This stage is the prerequisite for any agent participation.  It
     involves Identity Registration (mandatory for all) and Capability
     Publication (mandatory for service providers).  The steps are as
     follows:










  Sun & Zhang              Expires 13 August 2026                 [Page 8]


  Internet-Draft                    IAIP                     February 2026


     *  *Step1:*Identity Registration (Leader & Partner).  Any Agent
        (whether Leader or Partner) MUST register its identity with the
        Agent Gateway using the ACP-IF-01 interface (between AIMF in the
        agent and AIMgF in the AG).  This establishes a verifiable Agent
        Identity Code (AIC) and exchanges cryptographic credentials
        required for future intent signing (Leader) or service execution
        (Partner).

     *  *Step2:*Capability Publication (Partner Agent).  The Partner Agent
        publishes a structured capability description (e.g., supported
        task types, performance bounds, resource constraints) to the Agent
        Gateway via the ACP-IF-06 interface (ADMF <-> ADMgF).  Note: If a
        Leader Agent also wishes to serve tasks, it MUST also perform this
        step.

     *  *Step3:*Synchronization to Interconnection Service Domain.  The
        Agent Gateway forwards the capability description to the Agent
        Description Management Function (ADMgF) in the Interconnection
        Service Domain.  ADMgF persists the data and synchronizes it to
        the Agent Discovery Function (ADF) for indexing.

     *  *Step4:*Trust Scope Enforcement.  The Domain Trust Management
        Function (DTMgF) applies domain federation policies to determine
        whether the registered Agent is authorized to operate within the
        specific trust domain.  Only authorized capabilities are made
        queryable via ADF.

     *Phase 2: Intent-based Routing and Forwarding*

     This stage is triggered when a registered Leader Agent submits a
     semantic intent request.  The Agent Gateway resolves and routes the
     intent to eligible Partner Agents.  The steps are as follows:

     *  *Step5:*Intent Submission.  The Leader Agent sends a signed
        semantic intent vector to the Agent Gateway.  The signature MUST
        be generated using the credentials established in Step 1.  The
        payload contains abstract task semantics.

     *  *Step6:*Intent Resolution and Candidate Matching.  The Agent
        Gateway invokes the ACP-IF-07 interface to query the ADF.  The IFR
        (Intent Forwarding Routing Table) performs semantic matching
        against the LCR, filtering based on trust scopes, and ranking
        candidates.

     *  *Step7:*Candidate Agents Return.  The Gateway returns a ranked
        list of eligible Partner Agents to the Leader Agent.





  Sun & Zhang              Expires 13 August 2026                 [Page 9]


  Internet-Draft                    IAIP                     February 2026


     *  *Step8:*Leader-side Verification and Selection.  The Leader Agent
        verifies the gateway's signature and selects one or more Partners
        based on local policy.

     *  *Step9:*Routing and Execution.  The Leader Agent establishes a
        direct end-to-end session with the selected Partner Agent(s) using
        ACP-IF-08 for point-to-point interaction, or ACP-IF-09 for
        grouping-mode collaboration.  All task payloads are transmitted
        over this encrypted channel.

  7.  Message Formats

     This section specifies the binary structure of IAIP messages.  The
     protocol uses a Type-Length-Value (TLV) design to ensure
     extensibility.

    +--------------------------------------------------------------------+
    |                      IAIP Message (TLV-based)                      |
    +--------------------------------------------------------------------+
    |                                                                    |
    |  +-------------------+------+-----------------------------------+  |
    |  | Type              | Len  | Value                             |  |
    |  +-------------------+------+-----------------------------------+  |
    |  | Common Header TLVs                                           |  |
    |  +-------------------+------+-----------------------------------+  |
    |  | VERSION           | 1    | Protocol version                  |  |
    |  | MSG_TYPE          | 1    | INTENT_REQ / CAP_ADV / ERROR      |  |
    |  | MSG_ID            | var  | Unique message identifier         |  |
    |  | SENDER_ID         | var  | Source agent / router ID          |  |
    |  | RECEIVER_ID       | var  | Target agent / router ID          |  |
    |  | TIMESTAMP         | 8    | Unix time / logical time          |  |
    |  | TTL / EXPIRY      | 4    | Validity / hop limit              |  |
    |  | CORRELATION_ID    | var  | Request-response correlation      |  |
    |  | INTEGRITY_TAG     | var  | MAC / signature                   |  |
    |  +-------------------+------+-----------------------------------+  |
    |                                                                    |
    |  +-------------------+------+-----------------------------------+  |
    |  | Payload TLVs (depend on MSG_TYPE)                            |  |
    |  +-------------------+------+-----------------------------------+  |
    |                                                                    |
    |  -- CAPABILITY ADVERTISEMENT (CAP_ADV) --------------------------  |
    |  | AGENT_ID          | var  | Advertising agent identifier      |  |
    |  | ENDPOINT          | var  | Network / logical endpoint        |  |
    |  | FUNC_DESC         | var  | Functional descriptors            |  |
    |  | INTENT_DOMAINS    | var  | Supported intent types            |  |
    |  | IO_SCHEMA         | var  | Input/output constraints          |  |
    |  | PERF_METRICS      | var  | Latency, success rate, etc.       |  |
    |  | RESOURCE_LIMITS   | var  | Token / compute budget            |  |



  Sun & Zhang              Expires 13 August 2026                [Page 10]


  Internet-Draft                    IAIP                     February 2026


    |                                                                    |
    |  -- CAPABILITY REFRESH (CAP_REFRESH) ----------------------------  |
    |  | AGENT_ID          | var  | Agent identifier                  |  |
    |  | TTL_UPDATE        | 4    | Extended lifetime                 |  |
    |  | METRIC_DELTA      | var  | Updated performance metrics       |  |
    |                                                                    |
    |  -- CAPABILITY DEREGISTER (CAP_DEREGISTER) ----------------------  |
    |  | AGENT_ID          | var  | Agent identifier                  |  |
    |  | REASON_CODE       | 2    | Deregistration reason             |  |
    |  | EFFECTIVE_TIME    | 8    | Time of effect                    |  |
    |                                                                    |
    |  -- INTENT REQUEST (INTENT_REQ) ---------------------------------  |
    |  | OBJECTIVE         | var  | Task objective                    |  |
    |  | CONSTRAINTS       | var  | Preferences / limits              |  |
    |  | CONTEXT           | var  | Context metadata                  |  |
    |  | PRIORITY          | 1    | Request priority                  |  |
    |  | BUDGET            | var  | Cost / token budget               |  |
    |  | PRIVACY_FLAG      | 1    | Intent privacy level              |  |
    |  | OBFUSCATED_INTENT | var  | Encrypted / masked intent         |  |
    |                                                                    |
    |  -- ROUTE DECISION / INTENT RESPONSE ----------------------------  |
    |  | TARGET_AGENT_LIST | var  | Selected target agent(s)          |  |
    |  | MATCH_CONFIDENCE  | var  | Similarity / rank score           |  |
    |  | FORWARDING_INFO   | var  | Next-hop / endpoint               |  |
    |  | FALLBACK_INDIC.   | 1    | Fallback used?                    |  |
    |                                                                    |
    |  -- ROUTING FEEDBACK --------------------------------------------  |
    |  | OUTCOME           | 1    | Success / failure                 |  |
    |  | OBSERVED_LATENCY  | var  | Execution latency                 |  |
    |  | OBSERVED_COST     | var  | Resource usage                    |  |
    |  | ERROR_INFO        | var  | Error details                     |  |
    |                                                                    |
    |  -- ERROR MESSAGE -----------------------------------------------  |
    |  | ERROR_CODE        | 2    | Error identifier                  |  |
    |  | DIAGNOSTIC        | var  | Human-readable info               |  |
    |  | RETRY_AFTER       | 4    | Backoff hint                      |  |
    |                                                                    |
    |  -- SECURITY EXTENSION (SECURITY_EXT) ---------------------------  |
    |  | AUTHN_INFO        | var  | Certificate / token ref           |  |
    |  | AUTHZ_SCOPE       | var  | Authorization scope               |  |
    |  | NONCE             | var  | Anti-replay                       |  |
    |  | SIGNATURE / MAC   | var  | Integrity protection              |  |
    |  | ENCRYPTION_CTX    | var  | Intent confidentiality ctx        |  |
    |                                                                    |
    +--------------------------------------------------------------------+

                        Figure 3: IAIP message format




  Sun & Zhang              Expires 13 August 2026                [Page 11]


  Internet-Draft                    IAIP                     February 2026


     The table above summarizes the field requirements.  Key fields
     include:

     *MSG_TYPE*  Identifies the payload type (e.g., 0x01: CAP_ADV, 0x02:
        INTENT_REQ).

     *TTL / EXPIRY*  Time-To-Live logic depending on message type.  For
        routing messages (INTENT_REQ), this represents the hop limit.  For
        registration messages, this represents the validity duration in
        seconds.

     *OBJECTIVE (in INTENT_REQ)*  The semantic vector or structured
        description of the task.

     *RESOURCE_LIMITS (in CAP_ADV)*  Specifies operational constraints,
        including token budget per request and computational cost.

     *FALLBACK_INDIC. (in RESPONSE)*  Flag indicating if a generalist
        fallback agent was used (0x01) or a direct match was found (0x00).

  8.  Protocol Operation and Core Procedures

     This section specifies the normative processing behavior of the Agent
     Gateway (AG), organized by the functional components defined in
     Section 5.  The Agent Access Component (AAC) handles ingress
     connectivity and security; the Local Capability Registry (LCR)
     manages state; and the Intent Forwarding Routing Table (IFR) executes
     decision logic.

  8.1.  Illustrative Protocol Examples

     The examples in this section are provided for illustration only and
     are non-normative.

  8.1.1.  Example A: Agent Registration (CAP_ADV)

     A Partner Agent registers its translation service with cost
     constraints.

  [Common Header] MSG_TYPE =
            CAP_ADV SENDER_ID = "agent-trans-01", TTL/EXPIRY = 3600 [Payload],
            FUNC_DESC = "service:translation; lang:en-to-zh", RESOURCE_LIMITS =
            "max_tokens=2048", SECURITY_EXT = "(signature bytes...)"

  8.1.2.  Example B: Intent Resolution Flow

     *Step 1: Leader Agent sends Intent Request*




  Sun & Zhang              Expires 13 August 2026                [Page 12]


  Internet-Draft                    IAIP                     February 2026


  [Common Header] MSG_TYPE =
            INTENT_REQ SENDER_ID = "leader-agent-007", MSG_ID = "req-1024"
            [Payload], OBJECTIVE = "(vector: [0.12, 0.95, ...])", BUDGET =
            "100"

     *Step 2: Gateway returns Candidate List (Response)*
     The AG finds two matching agents.  The first one is a direct match,
     so Fallback Indicator is 0.

  [Common Header] MSG_TYPE =
            RESPONSE RECEIVER_ID = "leader-agent-007", CORRELATION_ID =
            "req-1024" [Payload], TARGET_AGENT_LIST = [1] "agent-trans-01"
            (Conf: 0.92, Endpoint: "10.0.1.5:8080"), [2] "agent-trans-03" (Conf:
            0.85, Endpoint: "10.0.1.8:8080"), FALLBACK_INDIC. = 0x00 (No
            Fallback)

  8.1.3.  Example C: Routing Feedback

     After execution, the Leader Agent reports performance metrics back to
     the AG to update the LCR's dynamic scores.

  [Common Header] MSG_TYPE =
            ROUTING_FEEDBACK SENDER_ID = "leader-agent-007" [Payload], OUTCOME =
            1 (Success), OBSERVED_LATENCY = 250 (ms), OBSERVED_COST = 50
            (tokens)

  8.2.  Agent Access Component (AAC) Operations

     The AAC serves as the termination point for the interconnection
     session.  It MUST intercept all incoming IAIP messages before they
     reach the LCR or IFR.

  8.2.1.  Session Authentication and Integrity

     Upon receiving any message, the AAC MUST perform the following
     validations:

     *  *Identity Verification:* Validate the SENDER_ID against the
        credentials provided in the AUTHN_INFO TLV or the underlying
        transport session (e.g., mTLS).
     *  *Message Integrity:* Verify the INTEGRITY_TAG or SIGNATURE.  If
        verification fails, the AAC MUST drop the message and return an
        ERROR with code AUTH_FAILED.








  Sun & Zhang              Expires 13 August 2026                [Page 13]


  Internet-Draft                    IAIP                     February 2026


  8.2.2.  Ingress Validation

     The AAC acts as the first line of defense.  It MUST validate the
     syntax of Common Header fields (e.g., VERSION, MSG_TYPE).  Malformed
     packets MUST be rejected immediately to protect the internal IFR
     engine.

  8.3.  Local Capability Registry (LCR) Management

     The LCR maintains the dynamic database of attached Agents.  It
     processes capability management messages validated by the AAC.

  8.3.1.  Profile Creation and Updates

     When the AAC forwards a CAP_ADV message, the LCR MUST:

     1.  Extract the AGENT_ID and map it to the provided ENDPOINT.

     2.  Store the FUNC_DESC, INTENT_DOMAINS, and RESOURCE_LIMITS as the
         agent's Capability Profile.

     3.  Set the entry's expiration time to Current_Time + TTL.

  8.3.2.  Lifecycle Maintenance

     Upon receiving a CAP_REFRESH, the LCR MUST look up the existing
     profile and extend its validity by TTL_UPDATE.

     The LCR MUST periodically purge entries that have exceeded their
     expiry time without refresh (STALE state) to ensure the IFR does not
     route to dead agents.

  8.4.  Intent Forwarding Routing Table (IFR) Decision Logic

     The Intent Forwarding Routing Table (IFR) functions as the dynamic
     routing engine of the Agent Gateway.  After an INTENT_REQ
     successfully passes AAC validation, the IFR MUST evaluate the request
     and produce a ranked TARGET_AGENT_LIST containing one or more
     eligible Partner Agents.

  8.4.1.  Candidate Retrieval

     The IFR MUST interpret the OBJECTIVE TLV as an intent descriptor and
     query the Local Capability Registry (LCR) to obtain the current set
     of active Capability Profiles.






  Sun & Zhang              Expires 13 August 2026                [Page 14]


  Internet-Draft                    IAIP                     February 2026


  8.4.2.  Constraint-Based Filtering

     The IFR MUST apply mandatory constraints to reduce the candidate set
     prior to semantic evaluation.  When a request includes constraint
     fields such as BUDGET, the IFR MUST compare these constraints against
     the corresponding attributes in the Capability Profiles (e.g.,
     RESOURCE_LIMITS) and exclude agents that do not satisfy the required
     conditions.

     Additional policy-based constraints MAY be applied according to local
     administrative policy.

  8.4.3.  Semantic Evaluation and Ranking

     For the remaining candidates, the IFR MUST perform semantic matching
     between the request intent and the advertised capabilities.  The
     specific matching method is implementation-dependent; however, the
     IFR MUST compute a relative confidence score that reflects the degree
     of intent-capability alignment.

     The IFR MAY incorporate additional operational signals, such as
     historical performance metrics (e.g., latency or success rate), when
     deriving the final ranking.

     The IFR MUST preserve the relative ordering of candidates when
     constructing the TARGET_AGENT_LIST.

  8.4.4.  Selection and Fallback

     The IFR SHOULD select the highest-ranked candidates for inclusion in
     the response, subject to local policy.

     If no candidate satisfies the acceptance criteria (e.g., minimum
     confidence threshold), the IFR SHOULD invoke the Fallback Mechanism.
     When fallback is applied, the Agent Gateway MUST set FALLBACK_INDIC
     to 0x01.

  8.5.  Forwarding and Loop Prevention

     For multi-hop scenarios, the AG enforces loop prevention using the
     TTL field in the Common Header.  If TTL <= 1, the request is dropped.
     Duplicate MSG_ID, are suppressed to prevent broadcast storms.

  8.6.  Reliability and Error Handling

     Errors detected by any component (AAC auth failure, LCR parsing
     error, IFR no-route) MUST result in an ERROR message returned to the
     sender, containing the appropriate ERROR_CODE.



  Sun & Zhang              Expires 13 August 2026                [Page 15]


  Internet-Draft                    IAIP                     February 2026


  8.7.  Protocol Processing procedure at Agent Gateways

     Figure 3 illustrates the protocol processing pipeline within the
     Agent Gateway (AG).  The protocol operation relies on the
     coordination between three normative functional components: the Agent
     Access Component (AAC), the Local Capability Registry (LCR), and the
     Intent Forwarding Routing Table (IFR).

     The process begins when a Partner Agent transmits a capability
     advertisement (CAP_ADV) [Section 8.1.1].

     *Ingress Validation:* The AAC [Section 8.2] intercepts the message to
     perform session authentication and integrity verification.

     *Registry Update:*Upon successful validation, the AAC forwards the
     payload to the LCR [Section 8.3].  The LCR parses the functional
     descriptors and updates its internal database, mapping the agent's
     semantic profile to its network endpoint.

     The routing process is triggered when a Leader Agent submits an
     intent request (INTENT_REQ) [Section 8.1.2].

     *Ingress Validation:*The AAC validates the request format and the
     sender's authorization scope.

     *Routing Decision:*Validated requests are passed to the IFR
     [Section 8.4], which executes the core decision logic:

     *  *Candidate Retrieval:*The IFR queries the LCR [Section 8.4.1] to
        retrieve active agents capable of satisfying the intent objective.

     *  *Filtering:*Mandatory constraints (e.g., budget, latency) are
        applied to prune ineligible candidates [Section 8.4.2].

     *  *Ranking:*The IFR performs semantic evaluation [Section 8.4.3] to
        assign confidence scores to the remaining candidates.

     *  *Selection:*The eligible partner agents are selected based on
        local policy and fallback mechanisms [Section 8.4.4].

     *Egress Processing:*The partner agent list is passed to the
     Forwarding module [Section 8.5].  This module enforces Time-To-Live
     (TTL) checks and duplicate suppression to prevent routing loops
     before dispatching the forwarded request to the Partner Agent.







  Sun & Zhang              Expires 13 August 2026                [Page 16]


  Internet-Draft                    IAIP                     February 2026


         +--------------+                  +--------------+
         | Leader Agent |                  | Partner Agent|
         | (Source/App) |                  | (Target/Phy) |
         +-------+------+                  +-------+------+
                 | (2) Intent Req                  | (1) CAP_ADV
                 | [Sec 8.1.2]                     | [Sec 8.1.1]
                 v                                 v
     +------------------------------------------------------------------+
     |              Agent Gateway (Interconnection Domain)              |
     |------------------------------------------------------------------|
     |                                                                  |
     | +--------------+        (CAP_ADV)         +--------------------+ |
     | | Agent Access |------------------------->|  Local Capability  | |
     | |  Comp (AAC)  |                          |   Registry (LCR)   | |
     | |  [Sec 8.2]   |                          |     [Sec 8.3]      | |
     | +------+-------+                          +---------+----------+ |
     |        |                                            ^            |
     |        | (INTENT_REQ)                               | Candidate  |
     |        v                                            | Retrieval  |
     | +---------------------------------------------------+----------+ |
     | |      Intent Forwarding Routing (IFR) [Sec 8.4]               | |
     | |--------------------------------------------------------------| |
     | | 1. Candidate Retrieval (Query LCR) [Sec 8.4.1] --------------+ |
     | | 2. Constraint Filtering [Sec 8.4.2]                          | |
     | | 3. Semantic Eval & Ranking [Sec 8.4.3]                       | |
     | | 4. Selection & Fallback [Sec 8.4.4]                          | |
     | +------+-------------------------------------------------------+ |
     |        | Selected Target List                                    |
     |        v                                                         |
     | +----------------------+                                         |
     | |  Forwarding & Loop   |                                         |
     | | Prevention [Sec 8.5] |                                         |
     | +------+---------------+                                         |
     |        |                                                         |
     +--------+---------------------------------------------------------+
              | (3) Forwarded Request
              v
       +-------------+
       | Partner Agt |
       | (Execution) |
       +-------------+

           Figure 4: Protocol Processing procedure at Agent Gateways








  Sun & Zhang              Expires 13 August 2026                [Page 17]


  Internet-Draft                    IAIP                     February 2026


  9.  Conclusions

     This document specifies the functional components, protocol
     procedures, and message formats of the Intent-based Agent
     Interconnection Protocol (IAIP).  It defines the mechanisms for
     capability-aware registration, semantic intent resolution, and
     dynamic routing.  By abstracting the complexity of agent discovery
     and intent matching, IAIP ensures scalable and adaptive collaboration
     across heterogeneous agent systems.

  10.  Security Considerations

     This document focuses on the Intent-based Agent Interconnection
     Protocol at the Agent Gateway for inter-agent collaboration in the
     Internet of Agents (IoA).  Security of the IoA ecosystem is not
     detailed in this document.  Security considerations relevant to
     cross-domain intent routing, capability advertisement integrity,
     trust federation among multiple agent service providers, and end-to-
     end confidentiality of agent interactions are suggested to be deeply
     discussed through other proposals.

  11.  IANA Considerations

     TBD

  12.  Normative References

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

  Authors' Addresses

     Sheng Sun
     ICT, CAS
     Email: sunsheng@ict.ac.cn


     Xinyi Zhang
     CNIC, CAS
     Email: xyzhang@cnic.cn










  Sun & Zhang              Expires 13 August 2026                [Page 18]


name: draft-jia-oauth-scope-aggregation
rev: 00
title: OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows
time: 2026-02-10T11:39:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-14T11:39:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:20.876092+00:00
source: ietf
abstract:
  This document describes a scope-aggregated OAuth 2.0 authorization
     pattern for multi-step AI agent workflows.  An AI agent aggregates
     the scopes required across a workflow and only initiates a single
     authorization procedure for the aggregated scope.  This reduces
     repeated user consents and multiple authorization round-trips,
     improving authorization efficiency.

full_text:
  Web Authorization Protocol                                        Y. Jia
  Internet-Draft                                                   S. Peng
  Intended status: Standards Track                                  Huawei
  Expires: 14 August 2026                                 10 February 2026


       OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows
                    draft-jia-oauth-scope-aggregation-00

  Abstract

     This document describes a scope-aggregated OAuth 2.0 authorization
     pattern for multi-step AI agent workflows.  An AI agent aggregates
     the scopes required across a workflow and only initiates a single
     authorization procedure for the aggregated scope.  This reduces
     repeated user consents and multiple authorization round-trips,
     improving authorization efficiency.

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



  Jia & Peng               Expires 14 August 2026                 [Page 1]


  Internet-Draft           OAuth Scope Aggregation           February 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Security Member in Resource Metadata  . . . . . . . . . . . .   5
       3.1.  Comparison to Existing Practice . . . . . . . . . . . . .   6
       3.2.  Backward Compatibility  . . . . . . . . . . . . . . . . .   6
     4.  Workflow Execution with OAuth Scope Aggregation . . . . . . .   7
     5.  Advantages  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Reduced Consent Interactions and End-to-End Latency . . .   9
       5.2.  Avoidance of Mid-Flow Failures due to Insufficient
             Privileges  . . . . . . . . . . . . . . . . . . . . . . .  10
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
       7.1.  Risk: Residual Privilege  . . . . . . . . . . . . . . . .  11
       7.2.  Risk: User Blind Signing  . . . . . . . . . . . . . . . .  11
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
     Appendix A.  Example of a Resource List . . . . . . . . . . . . .  13
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

  1.  Introduction

     Recent advances in large language models (LLMs) enable AI agents to
     plan and execute multi-step workflows for complex tasks.  With agent
     communication protocols, AI agents can call third-party tools and
     delegate tasks to other AI agents.  When an AI agent is acting on
     behalf of a human user, these interoperations should require
     authentication and authorization.

     The OAuth 2.0 authorization framework [RFC6749] has been a widely
     preferred method for granting an AI agent access to protected
     resources in existing agent communication protocols.  Acting as an
     OAuth client, an AI agent must present a valid access token with
     appropriate scopes for each request to access a protected resource.
     If the token is missing or lacks the required scope, the resource
     server will reject the request with an HTTP 401/403 error response.
     The agent is then expected to perform authorization server discovery
     and initiate an OAuth flow to obtain an access token as shown in
     Figure 1, involving end user authentication and consent.  This
     challenge-triggered flow repeats for each scope deficiency when an AI
     agent workflow spans across multiple protected resources, causing
     user fatigue and increased end-to-end latency.




  Jia & Peng               Expires 14 August 2026                 [Page 2]


  Internet-Draft           OAuth Scope Aggregation           February 2026


                                       .-------------------------.
                                       |  Authorization Domain   |
                                       |                         |
                                       |    +-----------------+  |
       +--------+                      |    |                 |  |
       |        |---(a) Auth request---+--->|                 |  |
       |        |                      |    |                 |  |
       |  End   |---(b) User consent---+--->|  Authorization  |  |
       |  User  |                      |    |     Server      |  |
       |        |<--(c) Auth code------+----|                 |  |
       |        |                      |    |                 |  |
       +--------+                      |    +-----------------+  |
         ^    |                        |          ^      |       |
     (a) |    | (c)                    |          |      |       |
     Auth|    | Auth                   |          |      |       |
     Req |    | Code  .-----(d) Token Exchange----'      |       |
         |    |       |                |                 |       |
         |    v       |                |                 |       |
       +--------+     |  .--(e) Access Token-------------'       |
       |        |-----'  |             |                         |
       |        |        |             |    +-----------------+  |
       |  AI    |<-------'             |    | Resource Server |  |
       | Agent  |                      |    |                 |  |
       |        |---(f) Request w/ Token--->| +-------------+ |  |
       |        |                      |    | |   Resource  | |  |
       |        |<--(g) Response-------+----| |   Metadata  | |  |
       +--------+                      |    | +-------------+ |  |
                                       |    | +-----+ +-----+ |  |
                                       |    | |Tool | |Tool | |  |
                                       |    | | A1  | | A2  | |  |
                                       |    | +-----+ +-----+ |  |
                                       |    +-----------------+  |
                                       '-------------------------'

              Figure 1: OAuth 2.0 authorization flow for AI agents

     This document defines an authorization domain as a logical grouping
     of the scopes authorizable by a single trust anchor (e.g., an OAuth
     2.0 authorization server).  Within this domain, an AI agent can
     request multiple scopes (e.g., email:read, calendar:write) that share
     a common user identity and consent context.  Given a multi-step
     workflow, an AI agent first computes the minimal aggregation of the
     required scopes within each authorization domain.  Subsequently, the
     agent performs authorization server discovery and initiates a scope-
     aggregated authorization flow to obtain the access token.  This
     approach reduces repeated user consent and multiple authorization
     round-trips while preserving least privilege.




  Jia & Peng               Expires 14 August 2026                 [Page 3]


  Internet-Draft           OAuth Scope Aggregation           February 2026


  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 BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Terminology

     AI Agent
        An entity with built-in intelligence, which can perform actions to
        accomplish tasks, possibly on behalf of an end-user or another
        agent.

     Agent Communication Protocol
        A protocol that defines how an agent discovers and utilizes
        server-exposed resources (e.g., tools, skills, etc.).  For
        example, Model Context Protocol (MCP) protocol [MCP] defines how
        to discover and call tools, and Agent-to-Agent (A2A) protocol
        [A2A] defines how to invoke other AI agents.

     Agent Workflow
        A sequence of steps to accomplish a task, which may be pre-built
        by a human or planned by an agent.  These steps may include access
        to one or more resources on remote resource servers.  An agent
        workflow may be structured as a chain or a tree with parallel
        branches.

     Resource Server (RS)
        An OAuth 2.0 term for the server hosting one or more protected
        resources that require access token for access.  The resources are
        invocable, server-exposed units of functionality.

     Authorization Server (AS)
        An OAuth 2.0 term for the server that issues access tokens to AI
        agent after successfully authenticating the resource owner and
        obtaining consent for authorization.

     Authorization Domain (AD)
        A logical grouping of scopes authorizable by a single trust
        anchor.  For example, scopes like mail.read and calendar.write
        within a single ecosystem belong to the same authorization domain.








  Jia & Peng               Expires 14 August 2026                 [Page 4]


  Internet-Draft           OAuth Scope Aggregation           February 2026


  3.  Security Member in Resource Metadata

     For the purpose of resource discovery, an AI agent obtains resource
     metadata by invoking a protocol method or by retrieving a description
     document from a well-known URI.  Such resources may be referred to as
     "tools" or "skills" in different contexts.  This document extends the
     resource metadata object by defining a security member that MAY be
     included to indicate a resource's authorization requirements.

     The resource metadata is represented in JSON format.  It MUST contain
     the following members:

     name
        A string that provides a unique identifier for the resource.

     description
        A human-readable string that describes the resource.

     input_schema
        A machine-readable schema (e.g., JSON schema) describing the
        parameters required to execute the resource.

     This document defines an OPTIONAL security member within the resource
     metadata.  When present, the security object indicates the
     authorization requirements for the resource and contains the
     following members:

     type
        REQUIRED.  An array of strings specifying one or more supported
        security schemes.  This document defines the value "oauth2" for
        use with the OAuth 2.0 authorization framework.  Other type
        values, such as "apikey", "basic", and "oidc", may also be used.

     scopes
        REQUIRED.  An array of strings specifying the scope values
        required to access the resource.  If this member is present and
        "oauth2" is included in the type array, the AI agent MUST possess
        all listed scopes to gain access.

     as_metadata
        OPTIONAL.  A string containing the URL to the OAuth 2.0
        Authorization Server (AS) metadata [RFC8414].  This allows the
        agent to dynamically discover the authorization endpoints.

     Figure 2 illustrates the structure of the security member within a
     resource definition:





  Jia & Peng               Expires 14 August 2026                 [Page 5]


  Internet-Draft           OAuth Scope Aggregation           February 2026


     {
       "name": "resource_identifier",
       "description": "...",
       "input_schema": { ... },
       "security": {
         "type": ["oauth2"],
         "scopes": ["scope_A"],
         "as_metadata": "https://server.example.com/.well-known/..."
       }
     }

         Figure 2: Structure of Resource Metadata with Security Member

     A comprehensive, non-normative example of a full list of resource
     metadata is provided in Appendix A.

  3.1.  Comparison to Existing Practice

     This document defines a uniform mechanism for advertising per-
     resource authorization requirements, drawing inspiration from and
     addressing gaps in existing protocols.

     Agent-to-Agent (A2A) Protocol [A2A]: The A2A protocol defines
     security scheme objects based on the OpenAPI 3.2 specification.
     OpenAPI includes a security object within its schema that serves a
     purpose analogous to the security member defined here.  It allows an
     API to declare its required security schemes (e.g., OAuth 2.0) and
     the necessary scopes for each operation.  This document aligns with
     that established principle, offering a potentially simplified
     version.

     Model Context Protocol (MCP) [MCP]: The MCP protocol specifies OAuth
     2.1 as the authorization framework.  However, MCP does not
     standardize per-tool scope advertisement in tool metadata.  This can
     lead to reactive, challenge-triggered authorization flows when
     executing an AI agent workflow.  The security member defined in this
     document directly addresses this gap by providing a mechanism for an
     MCP server to advertise these requirements.

  3.2.  Backward Compatibility

     Inclusion of the security member in resource metadata is OPTIONAL.  A
     server SHOULD omit the security member for resources that do not
     require authorization.  To allow for implementation flexibility, a
     server MAY also omit the security member for a protected resource.






  Jia & Peng               Expires 14 August 2026                 [Page 6]


  Internet-Draft           OAuth Scope Aggregation           February 2026


     An AI agent MUST ignore a security member if it does not understand
     the contents.  Furthermore, all agents MUST be able to handle
     authorization reactively (e.g., via a step-up flow) upon receiving an
     authorization error.

     AI agents that recognize and support the security member SHOULD use
     the information it contains to perform proactive and aggregated
     authorization, as described in Section 4.

  4.  Workflow Execution with OAuth Scope Aggregation

     Using the security member in the resource metadata, an AI agent can
     follow the sequence below to execute a workflow:

     1.  Resource Discovery: The AI agent fetches the resource metadata
         from the resource server.  Resource metadata MAY include a
         security member describing the required authentication scheme,
         scopes, and AS metadata URL.

     2.  Authorization Domain Identification: Given a pre-defined or
         planned workflow, the AI agent iterates through each step and
         fetches the associated AS metadata to learn the authorization
         domain and authorization endpoints.

     3.  Scope Aggregation: For each authorization domain, the AI agent
         computes a least-privilege set of scopes required by the
         workflow, using the OPTIONAL security member defined in
         Section 3.  The agent aggregates the required scopes across all
         resource invocations within the same authorization domain and
         removes duplicates.  If, and only if, the authorization domain
         defines a hierarchical relationship among its scopes (e.g., a
         broader scope implies one or more narrower scopes), the agent MAY
         further reduce the requested scope set by removing any scope that
         is subsumed by another requested scope.  For example, within a
         single authorization domain, an agent workflow (1) reads a
         document from the cloud drive with scope "drive.read", (2)
         updates the document with scope "drive.write", and (3) creates
         calendar events with scope "calendar.write".  If the
         authorization domain defines that "drive.write" subsumes
         "drive.read", the aggregated scope set is ["drive.write",
         "calendar.write"].

     4.  Aggregated Scope Authorization: For each authorization domain,
         the AI agent initiates an OAuth 2.0 authorization code grant to
         obtain an access token with the aggregated scopes.  During this
         step, the user is prompted to authorize the requested scopes.





  Jia & Peng               Expires 14 August 2026                 [Page 7]


  Internet-Draft           OAuth Scope Aggregation           February 2026


     5.  Workflow Execution: The AI agent executes the multi-step
         workflow, using the obtained access tokens when accessing
         resources on resource servers.

     This process is illustrated in Figure 3.

   +--------+       +--------+       +---------------+       +-----------+
   |End User|       |AI Agent|       |Resource Server|       |Auth Server|
   +---+----+       +---+----+       +-------+-------+       +-----+-----+
       |                | (1) Get metadata   |                     |
       |                |------------------->|                     |
       |                |                    |                     |
       |                | (1) Res. metadata  |                     |
       |                |< - - - - - - - - - |                     |
       |                |                    |                     |
       |                | (2) Get AS metadata for each AD          |
       |                |----------------------------------------->|
       |                |                    |                     |
       |                | (2) AS metadata    |                     |
       |                |<- - - - - - - - - - - - - - - - - - - - -|
       |                |                    |                     |
       |                |----\               |                     |
       |                |    | (3) Scope aggregation               |
       |                |<---/  within each AD                     |
       |                |                    |                     |
       | (4a) Init auth |                    |                     |
       |<---------------|                    |                     |
       |                |                    |                     |
       |              (4b) User authentication + consent           |
       |---------------------------------------------------------->|
       |                |                    |                     |
       |              (4c) Redirect back to agent                  |
       |< - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
       |                |                    |                     |
       | (4d) Auth code |                    |                     |
       | - - - - - - - >|                    |                     |
       |                | (4e) Token exchange                      |
       |                |----------------------------------------->|
       |                |                    |                     |
       |                | (4f) Access token w/ aggregated scopes   |
       |                |<- - - - - - - - - - - - - - - - - - - - -|
       |                |                    |                     |
       |     +----------+--------------------+---------------+     |
       |     | LOOP: Repeat for each step w/ resource req.   |     |
       |     |-----------------------------------------------|     |
       |     |          |(5) Request resource w/ token       |     |
       |     |          |------------------->|               |     |
       |     |          |                    |               |     |



  Jia & Peng               Expires 14 August 2026                 [Page 8]


  Internet-Draft           OAuth Scope Aggregation           February 2026


       |     |          |(5) Resource responses              |     |
       |     |          |<- - - - - - - - - -|               |     |
       |     +----------+--------------------+---------------+     |
       |                |                    |                     |
   +---+----+       +---+----+       +-------+-------+       +-----+-----+
   |End User|       |AI Agent|       |Resource Server|       |Auth Server|
   +--------+       +--------+       +---------------+       +-----------+

        Figure 3: Sequence diagram of workflow execution with scope-
                          aggregated authorization

  5.  Advantages

     Compared to a reactive, challenge-triggered authorization flow, this
     scope-aggregated authorization strategy offers several benefits for
     multi-step AI agent workflows.

  5.1.  Reduced Consent Interactions and End-to-End Latency

     In the absence of aggregated authorization, the end user is required
     to respond to multiple consent prompts for individual resources
     associated with distinct scopes.  This interaction pattern is
     illustrated in Figure 4.  On the contrary, the mechanism defined in
     this document enables the end user to authorize the AI Agent one
     single time per authorization domain.  This approach mitigates user
     friction and consent fatigue, while simultaneously reducing the end-
     to-end latency of task completion.

   +--------+       +--------+       +---------------+       +-----------+
   |End User|       |AI Agent|       |Resource Server|       |Auth Server|
   +---+----+       +---+----+       +-------+-------+       +-----+-----+
       |                | (1) Get metadata   |                     |
       |                |------------------->|                     |
       |                |                    |                     |
       |                | (1) Res. metadata  |                     |
       |                |< - - - - - - - - - |                     |
       |                |                    |                     |
    +--+----------------+--------------------+---------------------+----+
    | LOOP: Repeat for each request with scope deficiency               |
    |-------------------------------------------------------------------|
    |  |                | (2) Request resource                     |    |
    |  |                |------------------->|                     |    |
    |  |                |                    |                     |    |
    |  |                | (2) Unauthorized error                   |    |
    |  |                |< - - - - - - - - - |                     |    |
    |  |                |                    |                     |    |
    |  |                | (3) Fetch AS metadata                    |    |
    |  |                |----------------------------------------->|    |



  Jia & Peng               Expires 14 August 2026                 [Page 9]


  Internet-Draft           OAuth Scope Aggregation           February 2026


    |  |                |                    |                     |    |
    |  |                | (3) AS metadata    |                     |    |
    |  |                |< - - - - - - - - - - - - - - - - - - - - |    |
    |  |                |                    |                     |    |
    |  | (4a) Init auth |                    |                     |    |
    |  |<---------------|                    |                     |    |
    |  |                |                    |                     |    |
    |  |              (4b) User authentication + consent           |    |
    |  |---------------------------------------------------------->|    |
    |  |                |                    |                     |    |
    |  |              (4c) Redirect back to agent                  |    |
    |  |< - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|    |
    |  |                |                    |                     |    |
    |  | (4d) Auth code |                    |                     |    |
    |  | - - - - - - - >|                    |                     |    |
    |  |                | (4e) Token exchange                      |    |
    |  |                |----------------------------------------->|    |
    |  |                |                    |                     |    |
    |  |                | (4f) Access token w/ requested scopes    |    |
    |  |                |< - - - - - - - - - - - - - - - - - - - - |    |
    |  |                |                    |                     |    |
    |  |                | (5) Request resource w/ access token     |    |
    |  |                |------------------->|                     |    |
    |  |                |                    |                     |    |
    |  |                | (5) Resource responses                   |    |
    |  |                |< - - - - - - - - - |                     |    |
    +--+----------------+--------------------+---------------------+----+
       |                |                    |                     |
   +---+----+       +---+----+       +-------+-------+       +-----+-----+
   |End User|       |AI Agent|       |Resource Server|       |Auth Server|
   +--------+       +--------+       +---------------+       +-----------+

      Figure 4: Sequence diagram of workflow execution without scope-
                          aggregated authorization

  5.2.  Avoidance of Mid-Flow Failures due to Insufficient Privileges

     By computing the required scopes and obtaining tokens in advance, the
     AI agent avoids mid-workflow failures caused by missing privileges.
     This increases the reliability of multi-step workflows, preventing
     partial completion and handling insufficient-scope conditions
     proactively rather than reactively.

  6.  IANA Considerations

     This document includes no request to IANA.





  Jia & Peng               Expires 14 August 2026                [Page 10]


  Internet-Draft           OAuth Scope Aggregation           February 2026


  7.  Security Considerations

     This section summarizes security risks that arise in scope-aggregated
     authorization for multi-step AI agent workflows and describes
     recommended mitigations.  Implementations are RECOMMENDED to apply
     the mechanisms below, as appropriate to their threat model and
     deployment context.

  7.1.  Risk: Residual Privilege

     In a sequential workflow involving Step A, B, and C, the AI agent
     still holds the permissions for Step A while executing Step B and C.
     More critically, after Step C is finished, the agent retains full
     access to Step A, B, and C.

     Mitigation:

     Token Downscoping [RFC8693] : Upon completing a step in the workflow,
     the AI agent SHOULD perform a token exchange request to the
     authorization server to exchange for a new token with a reduced scope
     set.  This reduces the impact of token leakage during later steps.

     Strict Token Revocation [RFC7009] : Upon successful completion or
     terminal failure of the workflow, the AI agent SHOULD immediately
     revoke the access token and any associated refresh tokens.  The
     authorization server SHOULD limit refresh token lifetimes to reduce
     residual privilege.

     Sender-Constrained Tokens [RFC9449] : It is RECOMMENDED to use
     sender-constrained access tokens that bind token use to a proof-of-
     possession (DPoP) key controlled by the AI agent.  This reduces the
     risk that an aggregated token can be intercepted and replayed by a
     different actor.

  7.2.  Risk: User Blind Signing

     When users are presented with a long set of aggregated scopes (e.g.,
     "Read Mail", "Write Files", "Access Calendar", "Post to Slack"), they
     may approve the request without understanding its implications.  This
     can undermine informed consent and increase the likelihood of over-
     authorization.

     Mitigation:








  Jia & Peng               Expires 14 August 2026                [Page 11]


  Internet-Draft           OAuth Scope Aggregation           February 2026


     Structured Consent UI: Authorization Servers SHOULD present requested
     privileges in a structured manner, grouped by workflow step, rather
     than as a flat list of scopes.  Authorization Servers MAY
     additionally require step-level acknowledgment for high-risk
     privileges.

  8.  Acknowledgements

     The authors would like to thank Yiyang Shao and Jinyang Li for useful
     discussion and ideas.

  9.  References

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

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

     [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
                2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
                August 2013, <https://www.rfc-editor.org/info/rfc7009>.

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

     [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
                Authorization Server Metadata", RFC 8414,
                DOI 10.17487/RFC8414, June 2018,
                <https://www.rfc-editor.org/info/rfc8414>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                DOI 10.17487/RFC8693, January 2020,
                <https://www.rfc-editor.org/info/rfc8693>.

     [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
                Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
                Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
                September 2023, <https://www.rfc-editor.org/info/rfc9449>.

  9.2.  Informative References



  Jia & Peng               Expires 14 August 2026                [Page 12]


  Internet-Draft           OAuth Scope Aggregation           February 2026


     [A2A]      Google, "Agent2Agent(A2A) Protocol", 2025,
                <https://a2a-protocol.org/latest>.

     [MCP]      Anthropic, "Model Context Protocol (MCP)", 2025,
                <https://modelcontextprotocol.io/docs/getting-started/
                intro>.

  Appendix A.  Example of a Resource List

     This appendix is non-normative.  Figure 5 shows an example resource
     list for a calendar server.  In this example, both resources belong
     to the same authorization domain.  For a workflow that accesses both
     resources, the AI agent can obtain an access token via OAuth 2.0 with
     the aggregated scope set ["calendar.read", "calendar.write"].  If the
     authorization domain defines that "calendar.write" subsumes
     "calendar.read", the requested scope set can be further reduced to
     ["calendar.write"].


































  Jia & Peng               Expires 14 August 2026                [Page 13]


  Internet-Draft           OAuth Scope Aggregation           February 2026


     [
       {
         "name": "CalendarReader",
         "description": "Read events from the user's calendar",
         "input_schema": {
           "type": "object",
           "properties": {
             "start_date": {
               "type": "string",
               "format": "date-time"
             },
             "end_date": {
               "type": "string",
               "format": "date-time"
             }
           },
           "required": ["start_date"]
         },
         "security": {
           "type": ["oauth2"],
           "scopes": ["calendar.read"],
           "as_metadata": "https://auth.calendar.com/.well-known/
           oauth-authorization-server"
         }
       },
       {
         "name": "CalendarWriter",
         "description": "Create events on the user's calendar",
         "input_schema": {
           "type": "object",
           "properties": {
             "summary": { "type": "string" },
             "start": { "type": "string", "format": "date-time" },
             "end": { "type": "string", "format": "date-time" }
           },
           "required": ["summary", "start", "end"]
         },
         "security": {
           "type": ["oauth2"],
           "scopes": ["calendar.write"],
           "as_metadata": "https://auth.calendar.com/.well-known/
           oauth-authorization-server"
         }
       }
     ]

         Figure 5: An example of the resource list of a calendar server




  Jia & Peng               Expires 14 August 2026                [Page 14]


  Internet-Draft           OAuth Scope Aggregation           February 2026


  Contributors

     The following people contributed significantly to this document:

     Yiyang Shao
     Huawei
     Email: shaoyiyang@huawei.com

     Jinyang Li
     Huawei
     Email: lijinyang9@huawei.com

  Authors' Addresses

     Yukuan Jia
     Huawei
     Huawei Bld., No.156 Beiqing Rd.
     Beijing
     100095
     China
     Email: jiayukuan@huawei.com


     Shuping Peng
     Huawei
     Huawei Bld., No.156 Beiqing Rd.
     Beijing
     100095
     China
     Email: pengshuping@huawei.com





















  Jia & Peng               Expires 14 August 2026                [Page 15]


name: draft-mozleywilliams-dnsop-dnsaid
rev: 00
title: DNS for AI Discovery
time: 2026-02-24T20:46:41Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T20:46:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127491+00:00
source: ietf
abstract:
  This document specifies a method for utilizing the Domain Name System
     (DNS) to facilitate scalable and interoperable discovery between AI
     agents.  The proposed mechanism, referred to as _DNS AI agent
     Discovery_ (DNS-AID), defines a structured DNS namespace and record
     usage model to support metadata exchange and capability
     advertisement.

     This will allow organisations to publish information about their AI
     agents on the Internet or internal networks using a well-known label
     within the organisation’s own DNS namespace.  This document does not
     define how the published agent information is accessed or the exact
     structure of that information.  Instead, it specifies a mechanism for
     indicating which access protocol should be used and what format the
     agent information will be provided in.

     _This document proposes no change to the structure of DNS messages,
     and no new operation codes, response codes, resource record types, or
     any other new DNS protocol values._

full_text:
  dnsop                                                          J. Mozley
  Internet-Draft                                               N. Williams
  Intended status: Standards Track                          Infoblox, Inc.
  Expires: 27 August 2026                                      B. Sarikaya
                                                              Unaffiliated
                                                                 R. Schott
                                                          Deutsche Telekom
                                                          23 February 2026


                            DNS for AI Discovery
                    draft-mozleywilliams-dnsop-dnsaid-00

  Abstract

     This document specifies a method for utilizing the Domain Name System
     (DNS) to facilitate scalable and interoperable discovery between AI
     agents.  The proposed mechanism, referred to as _DNS AI agent
     Discovery_ (DNS-AID), defines a structured DNS namespace and record
     usage model to support metadata exchange and capability
     advertisement.

     This will allow organisations to publish information about their AI
     agents on the Internet or internal networks using a well-known label
     within the organisation’s own DNS namespace.  This document does not
     define how the published agent information is accessed or the exact
     structure of that information.  Instead, it specifies a mechanism for
     indicating which access protocol should be used and what format the
     agent information will be provided in.

     _This document proposes no change to the structure of DNS messages,
     and no new operation codes, response codes, resource record types, or
     any other new DNS protocol values._

  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://example.com/LATEST.  Status information for this document may
     be found at https://datatracker.ietf.org/doc/draft-mozleywilliams-
     dnsop-dnsaid/.

     Discussion of this document takes place on the WG Working Group
     mailing list (mailto:WG@example.com), which is archived at
     https://example.com/WG.





  Mozley, et al.           Expires 27 August 2026                 [Page 1]


  Internet-Draft                   DNS-AID                   February 2026


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

  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 27 August 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.  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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     3.  DNS Mechanisms for Agent Discovery  . . . . . . . . . . . . .   5
       3.1.  Use of Service Binding Records in Discovery . . . . . . .   5
       3.2.  DNS-Based Service Discovery . . . . . . . . . . . . . . .   6
       3.3.  Domain Control Validation . . . . . . . . . . . . . . . .   7
     4.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Example Communication . . . . . . . . . . . . . . . . . .   8
       4.2.  Example Record  . . . . . . . . . . . . . . . . . . . . .   9
       4.3.  Example Use Cases . . . . . . . . . . . . . . . . . . . .  10
       4.4.  Zone and Other Requirements . . . . . . . . . . . . . . .  10
         4.4.1.  Delegation and Chain of Trust . . . . . . . . . . . .  10



  Mozley, et al.           Expires 27 August 2026                 [Page 2]


  Internet-Draft                   DNS-AID                   February 2026


         4.4.2.  Performance Optimization(s) . . . . . . . . . . . . .  11
         4.4.3.  Customization(s)  . . . . . . . . . . . . . . . . . .  11
     5.  Implementation Guidance . . . . . . . . . . . . . . . . . . .  12
       5.1.  Discovery Usage Examples  . . . . . . . . . . . . . . . .  12
         5.1.1.  Discovery Status 1 (Known Service and Domain) . . . .  13
         5.1.2.  Discovery Status 2 (Known Service OR Domain,
                 Trusted)  . . . . . . . . . . . . . . . . . . . . . .  14
         5.1.3.  Discovery Status 3 (Multi-Domain Query for Known
                 Service)  . . . . . . . . . . . . . . . . . . . . . .  15
         5.1.4.  Discovery Status 4 (Untrusted Domain / Consolidated
                 Registry) . . . . . . . . . . . . . . . . . . . . . .  17
         5.1.5.  Discovery Status 4 (Unknown / Wildcard, or status 2
                 untrusted?) . . . . . . . . . . . . . . . . . . . . .  18
       5.2.  AI Providers  . . . . . . . . . . . . . . . . . . . . . .  18
         5.2.1.  Publishing Schema . . . . . . . . . . . . . . . . . .  18
         5.2.2.  TTLs, Update Agility  . . . . . . . . . . . . . . . .  19
         5.2.3.  Example DNS-AID Zonefile  . . . . . . . . . . . . . .  19
         5.2.4.  How to use this zonefile  . . . . . . . . . . . . . .  21
       5.3.  Why these records . . . . . . . . . . . . . . . . . . . .  21
     6.  Future Work & Unaddressed Portions  . . . . . . . . . . . . .  22
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  22
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  24
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     DNS-AID introduces a leaf zone convention (e.g., _agents.example.com)
     containing Service Binding (SVCB) records (e.g.,
     chat._agents.example.com) that encode application-specific metadata.
     These records enable agents to retrieve operational parameters prior
     to initiating a session, supporting both targeted lookups and
     capability-based discovery.  The approach leverages existing DNS
     protocols and records, including DNS Service Discovery (DNS-SD),
     DNSSEC, and DANE, to provide integrity, authenticity, and automation
     without requiring human intervention.  Lastly, the draft for Domain
     Control Validation (DCV) proposes a best current practice to prove an
     agent is authorized to act on behalf of a domain.

     This mechanism provides the bootstrap for discovering an
     organization's agents.  An organization can publish it's own registry
     of agents and their capabilities at a well-known entry point in the
     DNS hierarchy.  It is also possible to provide names for commonly
     used agents, so that any registry does not need to be queried and the
     returned capabilities processed (e.g. on a model card or other



  Mozley, et al.           Expires 27 August 2026                 [Page 3]


  Internet-Draft                   DNS-AID                   February 2026


     schema) and then the name of this resolved.  It is expected that
     other drafts will develop the content of any registry, such as
     refining the model card concept to a more structure schema, and the
     protocol used to interact with the registry.  It is more performant
     and deterministic to receive the details of the IP, protocols and
     port from an SVCB record than it is to determine this from a model
     card.  It also mitigates against the vulnerability of parsing this
     information from a model card.

     For example, a company may only have a few external agents available
     for use, and if the IETF standardizes 'types' of AI agents, then
     perhaps _chat._agents.example.com or _img2txt._agents.example.com etc
     are all different SVCB records.  On the other hand a company may
     provide an index of all agents via a well know entry point in the DNS
     hierarchy e.g. _index._agents.example.com.

     The DNS-AID model is designed for incremental and non-disruptive
     deployment within existing DNS infrastructure.  It introduces no new
     DNS message formats, opcodes, response codes, or resource record
     types.  Instead, it defines a structured namespace convention and
     usage profile for existing record types... primarily SVCB, TXT, and
     TLSA all within designated leaf zones (e.g.,
     _a2a._agents.example.com).

     Organizations may adopt DNS-AID by publishing agent metadata under
     delegated subdomains, leveraging DNSSEC for integrity and
     authenticity, and optionally implementing Domain Control Validation
     (DCV) to signal delegated authority.  These zones may be exposed
     selectively via split-horizon DNS or different zones, enabling
     differentiated discovery views for internal and external agents.  No
     changes are required to recursive or authoritative DNS server
     implementations beyond standard support for DNSSEC and SVCB.

     This model supports opt-in adoption, allowing agent operators to
     publish discovery metadata without coordination with external
     registries or protocol maintainers.  It is compatible with existing
     DNS tooling, including zone provisioning systems, monitoring
     platforms, and resolver configurations.  DNS-AID is therefore
     suitable for deployment across enterprise, cloud, and federated
     environments, and may coexist with other discovery mechanisms without
     conflict.










  Mozley, et al.           Expires 27 August 2026                 [Page 4]


  Internet-Draft                   DNS-AID                   February 2026


  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.  DNS Mechanisms for Agent Discovery

     AI agents that need to be discovered are currently being developed to
     support tasks such as travel planning, etc.  See Figure 1.

                       Agent Capabilities

     ┌───────────────────────┐    ┌───────────────────────┐
     │      DISCOVERY        │    │     APPLICATION       │
     │                       │    │                       │
     │  - SVCB (INDEX)       │    │  - TRAVEL             │
     │      IP               │    │  - COST               │
     │      PROTOCOL         │    │  - ATTESTATIONS       │
     │      PORT             │    │     TRAINING DATA     │
     │                       │    │     CERTIFICATIONS    │
     │  -WELL KNOWN AGENTS   │    │     ACCEPTABLE USE    │
     │     SVCB RRs          │    │  - TO BE SPECIFIED... │
     │                       │    │                       │
     └───────────────────────┘    └───────────────────────┘

            This draft                   Other drafts

                        Figure 1: AI Agent Capabilities

  3.1.  Use of Service Binding Records in Discovery

     Agents will use SVCB records as defined in [RFC9460] to discover
     other agent endpoints under structured leaf zones (e.g.,
     _chat._agents.example.com).  These records allow querying agents to
     retrieve operational parameters prior to initiating a session,
     including supported protocols, privacy features (e.g., Encrypted
     Client Hello via ECH), and failover configurations.

     Agents may advertise support for QUIC, HTTP/3, or agent-to-agent
     protocols via ALPN declarations.  Operators may specify alternate
     endpoints or migrate services across domains without relying on CNAME
     indirection, improving performance and reducing DNS resolution
     complexity.





  Mozley, et al.           Expires 27 August 2026                 [Page 5]


  Internet-Draft                   DNS-AID                   February 2026


     When paired with attribute leaf zones and custom SVCB parameters,
     this mechanism enables fine-grained discovery of agent capabilities.
     For instance, an agent querying _a2a._agents.example.com may receive
     an SVCB record indicating supported modalities (e.g., chat, image-to-
     text), expected input formats, and cost-related metadata (e.g., token
     pricing).  This structured discovery model supports deterministic,
     cacheable, and semantically rich interactions between agents.

     SVCB records can indicate the protocol used to communicate with a
     given agent as in Figure 2:

    _index._agents.example.com. 3600 IN SVCB 1 ai-index-svc.example.com. (
        alpn="a2a"
        port=443
        ipv4hint=192.0.2.1
        ipv6hint=2001:db8::1
    )

                        Figure 2: SVCB Record Example

  3.2.  DNS-Based Service Discovery

     DNS-SD as defined in [RFC6763], extends the capabilities of the
     Domain Name System to support service-type-based discovery.  Unlike
     traditional DNS resolution, which requires prior knowledge of a
     specific hostname, DNS-SD enables clients to discover services based
     on their functional type (e.g., _http._tcp, _printer._udp) within a
     given domain.

     DNS-SD provides a mechanism for AI agents to discover other agents or
     services based on declared capabilities rather than explicit names.
     For example, an agent may issue a query for _data-
     cleaner._a2a._agents.example.com to locate services capable of
     performing data sanitization tasks.  This type-based discovery model
     supports dynamic ecosystems where agent roles and capabilities may
     evolve over time.

     DNS-SD operates over both multicast DNS (mDNS) and unicast DNS,
     allowing for flexible deployment in local networks and globally
     scoped domains.  In enterprise or cloud environments, unicast DNS-SD
     enables structured and policy-compliant discovery across
     organizational boundaries.  When combined with SVCB records, DNS-SD
     allows agents to retrieve detailed service metadata, including
     transport preferences, protocol support, and operational parameters.







  Mozley, et al.           Expires 27 August 2026                 [Page 6]


  Internet-Draft                   DNS-AID                   February 2026


     This model supports federated agent architectures, where multiple
     agents may advertise similar capabilities under different domains.
     By leveraging DNS-SD, agents can perform capability-based queries and
     receive a list of candidate services, each accompanied by structured
     metadata for evaluation and selection.

     DNS-SD also supports extensibility through TXT records and custom
     service naming conventions, enabling organizations to encode
     additional attributes relevant to agent interaction (e.g., supported
     data formats, authentication requirements, or cost models).  A TXT
     record with the same name as the SVCB record could be used to provide
     additional meta-data.  These features make DNS-SD a suitable
     foundation for scalable, interoperable, and semantically rich agent
     discovery workflows.

     An index of agents type service can be provided via DNS-SD as a well
     known entry point to a more complete capability description via a
     common schema e.g. _index._agents.example.com.  This may be used in
     addition to or instead of querying for specific agent services such
     as _data-cleaner._a2a._agents.example.com.  Querying specific
     services will shortcut communication vs. querying an index derived
     from something like organisation's agent registry.

  3.3.  Domain Control Validation

     DCV refers to the process by which an entity demonstrates
     authoritative control over a DNS domain.  As described in
     [I-D.draft-ietf-dnsop-domain-verification-techniques], DNS-based DCV
     typically involves the placement of a DNS record, most commonly a TXT
     record, containing a challenge token or assertion at a designated
     location within the domain.  This record is then queried by an
     Application Service Provider (ASP) to confirm control.

     The authors do not intend for authorization to exist solely within
     this phase of the discovery process, however there may be use cases
     in which agents acting on behalf of domains, prior to application
     handshake, can prove they are acting on behalf of a domain
     (organization).  This may be a preferable mechanism, especially for
     ephemeral agents, to prove they act on behalf of a domain, rather
     than manage many temporary security mechanisms across multiple
     information security pillars (firewalls, certs, etc.).

     In the context of DNS-AID, DCV provides a mechanism for agents to
     assert delegated authority on behalf of a domain.  For example, an
     organization may publish a TXT record under a structured leaf zone
     (e.g., _agent-roles._a2a._agents.example.com) containing metadata
     such as:




  Mozley, et al.           Expires 27 August 2026                 [Page 7]


  Internet-Draft                   DNS-AID                   February 2026


     ai-role=data-cleaner; crm=salesforce; access=readonly

     This record signals that a specific agent is authorized to perform
     scoped operations under the domain's authority.  When protected by
     DNSSEC, such assertions become cryptographically verifiable,
     mitigating risks of spoofing or unauthorized delegation.

     DCV within DNS-AID supports both ephemeral and persistent validation
     models.  Ephemeral validation may be used for short-lived agent
     credentials or session-based delegation, while persistent records
     enable long-term authorization signaling.  TTL and expiration
     considerations, as discussed in the draft, are critical to ensuring
     that validation records do not persist beyond their intended scope.

     Furthermore, DNS-AID encourages the use of application-specific
     naming conventions and token formats to avoid service confusion and
     collision.  Validation records should be scoped to the intended
     service and include unguessable tokens or structured metadata to
     prevent unauthorized reuse across federated agent ecosystems.

  4.  Architecture

     DNS’s hierarchical namespace supports multi-tenant and federated
     discovery models.  Organizations may delegate subdomains to tenants
     (e.g., customer1._agents.vendor.com) or publish agent metadata under
     federated zones (e.g., region1._a2a.example.org).  This enables
     scoped discovery, policy enforcement, and operational isolation
     across tenants, departments, or geographic regions.  Combined with
     DNSSEC and access controls, this model supports secure delegation and
     trust signaling in complex agent ecosystems, including SaaS platforms
     and cross-organizational collaborations.

  4.1.  Example Communication

     Agent (org1) wants to find other agents provided by another entity
     (org2) and discover/verify capabilities Figure 3:















  Mozley, et al.           Expires 27 August 2026                 [Page 8]


  Internet-Draft                   DNS-AID                   February 2026


                      DNS SVCB Query
                  _a2a._agents.example.com
     ┌────────┐                       ┌────────┐            ┌────────┐
     │AI Agent├──────────────────────►│Resolver├───────────►│Auth DNS│
     │ (ORG1) │◄──────────────────────┤ (ORG1) │◄─────┬─────┤ (ORG2) │
     └────────┘                       └────────┘      │     └────────┘
                                                      │
     ┌────────────────────────────────────────────────┴──────────────┐
     │_a2a._agents.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. ( │
     │    alpn="a2a"                                                 │
     │    port=443                                                   │
     │    ipv4hint=192.0.2.1                                         │
     │    ipv6hint=2001:db8::1                                       │
     │)                                                              │
     └───────────────────────────────────────────────────────────────┘

                       Figure 3: Agent ORG1 Querying Org2

  4.2.  Example Record

     _a2a._agents.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. (
         alpn="a2a"
         port=443
         ipv4hint=192.0.2.1
         ipv6hint=2001:db8::1
     )

                     Figure 4: Example SVCB Resource Record

     *  _a2a._agents.example.com.: The service name, following the SVCB
        naming convention (_service._agents.example.com).

     *  3600: TTL (Time to Live) in seconds.

     *  IN SVCB: The record type.

     *  1: SVCB priority. 0 is for alias mode; 1+ is for service mode.

     *  ai-index-svc.org2.com.: The target name of the service.

     *  alpn="a2a": Specifies the ALPN protocol identifier.  This is where
        your custom protocol is declared.

     *  port=443: The port on which the service is available.

     *  ipv4hint and ipv6hint: Optional hints for clients to connect
        directly.




  Mozley, et al.           Expires 27 August 2026                 [Page 9]


  Internet-Draft                   DNS-AID                   February 2026


  4.3.  Example Use Cases

     1.  A user instructs their internal agent to “clean up Salesforce
         contacts based on this email.” The agent must discover
         Salesforce’s authorized agents, validate its own delegation to
         act on behalf of the enterprise, and initiate a secure session.
         DNS-AID enables this by publishing agent endpoints and roles
         under DNS zones controlled by each organization.

     2.  A research consortium deploys agents across multiple
         institutions.  Each institution publishes its agents under its
         own domain (e.g., _a2a._agents.universityA.edu), allowing
         collaborators to discover services based on capability (e.g.,
         _data-annotator._a2a.universityB.edu) while respecting
         institutional boundaries and trust models.

     3.  A SaaS provider hosts agents for multiple customers.  Each
         customer’s agents are published under tenant-specific zones
         (e.g., customer1._agents.saas.com), enabling scoped discovery and
         policy enforcement.  DNS-AID supports this model through
         hierarchical zone delegation and metadata-rich SVCB records.

     4.  Lightweight agents deployed on mobile or edge devices require
         low-latency, cacheable discovery mechanisms.  DNS’s distributed
         architecture and support for SVCB hints (e.g., IP addresses,
         preferred protocols) enable efficient resolution and connection
         bootstrapping in constrained environments.

     5.  In regulated industries, agents must operate within
         jurisdictional boundaries and maintain audit trails of
         interactions.  DNS supports geographic scoping via ccTLDs and
         split-horizon configurations, while query logging and DNSSEC
         provide observability and integrity guarantees.

  4.4.  Zone and Other Requirements

  4.4.1.  Delegation and Chain of Trust

     A public authoritative zone used for the purposes of agent discovery
     MUST use DNSSEC [RFC4033].  The zone MUST establish a complete chain
     of trust to a publicly recognized trust anchor.  AI agents MUST use
     validating resolvers, or have the capability to validate records.

     All DNS-AID-specific discovery records (e.g. SVCB/HTTPS [RFC9460],
     TXT/URI [RFC7553] used for capability descriptors, and any DNS-
     AID-defined RRTypes) MUST be signed and published in the DNS-AID
     External Zone.  Where DNS-AID endpoints rely on TLS, publication of
     DANE TLSA records SHOULD be used to bind endpoint certificates to



  Mozley, et al.           Expires 27 August 2026                [Page 10]


  Internet-Draft                   DNS-AID                   February 2026


     DNSSEC-validated names [RFC6698][RFC7671].  Resolver behavior
     consuming DNS-AID data MUST treat DNSSEC-bogus responses as failures
     and MUST NOT act on unsigned or invalidly signed discovery data.

  4.4.2.  Performance Optimization(s)

     Each agent service endpoint that is specifically published as a DNS
     record SHOULD be an SVCB record in ServiceMode (or HTTPS RR for HTTPS
     endpoints) to convey connection parameters and capability locators
     with a single lookup [RFC9460].  SVCB “address hints” (ipv4hint,
     ipv6hint) SHOULD be used to reduce A/AAAA follow-up queries;
     resolvers MAY still validate final addresses via canonical
     resolution.  Where human-friendly names are required, SVCB AliasMode
     (priority 0) MAY be used to map from a stable alias name to a
     canonical name.

     Authoritative servers MUST support EDNS(0) [RFC6891] and TCP fallback
     [RFC7766].  Operators SHOULD target response sizes that avoid IP
     fragmentation on common paths (e.g., ≤1232 bytes on IPv6), preferring
     compression and layered indirection over oversized RRsets.  TTLs MUST
     be chosen to reflect the volatility of capability data; index/
     indirection records may use longer TTLs than frequently changing
     endpoint or capability descriptors.  Negative caching MUST conform to
     [RFC2308].  When high update rates are expected, IXFR and NOTIFY
     SHOULD be used to reduce propagation latency.

     A representative naming pattern is shown below; the exact label order
     is deployment-specific, but the leaf per service, per agent rule
     applies:

     ``` ; Hashed, per-agent, per-service leaf
     a4k2f9._mcp._agents.example.org.  600 IN SVCB 1 svc-
     a4k2f9.example.org.  alpn="map,h2,h3" port=443 ipv6hint=2001:db8::5
     ipv4hint=192.0.2.5

     ; Optional alias for a friendlier owner name
     billing._mcp._agents.example.org. 300 IN SVCB 0
     a4k2f9._mcp._agents.example.org. ```

  4.4.3.  Customization(s)

     DNS-AID deployments MAY define additional SVCB parameters
     (SvcParamKeys) to convey agent-specific capability metadata, provided
     that interoperability safeguards in [RFC9460] are observed.  During
     experimentation, unregistered keys MUST use the numeric keyNNNNN
     presentation form, and any client behavior that depends on them MUST
     be gated via the mandatory SvcParam to ensure downgrade safety.




  Mozley, et al.           Expires 27 August 2026                [Page 11]


  Internet-Draft                   DNS-AID                   February 2026


     This specification defines the following provisional SvcParamKeys for
     DNS-AID (names are illustrative; production deployments MUST register
     through IANA per [RFC9460] or use keyNNNNN until standardized):

     The following are example use cases for additional params:

     *  cap — a capability descriptor locator or inline identifier (e.g.,
        a URN or compact JSON-Ref) that identifies the agent’s advertised
        capability schema/version.

     *  cap-sha256 — a base64url-encoded SHA-256 digest of the canonical
        capability descriptor to support integrity checks and cache
        revalidation.

     *  policy — a URI or URN identifying a policy bundle applicable to
        this agent (e.g., jurisdiction, data handling class) for
        client-side selection.

     *  realm — an opaque token for multi-tenant scoping or authz realm
        selection during protocol bootstrapping.

     Clients that require any of these parameters MUST verify their
     presence via the mandatory key; otherwise, the SVCB record MUST be
     ignored.  Example:

     Single-RRTYPE publication with custom params (experimental keys
     shown) a4k2f9._mcp._agents.example.org. 600 IN SVCB 1 svc-
     a4k2f9.example.org.  alpn="h2" port=443 ipv4hint=192.0.2.5
     mandatory=alpn,port,key65001,key65002,key65010
     key65001="cap=urn:cap:example:mcp:invoice.v1" key65002="cap-
     sha256=yvZ0n7q8bE2gYkz8m1j1s0yQG0mC2F6qj3b9pVb6Gk0"
     key65010="bap=a2a/1,mcp/1"

     Where endpoints are HTTPS, the HTTPS RR variant SHOULD be used to
     co-locate transport parameters such as ECH with capability metadata;
     otherwise, generic SVCB MAY be used.  Future standardization SHOULD
     define the exact syntax (e.g., ABNF) and registry policy for these
     keys, including error handling for malformed or conflicting
     parameters.  Until registration is complete, deployments MUST treat
     unknown keyNNNNN parameters as opaque and MUST NOT infer semantics
     without out-of-band agreement.

  5.  Implementation Guidance

  5.1.  Discovery Usage Examples






  Mozley, et al.           Expires 27 August 2026                [Page 12]


  Internet-Draft                   DNS-AID                   February 2026


  5.1.1.  Discovery Status 1 (Known Service and Domain)

     Query foobar._mcp._agents.example.com Figure 5:

     In this scenario, the AI Agent Client knows both the service type
     (mcp) and the authoritative domain (example.com) and performs a
     direct SVCB query.

        AI Agent Client
        wants to discover:   foobar._mcp._agents.example.com
        (mcp = service, foobar = agent/capability, example.com = trusted domain)

          Agent Client              Resolver / Cache         Root/TLD/Auth DNS
                │                           │                          │
                │   1. SVCB Query           │                          │
                │   (Recursive)             │                          │
                ├──────────────────────────►│                          │
                │                           │                          │
                │                           │ 2. Query Root            │
                │                           ├─────────────────────────►│
                │                           │                          │
                │                           │ 3. Referral to .com NS   │
                │                           │◄─────────────────────────┤
                │                           │                          │
                │                           │ 4. Query .com TLD        │
                │                           ├─────────────────────────►│
                │                           │                          │
                │                           │ 5. Referral to auth NS   │
                │                           │◄─────────────────────────┤
                │                           │                          │
                │                           │ 6. Query Auth NS for     │
                │                           │    foobar._mcp._agents   │
                │                           ├─────────────────────────►│
                │                           │                          │
                │                           │ 7. SVCB RRSet Response   │
                │                           │    (DNSSEC-signed)       │
                │                           │◄─────────────────────────┤
                │                           │                          │
                │   8. SVCB Response        │                          │
                │   (cached + validated)    │                          │
                │◄──────────────────────────┤                          │
                │                           │                          │
                │   Response includes:      │                          │
                │   • Service target        │                          │
                │   • ALPN protocol(s)      │                          │
                │   • Port number           │                          │
                │   • IPv4/IPv6 hints       │                          │
                │   • DNSSEC signatures     │                          │



  Mozley, et al.           Expires 27 August 2026                [Page 13]


  Internet-Draft                   DNS-AID                   February 2026


                │   • Capabilities (cost,   │                          │
                │      modalities, etc)     │                          │
                │                           │                          │
                │   9. A2A, MCP, etc.       │                          │
                ├──────────────────────────►│                          │
                │   (Agent-to-Agent         │                          │
                │    communication begins)  │                          │
                │                           │                          │

    Figure 5: Discovery Status 1: SVCB Query with Full Chain Traversal

  5.1.2.  Discovery Status 2 (Known Service OR Domain, Trusted)

     Query of the known organisation's index if service is unknown
     Figure 6:

     In this scenario, the Agent Client knows the trusted domain
     (example.com) but the specific agent service type is unknown.  The
     client queries a well-known index entry point to discover available
     agent capabilities.  The index query is not DNS.

        AI Agent Client
        knows:            example.com is trusted
        wants to discover: available agents and services
        queries:          _index._agents.example.com (well-known entry point)

          Agent Client              Resolver / Cache         Root/TLD/Auth DNS
                │                           │                          │
                │   1. SVCB Query           │                          │
                │   _index._agents          │                          │
                │   (Recursive)             │                          │
                ├──────────────────────────►│                          │
                │                           │                          │
                │                           │ 2. Query Root            │
                │                           ├─────────────────────────►│
                │                           │                          │
                │                           │ 3. Referral to .com NS   │
                │                           │◄─────────────────────────┤
                │                           │                          │
                │                           │ 4. Query .com TLD        │
                │                           ├─────────────────────────►│
                │                           │                          │
                │                           │ 5. Referral to auth NS   │
                │                           │◄─────────────────────────┤
                │                           │                          │
                │                           │ 6. Query Auth NS for     │
                │                           │    _index._agents        │
                │                           ├─────────────────────────►│



  Mozley, et al.           Expires 27 August 2026                [Page 14]


  Internet-Draft                   DNS-AID                   February 2026


                │                           │                          │
                │                           │ 7. Index DNS Response    │
                │                           │    (SVCB RRSet or        │
                │                           │     CNAME/AliasMode)     │
                │                           │◄─────────────────────────┤
                │                           │                          │
                │   8. Index Agent Response │                          │
                │   (cached + validated)    │                          │
                │◄──────────────────────────┤                          │
                │                           │                          │
                │   Response includes:      │                          │
                │   • List of agent types   │                          │
                │     (mcp, a2a, etc.)      │                          │
                │   • Service endpoints     │                          │
                │   • Capability metadata   │                          │
                │   • DNSSEC signatures     │                          │
                │                           │                          │
                │   9. Parse index, select  │                          │
                │      desired agent type   │                          │
                │      (e.g., mcp)          │                          │
                │                           │                          │
                │   10. Query specific      │                          │
                │       agent service       │                          │
                │       foobar._mcp._aiag...├─────────────────────────►│
                │                           │                          │
                │                           │ 11. Return service       │
                │                           │     details              │
                │◄──────────────────────────┤◄─────────────────────────┤
                │                           │                          │
                │   12. A2A, MCP, etc.      │                          │
                ├──────────────────────────►│                          │
                │   (Agent-to-Agent         │                          │
                │    communication begins)  │                          │
                │                           │                          │

     Figure 6: Discovery Status 2: Index-Based Discovery with Service
                                Selection

  5.1.3.  Discovery Status 3 (Multi-Domain Query for Known Service)

     Query the same well-known agent name across multiple known domains
     (potential for this discovery case to be met by the registry
     described in Discovery Status 4):








  Mozley, et al.           Expires 27 August 2026                [Page 15]


  Internet-Draft                   DNS-AID                   February 2026


        AI Agent Client
        knows:            img2txt is a well-known agent type
        knows:            org1.com and org2.com are trusted domains
        wants to discover: which orgs have img2txt agents available

          Agent Client              Resolver / Cache         Root/TLD/Auth DNS
                │                           │              (ORG1 and ORG2)
                │                           │                          │
                │   1. SVCB Query           │                          │
                │   img2txt._a2a._agents    │                          │
                │   .org1.com               │                          │
                │   (Recursive)             │                          │
                ├──────────────────────────►│                          │
                │                           │                          │
                │                           │ 2. Resolve .org1 chain   │
                │                           ├─────────────────────────►│
                │                           │                          │
                │                           │ 3. Auth. DNS org1        │
                │                           │◄─────────────────────────┤
                │                           │    returns service info  │
                │                           │                          │
                │   4. Response (org1)      │                          │
                │   (cached + validated)    │                          │
                │◄──────────────────────────┤                          │
                │                           │                          │
                │   5. SVCB Query           │                          │
                │   img2txt._a2a._agents    │                          │
                │   .org2.com               │                          │
                ├──────────────────────────►│                          │
                │                           │                          │
                │                           │ 6. Resolve .org2 chain   │
                │                           ├─────────────────────────►│
                │                           │                          │
                │                           │ 7. Auth. DNS org2        │
                │                           │◄─────────────────────────┤
                │                           │    returns service info  │
                │                           │                          │
                │   8. Response (org2)      │                          │
                │   (cached + validated)    │                          │
                │◄──────────────────────────┤                          │
                │                           │                          │
                │   9. Client evaluates:    │                          │
                │   • Service capabilities  │                          │
                │     from both responses   │                          │
                │   • Trust levels (DNSSEC) │                          │
                │   • Cost, latency, etc.   │                          │
                │                           │                          │
                │   10. Select endpoint &   │                          │



  Mozley, et al.           Expires 27 August 2026                [Page 16]


  Internet-Draft                   DNS-AID                   February 2026


                │       A2A/protocol with   │                          │
                │       chosen provider     │                          │
                ├──────────────────────────►│                          │
                │   (Agent-to-Agent         │                          │
                │    communication begins)  │                          │
                │                           │                          │

  Figure 7: Discovery Status 3: Parallel Multi-Domain Service Discovery

  5.1.4.  Discovery Status 4 (Untrusted Domain / Consolidated Registry)

     Query a consolidated (reputable) registry (not DNS) when neither
     domain nor comprehensive service list is known:

        AI Agent Client
        knows:            a trusted registry (e.g., registry.ai-trust-community.org)
        wants to discover: all viable img2txt agents available (any org)
        scenario:         agent choice driven by capability, not domain affinity

          Agent Client              Resolver / Cache         Registry / Auth DNS
                │                           │                          │
                │   1. SVCB Query           │                          │
                │   _index._agents          │                          │
                │   .registry.ai-trust...   │                          │
                │   (Recursive)             │                          │
                ├──────────────────────────►│                          │
                │                           │                          │
                │                           │ 2. Resolve registry      │
                │                           │    domain chain          │
                │                           ├─────────────────────────►│
                │                           │                          │
                │                           │ 3. Return registry       │
                │                           │◄─────────────────────────┤
                │                           │    index/catalog SVCB    │
                │                           │                          │
                │   4. Registry Index       │                          │
                │   (HTTP, JSON, etc)       │                          │
                │──────────────────────────►┤                          │
                │                           │                          │
                │                           │  5. Registry Response    │
                │                           │◄─────────────────────────┤
                │                           │                          │
                │                           │   Response contains:     │
                │                           │   • Ref list: img2txt    │
                │                           │     agents from multiple │
                │                           │     trusted orgs         │
                │                           │   • Domains + endpoints  │
                │                           │   • Aggregate ratings,   │



  Mozley, et al.           Expires 27 August 2026                [Page 17]


  Internet-Draft                   DNS-AID                   February 2026


                │                           │     SLA info, cost       │
                │                           │   • DNSSEC provenance    │
                │                           │   • Capabilities (cost,  │
                │                           │     modalities, etc)     │
                │                           │                          │
                │   6. Client evaluates     │                          │
                │   registry results        │                          │
                │   (may include one or     │                          │
                │    more followup queries  │                          │
                │    per Discovery Status 1 │                          │
                │    for additional detail) │                          │
                │                           │                          │
                │   7. Query chosen         │                          │
                │      agent's auth DNS     │                          │
                │      for final details    │                          │
                ├──────────────────────────►│                          │
                │                           │                          │
                │   8. A2A/protocol with    │                          │
                │      registry-selected    │                          │
                │      endpoint             │                          │
                ├──────────────────────────►│                          │
                │   (Agent-to-Agent         │                          │
                │    communication begins)  │                          │
                │                           │                          │

      Figure 8: Discovery Status 4: Registry-Based Discovery Across
                            Multiple Providers

  5.1.5.  Discovery Status 4 (Unknown / Wildcard, or status 2 untrusted?)

     This case is out of scope.

  5.2.  AI Providers

  5.2.1.  Publishing Schema

     Publishers SHOULD expose per-service discovery records using SVCB (or
     HTTPS for HTTP origins) at stable, well-scoped owner names (e.g.,
     agent-id._mcp._agents.example.org.).  SVCB ServiceMode conveys
     connection parameters and capability locators in a single round trip;
     AliasMode MAY be used to map a friendly name to a hashed leaf for
     sharding without duplicating RRSets.  Initial connection parameter
     keys (alpn, port, address hints) and the mandatory key MUST be
     honored by clients.  [RFC9460]

     Minimal example:





  Mozley, et al.           Expires 27 August 2026                [Page 18]


  Internet-Draft                   DNS-AID                   February 2026


     ; ServiceMode SVCB for an MCP-capable agent
     a4k2f9._mcp._agents.example.org.  600 IN SVCB 1 svc-
     a4k2f9.example.net.  alpn="h2,h3" port=443 ipv6hint=2001:db8::5
     ipv4hint=192.0.2.5 mandatory=alpn,port

     SVCB/HTTPS semantics and SvcParam processing MUST follow [RFC9460] to
     ensure interop and correct fallback.

  5.2.2.  TTLs, Update Agility

     Publishers SHOULD assign longer TTLs to relatively static indirection
     records (aliases, stable service labels) and shorter TTLs to volatile
     endpoint/capability records to balance cache efficiency with rollout
     safety.  Consumers will apply negative caching per [RFC2308], so
     publishers SHOULD avoid unnecessary NXDOMAIN flaps during deployments
     (e.g., prefer blue/green leaves over in-place deletions).

  5.2.3.  Example DNS-AID Zonefile

     ``` $ORIGIN example.org. $TTL 3600

     ; -------------------------------------------------------------------
     --- ; SOA / NS ; ----------------------------------------------------
     ------------------ @ IN SOA ns1.example.org. hostmaster.example.org.
     ( 2025091901 ; serial (YYYYMMDDnn) 7200 ; refresh 1800 ; retry
     1209600 ; expire 3600 ) ; minimum IN NS ns1.example.org.  IN NS
     ns2.example.org.

     ns1 IN A 192.0.2.53 ns1 IN AAAA 2001:db8::53 ns2 IN A 192.0.2.54 ns2
     IN AAAA 2001:db8::54

     ; -------------------------------------------------------------------
     --- ; DNS-AID discovery (MCP example): per-service, per-agent leaf ;
     - Leaf is a stable mapping from AgentID -> label (e.g. hashed). ; -
     Use SVCB ServiceMode (priority > 0) to bind connection parameters. ; 
     ---------------------------------------------------------------------
     -

     ; AliasMode to keep a friendly name stable even if the leaf changes
     billing._mcp._agents 300 IN SVCB 0 a4k2f9._mcp._agents.example.org.

     ; Leaf per agent/service (ServiceMode).  Shorter TTL for agility.
     a4k2f9._mcp._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \
     alpn="h2,h3" \ port=443 \ ipv4hint=192.0.2.5 \ ipv6hint=2001:db8::5 \
     mandatory=alpn,port






  Mozley, et al.           Expires 27 August 2026                [Page 19]


  Internet-Draft                   DNS-AID                   February 2026


     ; (Optional) Another service face for the same agent (A2A)
     a4k2f9._a2a._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \ alpn="h2"
     port=8443 \ mandatory=alpn,port

     ; (Optional) HTTPS RR at apex for web-style consumers of DNS-AID
     metadata @ 900 IN HTTPS 1 web-gw.example.net. \ alpn="h2,h3" port=443

     ; -------------------------------------------------------------------
     --- ; Capability / policy signaling via SVCB custom keys
     (experimental) ; Use numeric keyNNNNN until you register IANA
     SvcParamKeys. ; Gate client requirements with "mandatory". ; --------
     -------------------------------------------------------------- ;
     Example: reference a capability descriptor and advertise supported
     app protocols. ; NOTE: Values and key numbers are illustrative.

     a4k2f9._mcp._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \
     alpn="h2,h3" port=443 \ mandatory=alpn,port,key65001,key65010 \
     key65001="cap=urn:cap:example:mcp:invoice.v1" \
     key65010="bap=a2a/1,mcp/1"

     ; -------------------------------------------------------------------
     --- ; Domain Control Validation (DCV) for DNS-AID authorization ;
     Publish a short-lived token to prove control over example.org. ;
     Remove after successful validation.  Resolver MUST DNSSEC-validate. ;
     ---------------------------------------------------------------------
     - _agents-challenge 300 IN TXT "bnd-req=svc:crm-
     sync@vendor.example;nonce=3Qz6l8pA;exp=2025-09-19T06:00:00Z"

     ; -------------------------------------------------------------------
     --- ; Optional DANE TLSA for the service endpoint used above. ;
     Owner: _<port>._tcp.<endpoint-FQDN> ; Usage 3 (DANE-EE), Selector 1
     (SPKI), Match 1 (SHA-256) ; Replace the hash with the actual SPKI
     hash of the leaf certificate. ; -------------------------------------
     --------------------------------- _443._tcp.svc-a4k2f9.example.net.
     1800 IN TLSA 3 1 1 (
     0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789AB )

     ; -------------------------------------------------------------------
     --- ; (Optional) Address records for the service endpoint, if hosted
     in-zone ; If hosted out-of-zone (example.net), these will live there
     instead. ; ----------------------------------------------------------
     ------------ svc-a4k2f9 900 IN A 192.0.2.5 svc-a4k2f9 900 IN AAAA
     2001:db8::5 web-gw 900 IN A 192.0.2.80 web-gw 900 IN AAAA
     2001:db8::80 ```







  Mozley, et al.           Expires 27 August 2026                [Page 20]


  Internet-Draft                   DNS-AID                   February 2026


  5.2.4.  How to use this zonefile

     *  Adjust TTLs for agility vs. cache efficiency.  Use longer TTLs on
        indirection (aliases), shorter TTLs on volatile leaves and DCV.
        This aligns with DNS caching behavior and negative caching rules
        [RFC2308].

     *  Follow SVCB/HTTPS semantics.  Clients must honor SvcPriority,
        AliasMode (priority 0), and ServiceMode parameters, including
        mandatory, alpn, port, and address hints per [RFC9460].

     *  DCV token flow.  Issue a time-bounded token at _agents-
        challenge.domain and require DNSSEC-validated retrieval (pattern
        analogous to ACME’s DNS-01 in [RFC8555]).  Remove on success.

     *  Bind transport to DNS with DANE (optional).  If your relying
        parties validate DNSSEC, publish TLSA to bind the endpoint’s cert/
        key, using the operational guidance in [RFC7671] (TLSA record
        format in [RFC6698]).

     *  Sign the zone.  This file is pre-signing.  Sign with DNSSEC
        (DNSKEY/DS/RRSIG, etc.) before deployment; validators must treat
        unsigned/bogus discovery data as a failure (per your earlier
        spec).  See DNSSEC core specs [RFC4033], [RFC4034], [RFC4035] and
        operational guidance.

  5.3.  Why these records

     *  SVCB/HTTPS concentrate connection metadata and allow aliasing at
        apex and service labels, reducing round trips and enabling
        policy-gated parameters via mandatory.

     *  Per-service, per-agent leaves avoid oversized RRsets and allow
        parallel administration/sharding while keeping alias names stable.
        This follows performance guidance in SVCB and your DNS-AID perf
        section.

     *  DCV via TXT mirrors a well-understood, automated control-proof
        pattern [RFC8555] that fits DNS-AID authorization workflows.

     *  DANE TLSA optionally removes reliance on external PKI anchors for
        endpoint auth where DNSSEC is deployed [RFC6698], with deployment
        rules in [RFC7671].








  Mozley, et al.           Expires 27 August 2026                [Page 21]


  Internet-Draft                   DNS-AID                   February 2026


  6.  Future Work & Unaddressed Portions

     How a consolidated registry would operate?  Would it gather and
     publish information from individual organisations (scraping), would
     those organisations registery attest to security and be verified?

  7.  Security Considerations

     DNSSEC security considerations apply.

  8.  IANA Considerations

     IANA is requested to register an underscored attribute leaf as part
     of [RFC8552] for agents.

     IANA is requested to designate custom key-value pairs for SVCB
     parameters to facilitate agent-to-agent application discovery,
     potentially for cost optimization (token input counts, costs per
     token bundle, etc.)

  9.  References

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

  9.2.  Informative References

     [I-D.draft-ietf-dnsop-domain-verification-techniques]
                Sahib, S. K., Huque, S., Wouters, P., Nygren, E., and T.
                Wicinski, "Domain Control Validation using DNS", Work in
                Progress, Internet-Draft, draft-ietf-dnsop-domain-
                verification-techniques-11, 1 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
                domain-verification-techniques-11>.

     [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
                NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
                <https://www.rfc-editor.org/rfc/rfc2308>.





  Mozley, et al.           Expires 27 August 2026                [Page 22]


  Internet-Draft                   DNS-AID                   February 2026


     [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements",
                RFC 4033, DOI 10.17487/RFC4033, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4033>.

     [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Resource Records for the DNS Security Extensions",
                RFC 4034, DOI 10.17487/RFC4034, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4034>.

     [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Protocol Modifications for the DNS Security
                Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4035>.

     [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
                of Named Entities (DANE) Transport Layer Security (TLS)
                Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
                2012, <https://www.rfc-editor.org/rfc/rfc6698>.

     [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
                Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
                <https://www.rfc-editor.org/rfc/rfc6763>.

     [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/rfc/rfc6891>.

     [RFC7553]  Faltstrom, P. and O. Kolkman, "The Uniform Resource
                Identifier (URI) DNS Resource Record", RFC 7553,
                DOI 10.17487/RFC7553, June 2015,
                <https://www.rfc-editor.org/rfc/rfc7553>.

     [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
                Authentication of Named Entities (DANE) Protocol: Updates
                and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
                October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.

     [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
                D. Wessels, "DNS Transport over TCP - Implementation
                Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
                <https://www.rfc-editor.org/rfc/rfc7766>.

     [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
                Records through "Underscored" Naming of Attribute Leaves",
                BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8552>.



  Mozley, et al.           Expires 27 August 2026                [Page 23]


  Internet-Draft                   DNS-AID                   February 2026


     [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
                Kasten, "Automatic Certificate Management Environment
                (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8555>.

     [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
                and Parameter Specification via the DNS (SVCB and HTTPS
                Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
                November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

  Acknowledgments

     The authors thank Ben Schwartz and Ross Gibson for their
     contributions, questions, and comments.

  Authors' Addresses

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


     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 27 August 2026                [Page 24]


