# drafts

name: draft-mao-rtgwg-apn-framework-for-ioa
rev: 00
title: APN Framework for Internet of Agent (IoA)
time: 2025-11-02T04:05:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T04:05:09Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:12.944663+00:00
abstract:
  With the rapid development of large model technologies in the AI
     field, it has become possible to develop more intelligent assistant
     software, which is currently referred to as AI Agents in the
     industry.  These agents may come from different manufacturers and be
     deployed on different cloud platforms and regions.  They need to
     communicate and collaborate with each other through the Internet,
     which is called Internet of Agents (IoA).  Different interactions of
     AI agents have varying task requirements, which also lead to
     different demands on the network.  This requires network providing
     various fine granular services for the interactions of AI agents.

     This document proposes the application of the APN framework in the
     IoA scenario and analyzes its necessity.

full_text:
  Network Working Group                                             J. Mao
  Internet-Draft                                                     Z. Li
  Intended status: Standards Track                                 N. Geng
  Expires: 5 May 2026                                             C. Zheng
                                                       Huawei Technologies
                                                           1 November 2025


                 APN Framework for Internet of Agent (IoA)
                  draft-mao-rtgwg-apn-framework-for-ioa-00

  Abstract

     With the rapid development of large model technologies in the AI
     field, it has become possible to develop more intelligent assistant
     software, which is currently referred to as AI Agents in the
     industry.  These agents may come from different manufacturers and be
     deployed on different cloud platforms and regions.  They need to
     communicate and collaborate with each other through the Internet,
     which is called Internet of Agents (IoA).  Different interactions of
     AI agents have varying task requirements, which also lead to
     different demands on the network.  This requires network providing
     various fine granular services for the interactions of AI agents.

     This document proposes the application of the APN framework in the
     IoA scenario and analyzes its necessity.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 5 May 2026.

  Copyright Notice

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



  Mao, et al.                Expires 5 May 2026                   [Page 1]


  Internet-Draft                 APN for IoA                 November 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  The Necessity of APN Framework for IoA  . . . . . . . . . . .   3
       4.1.  What is APN . . . . . . . . . . . . . . . . . . . . . . .   3
       4.2.  IoA needs Differentiated SLA Guarantee from network . . .   4
       4.3.  IoA needs Secure Transmission from network  . . . . . . .   5
       4.4.  IoA needs Measurement and Visualization from network  . .   6
     5.  APN framework for IoA . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Using APN framework in IoA scenarios  . . . . . . . . . .   6
       5.2.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   8
         5.2.1.  Requirements for AI Agents  . . . . . . . . . . . . .   8
         5.2.2.  Requirements for Network Devices  . . . . . . . . . .   9
         5.2.3.  Requirements for Network Controller . . . . . . . . .   9
         5.2.4.  Requirements for Protocol Extensions  . . . . . . . .   9
         5.2.5.  Requirements for Security . . . . . . . . . . . . . .  10
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     With the rapid development of large language model technologies in
     the AI field, it has become possible to develop more intelligent
     assistant software, which is currently referred to as AI agents in
     the industry.

     Various types of AI agents have emerged rapidly within a year,
     serving different industries and people's daily lives.  Examples
     include deep research agents, code development agents, text
     generation agents, image generation agents, video generation agents,
     as well as agents for ordering meals, booking flights, booking
     hotels, and travel planning.




  Mao, et al.                Expires 5 May 2026                   [Page 2]


  Internet-Draft                 APN for IoA                 November 2025


     These agents may come from different manufacturers and be deployed on
     different cloud platforms and regions.  They need to communicate and
     collaborate with each other through the internet.

     For example, a user might request the marketing agent to help
     generate promotional materials for a new router product.  The
     marketing agent might first ask the text generation agent to write
     promotional copy, then request the image generation agent to create
     promotional images, and subsequently ask the video generation agent
     to produce a product introduction video.  Finally, it would collect
     all the promotional materials from these agents, save them on the
     server and notify the user to review them.

     Different interactions of AI agents have varying task requirements,
     which also lead to different demands on the network.  This requires
     network providing various fine granular services for the interactions
     of AI agents.

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

  3.  Terminology

     APN: Application-aware Networking

     IoA: Internet of Agents

  4.  The Necessity of APN Framework for IoA


  4.1.  What is APN

     APN is a technology that enables networks to be aware of application
     requirements.  Its framework and extension are defined in
     [I-D.li-rtgwg-apn-framework] and
     [I-D.li-rtgwg-apn-app-side-framework].

     These documents propose a new framework, named Application-aware
     Networking (APN), where application-aware information (APN attribute)
     including application-aware identification (APN ID) and application-
     aware parameters (APN Parameters), is encapsulated at network edge
     devices and carried along with the encapsulation of the tunnel used
     by the packet when traversing the APN domain.



  Mao, et al.                Expires 5 May 2026                   [Page 3]


  Internet-Draft                 APN for IoA                 November 2025


     By APN domain we intend the operator infrastructure where APN is used
     from edge to edge (ingress to egress) and where the packet is
     encapsulated using an outer header incorporating the APN information.
     The APN attribute will facilitate service provisioning and provide
     fine-granularity services in the APN domain.

     In addition, for the extension of the APN framework for application
     side, the APN resources of the APN domain are allocated to
     applications which compose and encapsulate the APN attribute in
     packets.  When network devices in the APN domain receive packets
     carrying APN attribute, they can directly apply policies for these
     traffic flows according to the APN attribute encapsulated by
     applications.

     APN can be applied in IoA scenarios, allowing networks to understand
     the requirements of each agent and its tasks on the network.  This
     enables the network to provide services that match these
     requirements, such as SLA assurance, security, measurement, and
     visualization, thereby improving the performance, security, and
     maintainability of agent interactions.

  4.2.  IoA needs Differentiated SLA Guarantee from network

     Different tasks of agent interaction have varying requirements for
     network transmission.

     For example:

     *  Tool invocation tasks emphasize real-time interaction and are
        highly sensitive to latency and jitter, but have low bandwidth
        requirements.

     *  Text generation tasks are relatively sensitive to latency but have
        low bandwidth requirements.

     *  Image generation tasks have low latency requirements but
        relatively high bandwidth demands.

     *  Video generation tasks have low requirements for latency and
        jitter but very high bandwidth demands.

     Each of these tasks can be further divided into real-time interaction
     tasks and background interaction tasks:








  Mao, et al.                Expires 5 May 2026                   [Page 4]


  Internet-Draft                 APN for IoA                 November 2025


     *  Real-time interaction is used in scenarios where users actively
        operate the system.  Since the final response needs to be
        presented to the user (who waits for the result in front of the
        device), it has higher requirements for real-time performance
        (i.e., latency and jitter).

     *  Background interaction is initiated by the agent software in the
        application's backend system, thus having lower requirements for
        real-time performance.

     These different QoS requirements can be identified in traffic packets
     using APN.  Currently, APN defines four APN parameters:

     *  Bandwidth Requirement Parameter

     *  Delay Requirement Parameter

     *  Delay Variation Parameter

     *  Packet Loss Rate Parameter

     New APN parameters may need to be defined to carry some information
     about AI models, tools, tasks, data, or tokens for some specific IoA
     scenarios.

     By carrying these APN parameters in the messages, the network can
     provide differentiated and targeted services for different
     intelligent agent tasks to ensure a good experience for agent
     interactions.  For example, the network can offer fine-grained SLA
     guarantees, fine-grained network slicing, and fine-grained
     deterministic networking.

  4.3.  IoA needs Secure Transmission from network

     Agents interact with each other through the Internet, which may
     require the network to provide security services.

     For example, a food ordering agent on a mobile phone communicates
     with a payment agent on the cloud, and the payment agent communicates
     with a bank agent, which may be on-premises.  These communications
     involve your personal account information and financial data, so they
     require a higher level of security.

     The APN ID or APN parameter can be used to carry encrypted
     transmission requirements.  The network can then create IPsec tunnels
     or quantum transmission channels and direct the traffic of agent
     interactions to these secure channels to prevent eavesdropping,
     tampering, and forgery.



  Mao, et al.                Expires 5 May 2026                   [Page 5]


  Internet-Draft                 APN for IoA                 November 2025


     For enterprises, they may want to enforce access control to agent
     interactions.  For instance, some agents that can access sensitive
     data are not allowed to collaborate with external agents to prevent
     data leakage.  However, some general-purpose agents are allowed to
     interact with external agents to improve team efficiency.

     The APN ID or APN parameter can be used to carry the identifier of
     the security group to which an agent belongs.  The network can then
     perform access control based on these identifiers to avoid unexpected
     agent interactions and information security risks.

  4.4.  IoA needs Measurement and Visualization from network

     When intelligent agents interact through the internet, the quality of
     communication may need to be measured for purposes such as fault
     localization, troubleshooting, and visualization.

     APN IDs can be used to identify AI agents, and network devices can be
     configured to enable network measurement functions (e.g., IFIT) for
     specific agents, thereby enabling in-band measurement of the
     interaction traffic among these agents.  The network controller can
     visually present the communication quality of these agent
     interactions to the network administrators.

  5.  APN framework for IoA


  5.1.  Using APN framework in IoA scenarios

     The APN architecture can be applied to IoA scenarios, as illustrated
     in the following diagram.  The IoA service requirement that needs to
     be carried in the APN ID or APN parameter essentially belongs to a
     type of application-aware information (i.e., APN attribute).


















  Mao, et al.                Expires 5 May 2026                   [Page 6]


  Internet-Draft                 APN for IoA                 November 2025


                                +------------------+
                                |   APN-Customer   |
                                +------------------+
                                         |
                                         | NBI
                                         |
                                +------------------+
            --------------------|                  |------------------------
           /                    |  APN-Controller  |                        \
          /              -------|                  |--------                 \
         /              /       +------------------+        \                 \
        |              /       /         |          \        \                 |
  +----------+        /       /          | SBI       \        \          +----------+
  |AI Agent 1|-\     |       |           |            |        |      /->|AI Agent 3|
  +----------+ |  +-----+ +-----+   +---------+   +--------+ +-----+  |  +----------+
               \->|APN  | |APN  |-A-|APN      |-A-|APN     | |APN  |->/
   User side      |-    |-|-    |-B-|-        |-B-|-       |-|-    |      Server side
               /->|Edge | |Head |-C-|Midpoint |-C-|Endpoint| |Edge |->\
  +----------+ |  +-----+ +-----+   +---------+   +--------+ +-----+  |  +----------+
  |AI Agent 2|-/                                                      \->|AI Agent 4|
  +----------+    |------------------APN Domain--------------------|     +----------+

                    Figure 1: Using APN framework in IoA scenarios

     *  AI Agent: Interacts with other AI Agents on the internet, sending
        task requests, asynchronous notifications, and result responses to
        the others.  It can subscribe to network services from operators
        and optionally carry service requirement in the sent traffic via
        APN Attribute.  This means that the AI Agent behaves as an APN-
        capable Application Client or Server as defined in
        [I-D.li-rtgwg-apn-app-side-framework].

     *  APN-Edge: If AI Agents send traffic without APN attribute, APN-
        Edge device should obtain the APN attribute based on the
        configuration on this device according to the existing information
        in the packet header, create a tunnel encapsulation and add the
        APN attribute into it, and send the packets carrying the APN
        attribute to the APN-Head device finally.  When the packets are
        going to leave the APN domain, APN-Edge should remove the
        encapsulation if APN-Edge and APN-Endpoint are deployed
        separately.  Those are detailly defined in
        [I-D.li-rtgwg-apn-framework].  If the APN attribute is added by
        the AI Agent, the functionalities of the APN-Edge need to be
        changed.  APN-Edge can directly transmit the packets to APN-Head
        without encapsulating tunnels.  That is detailly defined in
        [I-D.li-rtgwg-apn-app-side-framework].





  Mao, et al.                Expires 5 May 2026                   [Page 7]


  Internet-Draft                 APN for IoA                 November 2025


     *  APN-Head: Identifies the service requirements of IoA based on the
        APN attribute in the packet and provides network services that
        meet these requirements.  This may involve encapsulating the
        packet with a new TE tunnel, placing the packet into an
        appropriate QoS queue, directing the packet to a network slice,
        adding or modifying some fields on the packet to perform network
        measurement, making access policy decisions, performing secondary
        encryption on the packet content, or diverting it to a secure
        channel.

     *  APN-Midpoint: APN-Midpoint provides the path service and enforces
        various policies according to the APN attribute carried in the
        packets.  The APN-Midpoint may also adjust the resource locally to
        guarantee the service requirements depending on a specific policy
        and the APN attribute conveyed by the packet.

     *  APN-Endpoint: the process of the specific network service will end
        at the APN-Endpoint.  If the outer tunnel header for the service
        between the APN-Head and the APN-Endpoint exists, it will be
        removed by the APN-Endpoint.  If the APN attribute is sent by AI
        Agents, the APN-Endpoint MUST keep the APN attribute in packets
        without any change.


  5.2.  Requirements


  5.2.1.  Requirements for AI Agents

     *  [REQ A01] AI Agent should support to subscribe network services
        from ISP, and get service requirement identifier or the usage
        authorization of service requirement metadata from ISP (out-band)
        or its APN-Controller.

     *  [REQ A02] AI Agent should support to describe the service status,
        the quality of users' experience (QoE), or the key quality
        indicators (KQI) in the APN attribute.

     *  [REQ A03] AI Agent should support to carry the APN attribute in
        the packets of the agent interaction traffic.

     *  TBD









  Mao, et al.                Expires 5 May 2026                   [Page 8]


  Internet-Draft                 APN for IoA                 November 2025


  5.2.2.  Requirements for Network Devices

     *  [REQ D01] APN-Head should support steering the packets based on
        APN attributes into a TE tunnel that satisfies the SLA
        requirements of the agent interaction.

     *  [REQ D02] APN-Head, APN-Midpoint and APN-Endpoint should support
        putting the packets based on APN attributes into a QoS queue
        buffer that satisfies the SLA requirement of the agent
        interaction.

     *  [REQ D03] APN-Head, APN-Midpoint and APN-Endpoint should support
        to steer the packets based on APN attributes into a network slice
        that satisfies the SLA requirement of the agent interaction.

     *  [REQ D04] APN-Head, APN-Midpoint and APN-Endpoint should support
        adding, modifying, or marking some fields of the packets based on
        APN attributes to perform network measurement that satisfies the
        measurement and visualization requirement of the agent
        interaction.

     *  [REQ D05] APN-Head should support enforcing access control to the
        packets based on APN attributes, in accordance with some security
        rules or policies that satisfy the security requirement of the
        agent interaction.

     *  TBD


  5.2.3.  Requirements for Network Controller

     *  [REQ C01] APN-Controller should support to notify the allocated
        results of the service requirement identifier, and the usage
        authorization of the service requirement metadata to AI Agent.

     *  [REQ C02] APN-Controller should support to analysis the measure
        data or path data of the agent interaction traffic reported from
        network devices to achieve traffic visualization and network
        troubleshooting.

     *  TBD

  5.2.4.  Requirements for Protocol Extensions

     *  [REQ P01] Protocol extensions should be defined for the AI Agent
        to request the APN-Controller in the network to allocated the APN
        resources of the APN domain.




  Mao, et al.                Expires 5 May 2026                   [Page 9]


  Internet-Draft                 APN for IoA                 November 2025


     *  [REQ P02] Security mechanism should be defined to guarantee for
        that the APN attribute being securely transmitted among the AI
        Agent(user side), AI Agent (server side) and the APN domain.

     *  TBD

  5.2.5.  Requirements for Security

     *  [REQ S01] The task contents of AI agent interactions should be
        protected or keep invisible.

     *  [REQ S02] The traffic of sensitive tasks should be steered into a
        secure channel for transmission, such as IPsec tunnels and quantum
        channels.

     *  TBD

  6.  IANA Considerations

     This document does not include an IANA request.


  7.  Security Considerations

     TBD


  8.  References

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

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

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

  8.2.  Informative References





  Mao, et al.                Expires 5 May 2026                  [Page 10]


  Internet-Draft                 APN for IoA                 November 2025


     [I-D.li-rtgwg-apn-app-side-framework]
                Li, Z. and S. Peng, "Extension of Application-aware
                Networking (APN) Framework for Application Side", Work in
                Progress, Internet-Draft, draft-li-rtgwg-apn-app-side-
                framework-00, 22 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-li-rtgwg-apn-
                app-side-framework-00>.

     [I-D.li-rtgwg-apn-framework]
                Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., and
                G. S. Mishra, "Application-aware Networking (APN)
                Framework", Work in Progress, Internet-Draft, draft-li-
                rtgwg-apn-framework-00, 4 March 2024,
                <https://datatracker.ietf.org/doc/html/draft-li-rtgwg-apn-
                framework-00>.

  Authors' Addresses

     Jianwei Mao
     Huawei Technologies
     Beijing
     100095
     China
     Email: MaoJianwei@huawei.com


     Zhenbin Li
     Huawei Technologies
     Email: robinli314@163.com


     Nan Geng
     Huawei Technologies
     Email: gengnan@huawei.com


     Chong Zheng
     Huawei Technologies
     Email: zhengchong6@huawei.com












  Mao, et al.                Expires 5 May 2026                  [Page 11]


name: draft-zeng-opsawg-llm-netconf-gap
rev: 00
title: Gap Analysis of Network Configuration Protocols in LLM-Driven Intent-Based Networking
time: 2025-11-02T12:16:18Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T12:16:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864751+00:00
abstract:
  Large Language Models (LLMs) are entering network operations through
     natural-language intent interfaces.  Existing south-bound protocols
     (NETCONF, RESTCONF, gNMI, MCP, A2A) were not designed for
     conversational, semantically-rich, multi-agent orchestration.  This
     document provides a systematic gap analysis and identifies extension
     points for each protocol to meet intent-based networking
     requirements.

full_text:
  Network Working Group                                            G. Zeng
  Internet-Draft                                                    J. Mao
  Intended status: Informational                                    B. Liu
  Expires: 6 May 2026                                              N. Geng
                                                                  X. Shang
                                                                    Q. Gao
                                                                     Z. Li
                                                                    Huawei
                                                           2 November 2025


   Gap Analysis of Network Configuration Protocols in LLM-Driven Intent-
                              Based Networking
                    draft-zeng-opsawg-llm-netconf-gap-00

  Abstract

     Large Language Models (LLMs) are entering network operations through
     natural-language intent interfaces.  Existing south-bound protocols
     (NETCONF, RESTCONF, gNMI, MCP, A2A) were not designed for
     conversational, semantically-rich, multi-agent orchestration.  This
     document provides a systematic gap analysis and identifies extension
     points for each protocol to meet intent-based networking
     requirements.

  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 6 May 2026.

  Copyright Notice

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





  Zeng, et al.               Expires 6 May 2026                   [Page 1]


  Internet-Draft               LLM Netconf Gap               November 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Gap Analysis per Protocol . . . . . . . . . . . . . . . . . .   3
       3.1.  MCP . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
         3.1.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   3
         3.1.2.  Solution Considerations . . . . . . . . . . . . . . .   4
       3.2.  A2A . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
         3.2.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   5
         3.2.2.  Solution Considerations . . . . . . . . . . . . . . .   7
       3.3.  NETCONF . . . . . . . . . . . . . . . . . . . . . . . . .   7
         3.3.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   7
         3.3.2.  Solution Considerations . . . . . . . . . . . . . . .   7
       3.4.  RESTCONF  . . . . . . . . . . . . . . . . . . . . . . . .   7
         3.4.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   7
         3.4.2.  Solution Considerations . . . . . . . . . . . . . . .   8
       3.5.  gNMI  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
         3.5.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   8
         3.5.2.  Solution Considerations . . . . . . . . . . . . . . .   8
     4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
     6.  Informative References  . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Intent-based networking (IBN) promises to translate high-level
     operator intent into network configuration without low-level syntax
     errors.  With the advent of LLMs, the interface moves from YAML/CLI
     to natural language.  Unfortunately, none of the current
     configuration or agent-to-agent protocols provide the semantic,
     transactional, and multi-agent primitives required by LLM-driven IBN.
     This draft analyses the gaps and proposes concrete extension
     directions for five widely deployed protocols.







  Zeng, et al.               Expires 6 May 2026                   [Page 2]


  Internet-Draft               LLM Netconf Gap               November 2025


  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", etc., are to be
     interpreted as described in [RFC2119].

     IBN, LLM, Agent, Intent, Tool, Artifact, and Task are used as defined
     in [I-D.ietf-opsawg-ibn-terminology].

  3.  Gap Analysis per Protocol

  3.1.  MCP

  3.1.1.  Gap Analysis

     The design goal of MCP is to give a single Large Language Model (LLM)
     a "plug-and-play" tool-calling capability.  When deployed directly
     between a network controller and the devices, however, the following
     structural gaps are exposed.

  3.1.1.1.  Lack of Network-Level Transaction Semantics

     MCP's tools/call is a stateless, one-shot JSON-RPC invocation.
     Network changes normally require the multi-stage semantics "candidate
     → validate → commit → rollback."  MCP has neither a candidate
     datastore nor two-phase-commit primitives.  Consequently, cross-
     device bulk deployments cannot guarantee "all-or-nothing" atomicity.
     When partial failures occur, the controller must supply its own
     compensation logic, lengthening the LLM's reasoning chain and
     increasing uncertainty.

  3.1.1.2.  No YANG Semantics Discovery Mechanism

     Today MCP tool descriptors are written by hand.  Network-device
     capabilities are authoritatively defined by YANG models; whenever a
     model is updated, the tool list must be manually re-synchronized.
     Without an automated pipeline "YANG → JSON-Schema → tool descriptor,"
     maintaining the tool catalogue in a large multi-vendor environment
     becomes a bottleneck.

  3.1.1.3.  Encoding and Bandwidth Bottlenecks

     Network-ops scenarios often involve high-frequency telemetry (5–60 s
     sampling, 10 k metrics per node).  MCP specifies only JSON-RPC over
     HTTP/1.1, resulting in highly redundant messages and no streaming
     push primitive.  When an LLM needs real-time anomaly detection,
     frequent polling consumes excessive bandwidth and CPU, violating
     data-center goals of low latency and high throughput.




  Zeng, et al.               Expires 6 May 2026                   [Page 3]


  Internet-Draft               LLM Netconf Gap               November 2025


  3.1.1.4.  Missing Multi-Device Context Correlation

     MCP's invocation context is confined to a single connection; it
     cannot natively carry network-level intent such as "change the same
     VLAN across three leaf switches while keeping the STP root bridge
     unchanged."  The LLM must repeat the constraints in the prompt,
     wasting tokens and raising the error rate.

  3.1.1.5.  Lack of Network Rollback and Audit Hooks

     Network operations require audit logs that "trace down to the leaf
     node."  MCP's tool return body contains only a JSON result; there are
     no standardized fields for rollback-point, commit-id, or syslog-
     severity.  Root-cause analysis and compliance audits therefore
     require additional integration with device syslog or NETCONF logs,
     increasing cost.

  3.1.1.6.  Incompatibility with Existing Device Security Models

     Devices commonly enforce certificate-based mutual-TLS plus NACM path-
     level permissions.  MCP currently defines only a Bearer-token header
     and offers no mapping between a tool call and the read/write/exec
     permissions on a YANG node.  If a tool-descriptor file leaks, an LLM
     could combine calls to bypass existing ACLs, creating a privilege-
     escalation risk.

  3.1.1.7.  Lifecycle and State-Management Gap

     Network changes often last several minutes (waiting for BGP
     convergence or MAC migration).  Once an MCP call completes, its
     context is discarded immediately, so there is no way to stream
     intermediate updates such as “convergence 90 %.” The LLM has no
     choice but to poll repeatedly, increasing load on both itself and the
     device while still failing to achieve a true state-machine-driven
     closed loop.

  3.1.2.  Solution Considerations

     For MCP to serve as "the universal glue between LLMs and devices" in
     production networks, an upper layer must supply a transactional state
     machine, a YANG self-description channel, streaming encodings, and
     fine-grained audit semantics.  Without these additions, MCP will
     remain confined to labs or single-device scripting and will be unable
     to close the loop on production-grade intent.







  Zeng, et al.               Expires 6 May 2026                   [Page 4]


  Internet-Draft               LLM Netconf Gap               November 2025


  3.2.  A2A

  3.2.1.  Gap Analysis

     Positioned as a "multi-agent collaboration layer," the Agent-to-Agent
     (A2A) protocol was created so that any two LLM-Agents can discover
     each other, negotiate, and jointly finish long-running tasks.  When
     it is dropped straight into "network-controller ↔ network-device" or
     "controller ↔ controller" settings, however, the following deep gaps
     surface:

  3.2.1.1.  Task Granularity Mismatch with Network Atomic Operations

     A2A Tasks target macro-level business goals (e.g., "relocate a DC").
     The smallest deliverable is an Artifact.  Network changes, by
     contrast, must touch a single YANG leaf (e.g., "set interface X MTU =
     9216").  The spec offers no "micro-task" primitive, so one Task
     either carries thousands of lines and becomes bloated, or is split
     into hundreds of Tasks that explode the state machine and raise LLM-
     orchestration complexity.

  3.2.1.2.  No Network-Wide Transaction or Roll-back Semantics

     A2A's state machine is limited to pending → working → completed/
     failed.  On failure the controller only gets a free-text
     Task.statusMessage.  Network ops demand cross-device atomic commit
     plus a rollback tag.  The protocol today defines no:

     *  two-phase-commit token (transaction-id),

     *  distributed lock or conflict detection,

     *  unified rollback API (rollback-on-failure).

     Controllers must therefore implement compensation themselves, forcing
     the LLM to reason about "how to write a rollback script," which
     violates intent-based principles.

  3.2.1.3.  Poor Encoding and Bandwidth Efficiency

     A2A mandates JSON for Artifact payloads and runs over HTTP/1.1.  For
     high-frequency telemetry (5 s interval, 10 k metrics/node) or bulk
     config pushes, JSON's textual redundancy causes:

     *  controller-device link congestion,

     *  wasted LLM-context tokens,




  Zeng, et al.               Expires 6 May 2026                   [Page 5]


  Internet-Draft               LLM Netconf Gap               November 2025


     *  repetitive header parsing and higher CPU load.

     The protocol lacks a binary or streaming encoding option and offers
     no back-pressure mechanism.

  3.2.1.4.  Missing Multi-Device Context Correlation

     A2A Task context is scoped to a single "conversation"; there is no
     standard field to express topology-level constraints such as "change
     the same VLAN on three leaf switches while keeping the STP root
     bridge unchanged."  The LLM must repeat inter-device relations in the
     prompt, burning tokens and risking truncation that produces
     configurations which are syntactically valid but topologically wrong.

  3.2.1.5.  Incompatibility with Existing Device Security Models

     Devices generally enforce certificate-based mutual TLS plus NACM
     path-level access control.  A2A currently specifies only an OAuth2
     delegation token and provides no mapping from "Task-level role" to
     YANG node read/write/exec permissions, nor per-Artifact fine-grained
     ACLs.  Once an Artifact is cached or forwarded it may bypass the
     certificate chain, leading to privilege escalation or configuration
     pollution.

  3.2.1.6.  No Network-Semantics Discovery Mechanism

     Skills are advertised in the Agent Card, but the Card is free text.
     There are no standard fields saying "I support OpenConfig BGP 4.0
     YANG" or "I manage AS 65001-65500."  LLMs must rely on fuzzy
     matching, often selecting the wrong partner and raising Task failure
     rates.

  3.2.1.7.  Life-Cycle and Intermediate-State Reporting Gap

     Network changes can last minutes (waiting for BGP convergence, MAC
     moves).  After a Task enters "working," A2A only mandates a final
     Artifact; there is no standard way to push interim states such as
     "convergence 70 %" or "MTU changed, waiting for LLDP neighbor re-
     discovery."  The LLM must poll or wait until timeout, increasing load
     and preventing a true state-machine-driven closed loop.











  Zeng, et al.               Expires 6 May 2026                   [Page 6]


  Internet-Draft               LLM Netconf Gap               November 2025


  3.2.2.  Solution Considerations

     To act as a "multi-agent collaboration bus" in network environments,
     A2A must be systematically extended in task granularity, transaction
     semantics, binary encoding, topology context, security mapping, life-
     cycle management, and intermediate-state push.  Otherwise it will
     remain suited only for macro business flows and will be unable to
     close the fine-grained, reliable, and roll-backable network-intent
     loop required in production.

  3.3.  NETCONF

  3.3.1.  Gap Analysis

     NETCONF [RFC6241] provides transactional, XML-encoded RPCs over SSH.
     It lacks:

     *  Semantic discovery: YANG models are not self-describing for LLMs;
        no runtime tool list.

     *  Session context: no standard place to store intent-id, LLM prompt,
        or multi-device correlation.

     *  Streaming telemetry: <notification> is push-style but insufficient
        for high-frequency KPI.

     *  Function-level audit: <commit> is atomic, but per-leaf
        authorization is out-of-scope.

  3.3.2.  Solution Considerations

     TBD

  3.4.  RESTCONF

  3.4.1.  Gap Analysis

     RESTCONF [RFC8040] maps YANG to HTTP URIs.  Gaps include:

     *  No candidate datastore—every PUT/PATCH is immediate.

     *  No server-side discovery document for LLMs.

     *  Stateless: no place to store multi-request intent.

     *  Encoding flexibility may confuse LLM prompt consistency.





  Zeng, et al.               Expires 6 May 2026                   [Page 7]


  Internet-Draft               LLM Netconf Gap               November 2025


  3.4.2.  Solution Considerations

     TBD

  3.5.  gNMI

  3.5.1.  Gap Analysis

     gNMI delivers high-speed telemetry but:

     *  No semantic metadata for LLMs.

     *  Set() is non-transactional across multiple paths.

     *  No multi-agent signalling—gNMI is 1:1.

     *  No standardized error ontology.

  3.5.2.  Solution Considerations

     TBD

  4.  Summary

     No single protocol satisfies all IBN-LLM requirements.
     NETCONF/RESTCONF/gNMI need semantic and transactional extensions;
     MCP/A2A need networking-specific profiling.  A companion document
     will define unified data models and security frameworks to close the
     identified gaps.

  5.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", 1997.

     [RFC6241]  Enns, R., "Network Configuration Protocol (NETCONF)",
                2011.

     [RFC8040]  Bierman, A., "RESTCONF Protocol", 2017.

     [RFC9457]  Nottingham, M., "Problem Details for HTTP APIs", 2023.

     [OpenConfig-gNMI]
                Team, OpenConfig., "gNMI Specification", 2022.

     [MCP-spec] Inc, Anthropic., "Model Context Protocol", 2024.

     [A2A-spec] LLC, Google., "Agent-to-Agent Protocol", 2025.



  Zeng, et al.               Expires 6 May 2026                   [Page 8]


  Internet-Draft               LLM Netconf Gap               November 2025


  6.  Informative References

     [I-D.ietf-opsawg-ibn-terminology]
                IETF, "Intent-Based Networking Terminology", 2025.

  Authors' Addresses

     Guanming Zeng
     Huawei
     Email: zengguanming@huawei.com


     Jianwei Mao
     Huawei
     Email: maojianwei@huawei.com


     Bing Liu
     Huawei
     Email: leo.liubing@huawei.com


     Nan Geng
     Huawei
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei
     Email: shangxiaotong@huawei.com


     Qiangzhou Gao
     Huawei
     Email: gaoqiangzhou@huawei.com


     Zhenbin Li
     Huawei
     Email: robinli314@163.com











  Zeng, et al.               Expires 6 May 2026                   [Page 9]


name: draft-zeng-opsawg-applicability-mcp-a2a
rev: 00
title: When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced Network Management Scenarios
time: 2025-11-02T12:22:28Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T12:22:28Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:08.642487+00:00
abstract:
  NETCONF provides robust configuration transactions and YANG-based
     data models, but falls short in scenarios requiring AI-driven
     semantic translation, long-lived cross-domain orchestration, multi-
     agent consensus, rapid DevOps iteration, or delivery of large non-
     configuration artifacts.  This document systematically analyzes the
     functional gaps and presents Model Context Protocol (MCP) and Agent-
     to-Agent (A2A) as complementary solutions.  Implementation guidance
     and coexistence models are also provided.

full_text:
  Network Working Group                                            G. Zeng
  Internet-Draft                                                    J. Mao
  Intended status: Standards Track                                  B. Liu
  Expires: 6 May 2026                                              N. Geng
                                                                  X. Shang
                                                                    Q. Gao
                                                                     Z. Li
                                                                    Huawei
                                                           2 November 2025


   When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced
                        Network Management Scenarios
                 draft-zeng-opsawg-applicability-mcp-a2a-00

  Abstract

     NETCONF provides robust configuration transactions and YANG-based
     data models, but falls short in scenarios requiring AI-driven
     semantic translation, long-lived cross-domain orchestration, multi-
     agent consensus, rapid DevOps iteration, or delivery of large non-
     configuration artifacts.  This document systematically analyzes the
     functional gaps and presents Model Context Protocol (MCP) and Agent-
     to-Agent (A2A) as complementary solutions.  Implementation guidance
     and coexistence models are also provided.

  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 6 May 2026.

  Copyright Notice

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




  Zeng, et al.               Expires 6 May 2026                   [Page 1]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Gap Analysis Summary  . . . . . . . . . . . . . . . . . . . .   3
     3.  When MCP Must Be Used . . . . . . . . . . . . . . . . . . . .   3
       3.1.  AI Natural-Language Intent  . . . . . . . . . . . . . . .   4
       3.2.  Rapid Model Iteration (DevOps Week-Release) . . . . . . .   5
     4.  When A2A Must Be Used . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Cross-Controller Long-Flow Orchestration  . . . . . . . .   6
       4.2.  Multi-Agent Consensus (Agent-to-Agent)  . . . . . . . . .   8
     5.  Coexistence Model . . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Design Choices at a Glance  . . . . . . . . . . . . . . .  10
       5.2.  Common Layering . . . . . . . . . . . . . . . . . . . . .  10
       5.3.  Controller-Gateway Model  . . . . . . . . . . . . . . . .  10
       5.4.  Device-Embedded Model . . . . . . . . . . . . . . . . . .  10
       5.5.  Migration Roadmap . . . . . . . . . . . . . . . . . . . .  10
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     7.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
     8.  Informative References  . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     NETCONF [RFC6241] remains the gold standard for network configuration
     transactions.  However, five emerging scenarios expose its
     fundamental limitations:

     *  (1) AI natural-language intent

     *  (2) Long-flow cross-controller orchestration

     *  (3) multi-agent consensus

     *  (4) weekly DevOps release cycles

     *  (5) multi-modal artifact delivery






  Zeng, et al.               Expires 6 May 2026                   [Page 2]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


     This document identifies objective gaps and specifies when and how
     MCP [I-D.yang-nmrg-mcp-nm] and A2A [I-D.google-agent2agent] should be
     engaged.

  2.  Gap Analysis Summary

     This section enumerates the fundamental gaps between NETCONF and the
     advanced management scenarios introduced in Section 1.  For each gap,
     the table below identifies:

     *  the missing capability,

     *  its root cause in NETCONF design, and

     *  the protocol (MCP or A2A) that natively provides it.

       +===================+=======================+==================+
       | Gap               | Root Cause in NETCONF | MCP/A2A Solution |
       +===================+=======================+==================+
       | AI Semantic Layer | XML-centric, no       | MCP /tools/list  |
       |                   | function registry     | + JSON-Schema    |
       +-------------------+-----------------------+------------------+
       | Long-Flow         | No Task life-cycle or | A2A Task state   |
       | Orchestration     | human-in-the-loop     | machine          |
       +-------------------+-----------------------+------------------+
       | Multi-Agent       | Client-server only;   | A2A AgentCard +  |
       | Consensus         | no peer negotiation   | Message          |
       +-------------------+-----------------------+------------------+
       | Weekly DevOps     | YANG revision 6-9     | MCP Tool hot-    |
       | Iteration         | months; firmware lock | register         |
       +-------------------+-----------------------+------------------+
       | Large Artifact    | 64 kB chunk; no       | MCP/A2A Artifact |
       | Delivery          | MIME/hash/URL         | (cloud URL)      |
       +-------------------+-----------------------+------------------+

                                   Table 1

     The gaps are not implementation defects but architectural invariants
     of RFC 6241.  They become blocking only in the five advanced
     scenarios identified.  Outside these scenarios, NETCONF continues to
     provide the most robust configuration transactions and should remain
     the south-bound protocol of choice.

  3.  When MCP Must Be Used







  Zeng, et al.               Expires 6 May 2026                   [Page 3]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


  3.1.  AI Natural-Language Intent

     Operators increasingly expect to issue instructions in natural
     language: “Raise MTU to 9000 for all Beijing core switches” or “Block
     source 1.2.3.4 for 30 minutes”.  NETCONF requires an edit-config XML
     blob with exact leaf names and namespaces; even experienced engineers
     make syntax mistakes under time pressure.

     The root cause is architectural:

     *  XML is attribute-heavy and case-sensitive; forgotten namespaces or
        mismatched quotes silently fail.

     *  There is no machine-discoverable “function catalogue” — an LLM
        must rely on static prompt examples which drift as models evolve.

     *  Multi-vendor differences (OpenConfig vs. proprietary YANG) force
        the LLM to choose branches inside the XML, exploding prompt size.

     MCP solves these issues with three primitives:

     *  /tools/list — JSON array of callable functions, each carrying
        human-readable description and JSON-Schema input.

     *  JSON-Schema — strong-typed, no namespaces, direct mapping to
        primitive types (string, integer, enum, array).

     *  JSON-RPC 2.0 — single-line request/response, easily parsed by LLM
        and by controller gateways.

     Example MCP Tool Descriptor (simplified):

     {
       "name": "batch_set_mtu",
       "description": "Set interface MTU on multiple devices",
       "inputSchema": {
         "type": "object",
         "properties": {
           "device_group": {"type": "string"},
           "mtu": {"type": "integer", "minimum": 576, "maximum": 9216}
         },
         "required": ["device_group", "mtu"]
       }
     }

                                    Figure 1

     The LLM now produces:



  Zeng, et al.               Expires 6 May 2026                   [Page 4]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


     {
       "jsonrpc": "2.0",
       "method": "batch_set_mtu",
       "params": {"device_group": "beijing-core", "mtu": 9000},
       "id": 1
     }

                                    Figure 2

  3.2.  Rapid Model Iteration (DevOps Week-Release)

     Cloud-era value-added services must be deployed within days, not
     months.  NETCONF's revision cycle (IETF draft → RFC: 6-9 months) and
     firmware upgrade windows (≤ 1 per year) are incompatible with weekly
     release trains.  The blocking points are:

     *  YANG module must be burned into firmware before the first config
        leaf is usable;

     *  Controller regression suite recompiles the entire YANG tree even
        for a single new leaf;

     *  Backward-compatibility review (must not break old devices)
        stretches internal QA to weeks.

     MCP breaks the deadlock by treating "intent" as a hot-swappable Tool
     rather than a permanent YANG node:

     *  Private YANG is compiled to JSON-Schema in the controller
        (milliseconds);

     *  Tool registers via /tools/register and is immediately callable;

     *  Gray-list rollout (10 % → 30 % → 100 %) and instant rollback (re-
        register previous Tool) are done without touching device flash.

     Example: Cloud-Shield DDoS Cleaning Service

     Private YANG (120 lines)
       +--rw start-cleanse
       | +--rw target-ip      inet:ipv4-address
       | +--rw bandwidth-Mbps uint32
       | +--rw duration-min   uint16

                                    Figure 3

     Compiled JSON-Schema and registered in 30 s:




  Zeng, et al.               Expires 6 May 2026                   [Page 5]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


  {
    "name": "start_cleanse",
    "version": "1.0.0",
    "description": "Start DDoS cleanse for target IP",
    "inputSchema": {
      "type": "object",
      "properties": {
        "target_ip": {"type": "string", "format": "ipv4"},
        "bandwidth_Mbps": {"type": "integer", "minimum": 100, "maximum": 100000},
        "duration_min": {"type": "integer", "minimum": 5, "maximum": 1440}
      },
      "required": ["target_ip", "bandwidth_Mbps"]
    }
  }

                                 Figure 4

     Thus MCP is mandatory for any management surface that must support
     weekly or daily release cycles without waiting for firmware or
     standards body timelines.

  4.  When A2A Must Be Used

  4.1.  Cross-Controller Long-Flow Orchestration

     Maintenance windows for core-network upgrades often exceed 30 minutes
     and span multiple vendor domains.  NETCONF provides atomic
     configuration on a single controller, but lacks:

     *  a cross-vendor task life-cycle,

     *  human-in-the-loop approval gates, and

     *  delivery of large artifacts (firmware, images, diff reports).

     A2A fills these gaps with three primitives:

     *  Task — state machine (pending → working → completed/failed/
        cancelled) persisting across agent restarts;

     *  Artifact — hash-signed object store (≤ 2 GB, resumable upload);

     *  Message — multi-round negotiation (JSON or natural language).








  Zeng, et al.               Expires 6 May 2026                   [Page 6]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


       +=========================+================+===================+
       | State                   | Meaning        | NETCONF           |
       |                         |                | Equivalent        |
       +=========================+================+===================+
       | pending                 | Waiting for    | None (RPC is      |
       |                         | resources or   | fire-and-forget)  |
       |                         | approval       |                   |
       +-------------------------+----------------+-------------------+
       | awaiting-human-approval | Human must     | None              |
       |                         | click approve/ |                   |
       |                         | cancel         |                   |
       +-------------------------+----------------+-------------------+
       | working                 | Agents         | edit-config       |
       |                         | executing sub- | (local only)      |
       |                         | tasks          |                   |
       +-------------------------+----------------+-------------------+
       | completed               | All agents     | commit            |
       |                         | report success |                   |
       +-------------------------+----------------+-------------------+
       | failed                  | Any agent      | rollback-on-error |
       |                         | reports        |                   |
       |                         | failure        |                   |
       +-------------------------+----------------+-------------------+
       | cancelled               | Operator or    | discard-changes   |
       |                         | policy         |                   |
       |                         | cancelled      |                   |
       +-------------------------+----------------+-------------------+

               Table 2: A2A Task States vs. NETCONF Operations

     Real-World Example: Five-City Core MTU Migration

     Controllers: Huawei NCE (3 cities) + Cisco NSO (2 cities)
     Devices: 312 PE routers
     Window: 120 min (02:00-04:00)
     Artifact: 2 GB firmware image + 40 MB diff-report

                                    Figure 5

     Step-wise A2A Flow (time-stamps):

     *  T+0 min: Orchestrator creates Task T100, goal="Raise MTU to 9000
        on core links".

     *  T+5 min: Each controller Agent posts Artifact pre-check.csv (link
        health KPI).





  Zeng, et al.               Expires 6 May 2026                   [Page 7]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


     *  T+10 min: Orchestrator Artifact hash-verified; human approval card
        sent to WeChat.

     *  T+15 min: Engineer clicks "approve"; Task state → working.

     *  T+20-90 min: Controllers download 2 GB image via Artifact URL;
        local NETCONF edit-config issued; progress Artifacts streamed
        every 5 min.

     *  T+95 min: Last Artifact post-upgrade-verification.csv uploaded.

     *  T+100 min: All agents report success; Task → completed.  Total
        human intervention: 1 click.

     A2A is mandatory for any multi-vendor, multi-hour workflow that
     demands task persistence, human gates, and multi-gigabyte artifact
     delivery—scenarios where NETCONF's single-controller, single-RPC
     paradigm is insufficient.

  4.2.  Multi-Agent Consensus (Agent-to-Agent)

     Fault recovery, security mitigation and resource optimisation often
     require multiple autonomous agents (monitoring, security, controller,
     human) to reach a common decision.  NETCONF's strict client-server
     model provides no peer-to-peer capability advertisement, multi-round
     negotiation or voting primitives.

     A2A introduces three building blocks:

     *  AgentCard — JSON-LD advertisement of skills and endpoint;

     *  Message — multi-round negotiation (JSON or natural language);

     *  Consensus Engine — policy-based scoring, voting, human-in-the-
        loop.
















  Zeng, et al.               Expires 6 May 2026                   [Page 8]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


       +================+==================+==========================+
       | Field          | Description      | Example Value            |
       +================+==================+==========================+
       | id             | globally unique  | monitor-sh-01            |
       |                | agent identifier |                          |
       +----------------+------------------+--------------------------+
       | skills         | array of skill   | {name: "threat_analyze", |
       |                | objects (name,   | desc: "Return 0-10       |
       |                | description)     | threat score"}           |
       +----------------+------------------+--------------------------+
       | endpoint       | HTTPS URL for    | https://mon-             |
       |                | A2A messages     | sh.example:9443/a2a      |
       +----------------+------------------+--------------------------+
       | authentication | mTLS + OIDC      | {"type": "mTLS",         |
       |                |                  | "sha256": "8f66..."}     |
       +----------------+------------------+--------------------------+

                     Table 3: AgentCard Mandatory Fields

     Consensus Flow Example: DDoS Port Shutdown

     Agents: Monitor, Security, Controller, Human
     Decision: shutdown port 10/1 ?
     Scoring: threat_level×0.6 + impact×0.4
     Threshold: ≥ 5.0 → shutdown

                                    Figure 6

     Message Sequence (time-stamps):

     *  T+0 s: Monitor Agent posts threat_score=9.0 via Message.

     *  T+5 s: Security Agent confirms attack signature; score unchanged.

     *  T+10 s: Controller Agent posts impact=300 VPN down; computed score
        = 9×0.6 + 3×0.4 = 6.6 (> 5.0).

     *  T+12 s: Task state → awaiting-human-approval; WeChat card sent.

     *  T+135 s: Human clicks "approve".

     *  T+140 s: Controller Agent calls NETCONF shutdown; Artifact post-
        action.log uploaded.

     *  T+180 s: All agents report success; Task → completed.






  Zeng, et al.               Expires 6 May 2026                   [Page 9]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


     Therefore A2A is mandatory whenever multiple autonomous agents must
     discover, negotiate, vote and reach a binding decision — scenarios
     that NETCONF's unidirectional client-server paradigm cannot emulate.

  5.  Coexistence Model

     This section describes how MCP and A2A can be deployed _without_
     forcing a redesign of the existing NETCONF ecosystem.  The
     architecture keeps NETCONF as the configuration authority and allows
     _either_ controller-hosted _or_ device-hosted MCP servers — the
     latter avoids a central gateway bottleneck while preserving operator
     investment in controllers.

  5.1.  Design Choices at a Glance

     TBD

  5.2.  Common Layering

     TBD

  5.3.  Controller-Gateway Model

     TBD

  5.4.  Device-Embedded Model

     TBD

  5.5.  Migration Roadmap

     TBD

  6.  Security Considerations

     MCP and A2A introduce OAuth2/JWT and long-lived Tasks.

  7.  Normative References

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

     [RFC9200]  Tschofenig, H., "Guidelines for Using the Transport Layer
                Security (TLS) Protocol in Devices", RFC 9200,
                DOI 10.17487/RFC9200, March 2022,
                <https://www.rfc-editor.org/rfc/rfc9200>.



  Zeng, et al.               Expires 6 May 2026                  [Page 10]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


  8.  Informative References

     [I-D.yang-nmrg-mcp-nm]
                Yang, Y., "Applicability of MCP for the Network
                Management", Work in Progress, Internet-Draft, draft-yang-
                nmrg-mcp-nm-00, July 2025,
                <https://datatracker.ietf.org/doc/html/draft-yang-nmrg-
                mcp-nm-00>.

     [I-D.google-agent2agent]
                Google., "Agent-to-Agent (A2A) Protocol", Work in
                Progress, Internet-Draft, draft-google-agent2agent-00, May
                2025, <https://datatracker.ietf.org/doc/html/draft-google-
                agent2agent-00>.

  Authors' Addresses

     Guanming Zeng
     Huawei
     Email: zengguanming@huawei.com


     Jianwei Mao
     Huawei
     Email: maojianwei@huawei.com


     Bing Liu
     Huawei
     Email: leo.liubing@huawei.com


     Nan Geng
     Huawei
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei
     Email: shangxiaotong@huawei.com


     Qiangzhou Gao
     Huawei
     Email: gaoqiangzhou@huawei.com






  Zeng, et al.               Expires 6 May 2026                  [Page 11]


  Internet-Draft                 MCP-A2A-Gap                 November 2025


     Zhenbin Li
     Huawei
     Email: robinli314@163.com
















































  Zeng, et al.               Expires 6 May 2026                  [Page 12]


name: draft-liu-saag-zt-problem-statement
rev: 00
title: Zero trust standards in IETF: use cases and problem statement
time: 2025-11-02T13:41:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T13:41:43Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:12.944685+00:00
abstract:
  The traditional "castle-and-moat" security paradigm is no longer
     effective for some emerging scenarios, such as cloud services, remote
     workforces and intelligent agents.  Zero trust (ZT) has emerged as
     the new paradigm, holding on the "never trust, always verify"
     principle, treats every single access request as untrudted and
     requires veficication.

     While a high-level atchitectural guidance exists, notably from NIST
     in SP 800-207 where thtenants of zero trust are well interperated,
     the industry lacks the open, interoperable framework and protocol
     necessary for building multi-vendor zero trust practice enrironment.
     This document presents the problem statement for zero trust
     interoperability, outlines the key use cases, and argue for the need
     for standardization in the IETF.  It discusses the possible scope for
     zero trust standardization work in the IETF, identifying which
     aspects are well suited for the IETF protocols and which are better
     addressed by other bodies.  The aim of this document is to initiate a
     discussion in the IETF community on the necessity and prospective of
     promoting zero trust related work here.

full_text:
  SAAG                                                              X. Liu
  Internet-Draft                                                   R. Yang
  Intended status: Informational                                  Y. Zhang
  Expires: 6 May 2026                                 Pengcheng Laboratory
                                                           2 November 2025


       Zero trust standards in IETF: use cases and problem statement
                   draft-liu-saag-zt-problem-statement-00

  Abstract

     The traditional "castle-and-moat" security paradigm is no longer
     effective for some emerging scenarios, such as cloud services, remote
     workforces and intelligent agents.  Zero trust (ZT) has emerged as
     the new paradigm, holding on the "never trust, always verify"
     principle, treats every single access request as untrudted and
     requires veficication.

     While a high-level atchitectural guidance exists, notably from NIST
     in SP 800-207 where thtenants of zero trust are well interperated,
     the industry lacks the open, interoperable framework and protocol
     necessary for building multi-vendor zero trust practice enrironment.
     This document presents the problem statement for zero trust
     interoperability, outlines the key use cases, and argue for the need
     for standardization in the IETF.  It discusses the possible scope for
     zero trust standardization work in the IETF, identifying which
     aspects are well suited for the IETF protocols and which are better
     addressed by other bodies.  The aim of this document is to initiate a
     discussion in the IETF community on the necessity and prospective of
     promoting zero trust related work here.

  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 6 May 2026.



  Liu, et al.                Expires 6 May 2026                   [Page 1]


  Internet-Draft   Zero trust standards in IETF: use cases   November 2025


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Use Case 1: Secure Remote Access for Enterprise
             Resources . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.2.  Use case 2: secure service-to-service communication . . .   4
       4.3.  Use Case 3: Granular Access to Third-Party SaaS
             Applications  . . . . . . . . . . . . . . . . . . . . . .   4
       4.4.  Use Case 4: Secure Access for Autonomous AI Agents  . . .   4
     5.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.  Lack of interoperability  . . . . . . . . . . . . . . . .   5
       5.2.  Market Confusion  . . . . . . . . . . . . . . . . . . . .   5
       5.3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Proposed Scope of Work for the IETF . . . . . . . . . . . . .   6
       6.1.  Control Plane Communication Protocol  . . . . . . . . . .   6
       6.2.  Dynamic Context and Signal Exchange Protocol  . . . . . .   7
       6.3.  Authenticated Session Establishment and Management  . . .   7
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     Traditional network security was built on the assumption of that
     every entity inside the perimeter were trusted by default.  This
     approach is increasingly ineffective in face of new use cases and
     sophisticateed attackers.





  Liu, et al.                Expires 6 May 2026                   [Page 2]


  Internet-Draft   Zero trust standards in IETF: use cases   November 2025


     Zero Trust (ZT) offers a fundamentally different approach.  As d
     efined in [NIST-SP-800-207], Zero Trust assumes no implicit trust is
     granted to assets or user accounts based solely on their physical or
     network location.  Instead, authentication and authorization are
     discrete, dynamic functions that must be performed before a session
     is established to an enterprise resource.  This is a "never trust,
     always verify" model.

     While this conceptual framework is powerful, its practical
     implementation is hampered by a lack of open standards.  Today's ZT
     solutions are largely proprietary, single-vendor ecosystems.  An
     organization cannot easily use a Policy Enforcement Point (PEP) from
     one vendor with a Policy Decision Point (PDP) from another.

     This document provides a gap analysis for zero trust standardization,
     as well as several typical use cases.  In additon, it also discusses
     the scope of standardization of zero trust in the IETF.

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

  3.  Terminology

     This document adopts the core terminology defined in
     [NIST-SP-800-207].

     Subject:  An entity (e.g., user, device, service, application, AI
        agent) that requests access to a resource.

     Resource:  A data source, service, device, or network component that
        a subject wishes to access.

     Policy Engine (PE):  The component responsible for the ultimate
        decision to grant or deny access to a resource for a given
        subject.

     Policy Administrator (PA):  The component responsible for
        establishing and/or shutting down the communication path between a
        subject and a resource.

     Policy Enforcement Point (PEP):  A system responsible for enabling,





  Liu, et al.                Expires 6 May 2026                   [Page 3]


  Internet-Draft   Zero trust standards in IETF: use cases   November 2025


        monitoring, and terminating connections between a subject and a
        resource.  The PEP communicates with the PA to forward requests
        and/or receive policy updates.

     Control Plane:  The logical network of communication that is used to
        manage the ZTA.  This includes communication between the PE, PA,
        and PEPs, as well as the collection of context and signals.

     Data Plane:  The logical network where subjects and resources
        communicate after access has been granted.

  4.  Use cases

     In this section we consider several emerging use cases where
     standardized ZT protocols would provide significant value.

  4.1.  Use Case 1: Secure Remote Access for Enterprise Resources

     A remote employee needs to access an internal application hosted in a
     private data center of an organization.

     1.  Subject: The employee's user identity and the device identity.
     2.  Resource: The internal application.

  4.2.  Use case 2: secure service-to-service communication

     A front-end web service running in a Kubernetes cluster in Cloud A
     needs to query a database service running in a VM in Cloud B.

     1.  Subject: The front-end web service, identified by a workload
         identity.
     2.  Resource: The database service.

  4.3.  Use Case 3: Granular Access to Third-Party SaaS Applications

     An organization wants to enforce device posture checks before
     allowing employees to access a third-party SaaS application .

     1.  Subject: The employee and their device.
     2.  Resource: The SaaS CRM application.

  4.4.  Use Case 4: Secure Access for Autonomous AI Agents

     An autonomous AI agent, acting on behalf of a user or system, needs
     to access a set of APIs to complete a task (e.g., booking travel).

     1.  Subject: The AI agent, possessing a cryptographically verifiable
         workload identity.



  Liu, et al.                Expires 6 May 2026                   [Page 4]


  Internet-Draft   Zero trust standards in IETF: use cases   November 2025


     2.  Resource: A set of airline, hotel, and payment gateway APIs.

  5.  Problem statement

     The implementation of zero trust is hindered by several key problems
     that may be addressed by standardization.

  5.1.  Lack of interoperability

     The core components of ZTA, PE, PA and PEP currently communicate with
     each other using proprietary protocols.  Different components from
     different vendors can barely communicate and interoperate with each
     other.  This makes an organization wishing to implenment ZTA system
     probably forced to source all components from one single vendor.
     This creates silos where the ZT system for employee access is
     completely separate from the ZT system for cloud service-to-service
     communication, even though the underlying principles are the same.  A
     unified approach requires common standards.

  5.2.  Market Confusion

     Without clear, protocol-level definitions and specifications, the
     term "zero trust" is often used as marketing buzzword rather than
     technology or product langauge.  Products with different capabilities
     and features can be all labeled as "zero trust enabled".
     Standardization can enhance clarity by clearly document the
     requirements for components to participate in ZTA system from the
     protocol and funtionality level.

  5.3.  Gap Analysis

     While the IETF and other SDOs have produced fundamental building
     blocks, there still lacks a complete, interoperable ZT standard
     framework.  A significant gap exists between the available components
     and a functioning ZTA control plane.  Specifically, the main gaps can
     be concluded as follows.

     1.  *A Standardized Control Plane Protocol:* This is the central gap.
         There is no standard protocol for a PEP to request an access
         decision from a PE, nor for the PE/PA to return a dynamic policy
         decision.  Today, this critical interaction is implemented with
         proprietary REST APIs with vendor-specific data models.









  Liu, et al.                Expires 6 May 2026                   [Page 5]


  Internet-Draft   Zero trust standards in IETF: use cases   November 2025


     2.  *A Standardized Signal Exchange Protocol:* A PE's decisions rely
         on continuous streams of context (signals).  While RATS defines
         attestation formats, there is no standard protocol for how
         diverse sources (EDR systems, threat feeds, IdPs) publish these
         signals and how a PE consumes them.  This prevents the creation
         of a multi- vendor "nervous system" for the ZTA.

     3.  *A Model for Dynamic, Fine-Grained Authorization:* OAuth scopes
         are often broad and long-lived.  ZT demands just-in-time, least-
         privilege access.  A standard is needed to model a request for,
         and issuance of, highly specific and ephemeral access rights
         (e.g., "grant subject X write access to record Y in database Z
         for the next 30 seconds").

     4.  *A framework for dynamic and continuous trust evaluation:* The
         core principle of Zero Trust is continuous verification.  This
         implies a mechanism for dynamically evaluating the
         trustworthiness of a subject over time.  While individual signals
         (like device posture or user location) are important, there is no
         standardized framework for aggregating these signals into a
         dynamic trust score or confidence level.  Furthermore, there is
         no standard protocol for how this trust score is updated in near-
         real-time and communicated to the Policy Engine to influence
         access decisions.  Defining such a framework would enable
         interoperable trust assessment modules and allow the PE to make
         more nuanced, risk-based decisions beyond a simple grant/deny.

  6.  Proposed Scope of Work for the IETF

     To be successful, an IETF effort must have a clearly defined scope.
     We propose focusing on the communication interfaces between ZTA
     components, directly addressing the gaps identified in Section 5.3.

  6.1.  Control Plane Communication Protocol

     The highest priority is to define a standard protocol for a PEP to
     request an access decision from a PE/PA and for the PE/PA to return a
     decision and policy configuration.  This could be a new protocol or a
     profile of an existing one (e.g., using HTTP APIs with a well-defined
     JSON data model).  It must specify how to represent the subject,
     resource, and context in a request, and how to represent grant, deny,
     or step-up authentication decisions in a response.









  Liu, et al.                Expires 6 May 2026                   [Page 6]


  Internet-Draft   Zero trust standards in IETF: use cases   November 2025


  6.2.  Dynamic Context and Signal Exchange Protocol

     A ZTA's decisions are only as good as the signals it receives.  A
     standardized protocol is needed for various sensors (e.g., EDR
     agents, threat intelligence feeds, IdPs) to publish signals to a
     centralized bus or directly to the PE.  This would allow a PE to
     consume signals from multiple vendors' security tools.  This work
     should align with and leverage concepts from the IETF RATS and SCITT
     working groups.

  6.3.  Authenticated Session Establishment and Management

     While TLS provides a secure channel, ZTA introduces new challenges.
     Work could be done to standardize how a PA instructs a PEP to
     establish a session.  This might involve profiling the use of
     existing protocols or defining mechanisms for securely delivering
     short-lived, session-specific credentials (e.g., tokens or
     certificates) to the subject and/or PEP as part of an access grant.

  7.  IANA Considerations

     This memo includes no request to IANA.

  8.  References

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

     [NIST-SP-800-207]
                Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
                "Zero Trust Architecture", August 2020,
                <https://csrc.nist.gov/publications/detail/sp/800-207/
                final>.

  8.2.  Informative References

  Authors' Addresses






  Liu, et al.                Expires 6 May 2026                   [Page 7]


  Internet-Draft   Zero trust standards in IETF: use cases   November 2025


     Xiang Liu
     Pengcheng Laboratory
     No.2 Xingke 1 Street
     Shenzhen
     518055
     China
     Email: liux15@pcl.ac.cn


     Rongwei Yang
     Pengcheng Laboratory
     No.2 Xingke 1 Street
     Shenzhen
     518055
     China
     Email: yangrw@pcl.ac.cn


     Yu Zhang
     Pengcheng Laboratory
     No.2 Xingke 1 Street
     Shenzhen
     518055
     China
     Email: zhangy08@pcl.ac.cn


























  Liu, et al.                Expires 6 May 2026                   [Page 8]


name: draft-akhavain-moussa-ai-network
rev: 01
title: AI Network for Training, Inference, and Agentic Interactions
time: 2025-11-02T18:53:57Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T18:53:57Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:09.773526+00:00
abstract:
  Artificial Intelligence (AI) is rapidly transforming industries and
     everyday life, fueled by advances in model architectures, training
     paradigms, and data infrastructure for generation and consumption.
     Today, machine learning models are embedded in many of our daily
     activities, ranging from simple classification systems to advanced
     architectures such as large language models (LLMs) like ChatGPT,
     Claude, Grok, and DeepSeek.  These models highlight the
     transformative potential of AI across diverse applications—from
     productivity tools to complex decision-making systems.

     However, the effectiveness and reliability of AI depend on two
     foundational processes: training and inference.  Each process
     introduces unique challenges related to data management, computation,
     connectivity, privacy, trust, security, and governance.

     In this draft, we introduce the Data and Agent Aware-Inference and
     Training Network (DA-ITN)—a unified, intelligent, multi-plane network
     architecture designed to address the full spectrum of requirements
     needed to enable AI networks.  DA-ITN provides a scalable and
     adaptive infrastructure that connects AI clients, data providers,
     model providers, agent providers, service facilitators, and
     computational resources to support end-to-end training, inference,
     and agentic interaction lifecycle operations.  The architecture
     features dedicated control, data, and operations & management (OAM)
     planes to orchestrate training, inference, and agentic services while
     ensuring reliability, transparency, and accountability.  By outlining
     the key requirements of such an AI ecosystem and demonstrating how
     DA-ITN fulfills them, this document presents an architecture for the
     future of AI-native networking—an "AI internet"—optimized for AI
     learning, efficient inference, scalable deployment, and seamless
     agent-to-agent collaboration.

full_text:
  Network Working Group                                        A. Akhavain
  Internet-Draft                                                 H. Moussa
  Intended status: Informational                             Huawei Canada
  Expires: 6 May 2026                                      2 November 2025


        AI Network for Training, Inference, and Agentic Interactions
                    draft-akhavain-moussa-ai-network-01

  Abstract

     Artificial Intelligence (AI) is rapidly transforming industries and
     everyday life, fueled by advances in model architectures, training
     paradigms, and data infrastructure for generation and consumption.
     Today, machine learning models are embedded in many of our daily
     activities, ranging from simple classification systems to advanced
     architectures such as large language models (LLMs) like ChatGPT,
     Claude, Grok, and DeepSeek.  These models highlight the
     transformative potential of AI across diverse applications—from
     productivity tools to complex decision-making systems.

     However, the effectiveness and reliability of AI depend on two
     foundational processes: training and inference.  Each process
     introduces unique challenges related to data management, computation,
     connectivity, privacy, trust, security, and governance.

     In this draft, we introduce the Data and Agent Aware-Inference and
     Training Network (DA-ITN)—a unified, intelligent, multi-plane network
     architecture designed to address the full spectrum of requirements
     needed to enable AI networks.  DA-ITN provides a scalable and
     adaptive infrastructure that connects AI clients, data providers,
     model providers, agent providers, service facilitators, and
     computational resources to support end-to-end training, inference,
     and agentic interaction lifecycle operations.  The architecture
     features dedicated control, data, and operations & management (OAM)
     planes to orchestrate training, inference, and agentic services while
     ensuring reliability, transparency, and accountability.  By outlining
     the key requirements of such an AI ecosystem and demonstrating how
     DA-ITN fulfills them, this document presents an architecture for the
     future of AI-native networking—an "AI internet"—optimized for AI
     learning, efficient inference, scalable deployment, and seamless
     agent-to-agent collaboration.

  Status of This Memo

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




  Akhavain & Moussa          Expires 6 May 2026                   [Page 1]


  Internet-Draft                 AI-Internet                 November 2025


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

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

     This Internet-Draft will expire on 6 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
     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.  Training Requirements . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Centralized versus Decentralized Training . . . . . . . .   4
       2.2.  Requirements Breakdown  . . . . . . . . . . . . . . . . .   5
         2.2.1.  Data Collection/Model Dispatching . . . . . . . . . .   6
         2.2.2.  Dataset Advertisement and Discovery . . . . . . . . .   7
         2.2.3.  Handling Mobility and Service Continuity  . . . . . .   9
         2.2.4.  Privacy, Trust, and Data Ownership and Utility  . . .  10
         2.2.5.  Testing and Performance Management  . . . . . . . . .  10
         2.2.6.  Training Service QoS Guarantee  . . . . . . . . . . .  11
         2.2.7.  Charging and Billing  . . . . . . . . . . . . . . . .  11
     3.  Inference . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       3.1.  Requirement Breakdown . . . . . . . . . . . . . . . . . .  12
         3.1.1.  Model Deployment and Mobility . . . . . . . . . . . .  13
         3.1.2.  AI Model (AI Agent) Discovery and Description . . . .  14
         3.1.3.  Query and Inference Result Routing  . . . . . . . . .  17
         3.1.4.  Inference Chaining/Collaborative Inference  . . . . .  18
         3.1.5.  Compute and Resource Management . . . . . . . . . . .  19
         3.1.6.  Privacy Preservation and Security . . . . . . . . . .  19
         3.1.7.  Utility Handling and QoS Requirements . . . . . . . .  20



  Akhavain & Moussa          Expires 6 May 2026                   [Page 2]


  Internet-Draft                 AI-Internet                 November 2025


         3.1.8.  Model Upgrade Streamlining  . . . . . . . . . . . . .  20
         3.1.9.  Charging and Billing  . . . . . . . . . . . . . . . .  21
     4.  Framework for DA-ITN (Data and Agent Aware Inference and
             Training Network) . . . . . . . . . . . . . . . . . . . .  22
       4.1.  DA-ITN Core . . . . . . . . . . . . . . . . . . . . . . .  23
       4.2.  DA-ITN Service Provider Community . . . . . . . . . . . .  24
       4.3.  DA-ITN Client Community . . . . . . . . . . . . . . . . .  25
       4.4.  DA-ITN Enablers . . . . . . . . . . . . . . . . . . . . .  26
     5.  DA-ITN high level architecture  . . . . . . . . . . . . . . .  27
       5.1.  Control plane and Intelligence Layer  . . . . . . . . . .  27
       5.2.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . .  29
       5.3.  Operation and Management Plane (OAM)  . . . . . . . . . .  29
       5.4.  Summary of the DA-ITN General Framework . . . . . . . . .  30
     6.  DA-ITN for Training . . . . . . . . . . . . . . . . . . . . .  31
     7.  DA-ITN for Inference  . . . . . . . . . . . . . . . . . . . .  34
     8.  DA-ITN-Facilitation Agentic Networks  . . . . . . . . . . . .  35
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  36
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36
     11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  36
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  37
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

  1.  Introduction

     AI has become a major focus in recent years, with its influence
     rapidly expanding from everyday tasks like scheduling to complex
     areas such as healthcare.  This growth is largely driven by advances
     in model architectures, training paradigms, and data infrastructure
     for generation and consumption.  For example, large language models
     (LLMs) like ChatGPT, Claude, Grok, and DeepSeek, which are now widely
     used for tasks such as text generation, translation, reasoning,
     coding, and data analysis, highlight AI’s transformative power to
     boost productivity and simplify real-life applications.  As such, it
     is clear that AI and machine learning are not passing trends but
     lasting and evolving forces that will only continue to evolve.  For
     clarity, in this draft, the term AI refers broadly to all types of
     models—from simple classification systems to advanced general
     intelligence models.

     However, it is crucial to recognize that the success of AI systems
     relies on two fundamental pillars: training and inference.  Both of
     these pillars have a number of factors and moving parts that need to
     be carefully coordinated, designed, and managed to ensure accuracy,
     resilience, usability, continuous evolution, trustworthiness, and
     reliability.  Moreover, once deployed, AI systems must be
     continuously monitored and governed to safeguard user safety and
     societal well-being.




  Akhavain & Moussa          Expires 6 May 2026                   [Page 3]


  Internet-Draft                 AI-Internet                 November 2025


     As such, aspects such as data management, computational resources,
     connectivity, security, privacy, trust, billing, and rigorous testing
     are all crucial when handling AI systems.  Thus, it is important to
     clearly understand the requirements of the AI systems from the
     training, inference, and agentic interaction prospectives as all of
     these pillars constitute an entangled framework and cannot be tackled
     in isolation.

     In this document, we present a vision of an ecosystem, especially
     designed to facilitate what we call the AI network.  We propose a
     unified, intelligent network architecture called the "Data and Agent
     aware-Inference and Training Network" (DA-ITN).  This ecosystem is
     envisioned as a comprehensive, multi-plane network with dedicated
     control, data, and operations & management (OAM) planes.  It is
     designed to interconnect all relevant stakeholders, including
     clients, AI service providers, data providers, and third-party
     facilitators.  Its core objective is to provide the infrastructure
     and coordination necessary to support an ecosystem for enabling AI of
     the future at scale.

     To that end, we begin by outlining the specific requirements of AI
     from both the training and inference standpoints.  We then introduce
     the core components of the DA-ITN and illustrate how they
     collectively meet these requirements.  Finally, this network is
     positioned as an ecosystem for agent-to-agent collaborations,
     interactions, and communications.

  2.  Training Requirements

     AI model training is the foundational process through which an AI
     system learns to perform tasks by analyzing data and adjusting its
     internal parameters to minimize performance errors.  At its core,
     this process involves feeding input data into a model, and applying
     optimization algorithms to iteratively refine the model’s
     performance.  As such, the training process involves creating
     rendezvous point where data, compute, and AI models can interact.

  2.1.  Centralized versus Decentralized Training

     It is clear from the above that no matter how advanced the model
     architecture may be, the success of any training process ultimately
     hinges on two fundamental components: the model and the data.  While
     the model itself is often developed and hosted in a centralized
     location—typically within the secure infrastructure of the model
     owner or designer—data is inherently distributed.  The training data
     might originate from sensors, devices, logs, events, documents, and
     other diverse sources spread across different geographies and
     domains.  To be exact, whether due to geographic dispersion,



  Akhavain & Moussa          Expires 6 May 2026                   [Page 4]


  Internet-Draft                 AI-Internet                 November 2025


     organizational silos, privacy constraints, or edge-device generation,
     data rarely exists in a single, clean repository.

     Today, model training can happen in one of two ways or a combination
     thereof: centralized or decentralized.  In centralized training,
     thanks to the development of robust data collection techniques and
     high-throughput connectivity networks, it is now feasible to collect
     data and bring it to where the model training would occur.  On the
     other hand, a more recent paradigm known as model-follow-data has
     emerged, advocating for the reverse: rather than transporting large
     volumes of potentially sensitive data to a central location, the
     model is dispatched to where the data resides—enabling distributed or
     federated training.

     Accordingly, to facilitate the training process, rendezvous points
     scheduling, whether centralized (data is collected and shipped to
     where the model is) or decentralize (model is shipped to where the
     data is), between distributed data, compute and storage resources,
     and AI models awaiting training needs to be arranged and managed,
     which is fundamental for successful model training.  However, this
     scheduling process introduces a number of challenges spanning
     privacy, trust, utility, and computational and connectivity resources
     management.  Moreover, as AI adoption accelerates, both centralized
     and decentralized approaches will drive increasing pressure on
     underlying connectivity infrastructure.  Therefore, to ensure
     scalable, efficient, and cost-effective AI training, it is vital to
     implement intelligent mechanisms for managing data and model
     movement, selecting relevant subsets for training, and minimizing
     unnecessary transfers.

     In the sections that follow, we explore the architectural and
     operational requirements needed to support this vision and lay the
     foundation for a high-performance, AI-native training ecosystem.

  2.2.  Requirements Breakdown

     Consider a number of AI model training clients awaiting training
     service.  An AI model training client is a user with a new or a pre-
     trained model who wishes to train or continue training their AI model
     using data that can be found in the data corpus.  The data corpus
     (the global dataset), as has been previously established, consists of
     a group of datasets that are distributed across various geographical
     locations.  The AI model training client requires access to this data
     either in a centralized or distributed manner.







  Akhavain & Moussa          Expires 6 May 2026                   [Page 5]


  Internet-Draft                 AI-Internet                 November 2025


  2.2.1.  Data Collection/Model Dispatching

     As previously discussed, data is inherently distributed.  In
     centralized training paradigms, this data must be transferred from
     its sources to centralized locations where model training occurs.
     Consider a scenario involving multiple AI model training clients,
     each awaiting centralized training of their AI model.  Each client is
     interested in a particular data set that is sufficient for the
     intended training objective.  Aggregating large volumes of data from
     geographically dispersed sources to the centralized server of each
     client introduces several significant challenges:

     *  Communication Overhead: The sheer volume of data to be transmitted
        can place substantial strain on the underlying transport networks,
        resulting in increased latency and bandwidth consumption.

     *  Redundant Knowledge Transfer: Despite originating from different
        sources, data sets may carry overlapping or identical knowledge
        content.  Transmitting such redundant content leads to unnecessary
        duplication, wasting resources without providing additional
        training value.

     *  Timely Delivery: In certain applications, the freshness of data is
        critical.  Delays in transmission can degrade the value of the
        information, as these applications are sensitive to the Age of
        Information (AoI)—the time elapsed since data was last updated at
        the destination.

     *  Multi-Modal Data Handling: Data often exists in various
        formats—such as text, images, audio, video, etc—each with distinct
        transmission requirements.  Ensuring accurate and reliable
        delivery of these diverse data types necessitates differentiated
        Quality of Service (QoS) levels tailored to the characteristics
        and sensitivity of each modality.

     *  Heterogeneous Access Media: Data may reside across diverse
        communication infrastructures—for example, some data may be
        accessible only via 3GPP mobile networks, while other data may be
        confined to wireline networks.  Coordinating data collection
        across these heterogeneous domains, while maintaining
        synchronization and consistency, presents a significant
        operational challenge.

     Importantly, many of these challenges are alleviated in decentralized
     training frameworks, where data remains local to its source and is
     not transferred over the network.  Instead, the model itself is
     distributed to the various data locations.  However, this alternate
     paradigm introduces its own set of unique challenges.



  Akhavain & Moussa          Expires 6 May 2026                   [Page 6]


  Internet-Draft                 AI-Internet                 November 2025


     As previously noted, modern AI models are growing increasingly large
     in size.  In decentralized training, it is often necessary to
     replicate the AI model that require training and transmit the copies
     to multiple geographically dispersed data sites.  This results in a
     different but equally significant set of logistical and technical
     hurdles:

     *  Communication Overhead: While data transfer is avoided,
        dispatching large model files across the network to multiple
        destinations can still impose substantial load on communication
        infrastructure, particularly in bandwidth-constrained
        environments.

     *  Redundant Knowledge Transfer: Data residing at different locations
        may share overlapping knowledge content.  Sending models to
        multiple sites with redundant knowledge content leads to
        inefficient use of network resources.  In some cases, even when
        knowledge content is only partially redundant, it may be more
        efficient—considering communication cost—to forego marginal
        training benefits in favor of reduced overhead.

     *  Timeliness and Data Freshness: In certain applications, the Age of
        Information (AoI) remains critical.  Prioritizing model dispatch
        to data sources with soon-to-expire or time-sensitive information
        is essential to maximize the utility of training and to maintain
        up-to-date model performance.

  2.2.2.  Dataset Advertisement and Discovery

     Given the distributed nature of data, there must be a mechanism
     through which data owners can advertise information about their
     datasets to AI model training clients.  This requires the ability to
     describe the characteristics of the data—such as its knowledge
     content, quality, size, and Age of Information (AoI)—in a way that
     allows AI clients to discover and evaluate whether the data aligns
     with their training objectives.  Training objectives can be one or
     more of: target performance, convergence time, training cost, etc.

     Crucially, the dataset discovery process may need to operate across
     multiple network domains and heterogeneous communication
     infrastructures.  For example, an AI training client operating over a
     wireline connection may be interested in data residing on a 3GPP
     mobile network.  This raises an important question: How can data
     owners effectively advertise their datasets in a way that is
     discoverable across diverse domains?  To enable such cross-domain
     data visibility and discovery, the following key requirements shall
     be considered:




  Akhavain & Moussa          Expires 6 May 2026                   [Page 7]


  Internet-Draft                 AI-Internet                 November 2025


     *  Dataset Descriptors: These are metadata objects used by dataset
        owners to reveal essential information about their datasets to AI
        clients.  Effective dataset descriptors must be self-contained,
        privacy-preserving, and informative enough to support decision-
        making by training clients.  They should allow dataset owners to
        selectively disclose details about their data—such as type,
        relevance, quality metrics, freshness, and perhaps cost of
        utility—while concealing sensitive or proprietary information
        (privacy preservation).  Data descriptors also need to be easily
        modified as dataset can be dynamic, and the change in dataset
        needs to be effectively reflected into the dataset descriptions.
        To ensure interoperability, dataset descriptors can either follow
        a standardized format or adopt a flexible but well-defined
        structure that enables consistent interpretation across different
        systems and domains.

     *  Dataset Discovery Mechanisms: The dataset discovery refers to the
        processes by which AI training clients locate and identify
        datasets across potentially vast and heterogeneous environments.
        An effective discovery mechanism should support global-scale
        searchability and cross-domain operability, allowing clients to
        find relevant datasets regardless of where they reside or which
        communication infrastructure they are accessible through.
        Discovery protocols may be standardized within specific domains
        (e.g., mobile networks, IoT platforms) or designed to function
        interoperable across multiple domains, enabling seamless
        integration and visibility.  It should also be highlighted that,
        discovery mechanisms should be considerably up-to-date with the
        changes that would occur as the underlying data changes
        dynamically.

     *  Dataset Relationship Maps: Training often requires identifying
        groups of datasets that collectively meet specific requirements.
        Evaluating each dataset in isolation may be insufficient.
        Instead, a mechanism is needed to establish relationships among
        datasets, enabling AI training clients to assemble the appropriate
        combination of data for their tasks.  These relationships can be
        envisioned to look like maps or topologies.  This is a crucial
        step as, if an AI model client was not able to find the right
        dataset that satisfies its requirements, the client might choose
        not to submit the model for training at this time which may reduce
        resource wastage from the get-go.

     *  Timely reporting: Given the dynamic nature of data availability,
        characteristics, and accessibility, it is essential to have
        advertisement mechanisms that can promptly reflect any changes.
        Real-time or near-real-time updates ensure that the AI training
        process remains aligned with the most current data conditions,



  Akhavain & Moussa          Expires 6 May 2026                   [Page 8]


  Internet-Draft                 AI-Internet                 November 2025


        thereby maximizing both effectiveness and accuracy.  Timely
        reporting helps prevent training on outdated or irrelevant data
        and supports optimal decision-making in model selection and
        training pipeline configuration.

     Additionally, it should be highlighted that in AI training,
     discovering dataset alone is not enough.  For instance, third-party
     resources like compute and storage are essential, and the providers
     of those resources must be able to advertise their capabilities so AI
     clients can locate and utilize them effectively.  Just like with
     data, resource discovery requires descriptors, multi-domain
     accessibility, and timely updates to support seamless coordination
     between models, data, and infrastructure.  It should be highlighted
     that data and resource discovery is essential in both centralized and
     decentralized training, as both can be done on third party
     infrastructure.

  2.2.3.  Handling Mobility and Service Continuity

     In some decentralized training applications, AI models are designed
     to traverse a predefined route, training on multiple datasets in a
     sequential or federated manner.  This introduces the need to manage
     model mobility.  However, the underlying data landscape is often
     dynamic—new data is continuously generated, existing data may be
     deleted, or datasets may be relocated to different nodes or domains.

     As a result, enabling reliable model mobility in such a fluid
     environment requires robust mobility management mechanisms.  For
     instance, while a model is en-route to a specific data location for
     training, that dataset may be moved elsewhere.  In such cases, the
     model must either be re-routed to the new location or redirected to
     an alternative dataset that satisfies similar training objectives.

     Additionally, since training occurs on remote compute infrastructure
     and can be time-intensive, unexpected resource shutdowns or failures
     may interrupt the process.  These interruptions can lead to service
     discontinuity, which must be addressed through mechanisms such as
     checkpointing, fallback resource selection, or dynamic rerouting of
     model or data to maintain training progress and system reliability.












  Akhavain & Moussa          Expires 6 May 2026                   [Page 9]


  Internet-Draft                 AI-Internet                 November 2025


     Additionally, model mobility may involve training on datasets that
     are distributed across heterogeneous communication infrastructures.
     Some infrastructures, such as emerging 6G networks, offer built-in
     mobility support—for example, when data resides on mobile user
     equipment (UE), its location can be tracked using native features of
     the network.  However, such mobility handling capabilities may not
     exist in other infrastructures, such as traditional wireline networks
     or legacy systems, making seamless model movement and data access
     more challenging in those environments.

  2.2.4.  Privacy, Trust, and Data Ownership and Utility

     Privacy and trust are mutual responsibilities between data owners and
     model owners and shall be protected.  Granting clients access to data
     for training and knowledge building should be a regulated process,
     with mechanisms to track data ownership and future use.  Initial
     discussions on this topic have taken place in forums such as the AI-
     Control Working Group.

     Equally important is ensuring that model owners are protected from
     data poisoning.  They must have confidence that the datasets they use
     are accurately described and not misrepresented.  If data owners
     provide false metadata—intentionally or otherwise—model owners may
     unknowingly train on unsuitable or harmful datasets, leading to
     degraded model performance.  To safeguard both parties, innovative
     verification and enforcement mechanisms are needed.  Technologies
     like blockchain could offer potential solutions for establishing
     trust and accountability, but further research and exploration are
     necessary to develop practical frameworks.

  2.2.5.  Testing and Performance Management

     Another critical aspect of training is testing and performance
     evaluation, typically carried out using a separate subset of the data
     known as the testing dataset.  This dataset is not used to update the
     model’s weights but to assess its performance on unseen samples.  In
     centralized training, this process is straightforward because all
     data resides in a single, accessible location, making it easy to
     partition the dataset into training and testing subsets.  However, in
     distributed training environments, where data is spread across
     multiple locations or devices, creating a representative and unbiased
     testing dataset without aggregating the data centrally becomes a
     major challenge.  Developing effective, privacy-preserving methods
     for testing in such settings requires innovative solutions







  Akhavain & Moussa          Expires 6 May 2026                  [Page 10]


  Internet-Draft                 AI-Internet                 November 2025


  2.2.6.  Training Service QoS Guarantee

     Beyond ensuring traditional Quality of Service (QoS) for data
     transmission, a new dimension of QoS must be considered—the QoS of
     training itself.  In AI training workflows, it is crucial to
     guarantee that key performance indicators (KPIs) related to training,
     such as accuracy convergence, training time, and resource
     utilization, are met consistently.  This raises several important
     questions: * How can these training KPIs be guaranteed in dynamic or
     distributed environments?

     *  What mechanisms can be used to monitor and track training
        performance in real time?

     *  Should AI training be treated like best-effort traffic, where no
        guarantees are made and resources are allocated as available?

     *  Should training tasks receive prioritized or differentiated
        service levels, similar to high-priority traffic in traditional
        networks?

     Addressing these questions is essential to ensure predictable and
     reliable AI model development, especially as training workloads grow
     in complexity and scale.  It may require introducing new QoS
     frameworks tailored specifically to the needs of AI training systems.

  2.2.7.  Charging and Billing

     The AI training process involves a diverse ecosystem of stakeholders,
     including data owners, model owners, and resource providers.  Each of
     these parties plays one or more vital roles in enabling successful
     training workflows.

     For example, communication providers contribute not only by
     transporting dataset and models across the network but also they
     themselves may also serve as data providers.  This is particularly
     evident in the emerging design of 6G networks, which integrate
     sensing capabilities with communication infrastructure.  As a result,
     6G operators are uniquely positioned to offer both connectivity and
     data, making them central players in the training pipeline.

     Despite their different roles, all parties contribute to enabling AI
     training as a service, a complex and resource-intensive process that
     is far from free.  Therefore, it is essential to establish a robust
     charging and billing framework that ensures each participant is
     fairly compensated based on their contribution.

     Several open questions arise in this context:



  Akhavain & Moussa          Expires 6 May 2026                  [Page 11]


  Internet-Draft                 AI-Internet                 November 2025


     *  Should training services follow a prepaid model, or adopt a pay-
        per-use structure?

     *  Should there be tiered service offerings, such as gold, silver,
        and platinum, each providing different levels of performance
        guarantees or priority access?

     *  How should these tiers be defined and enforced in terms of service
        quality, resource allocation, and response time?

     Developing fair, transparent, and scalable billing mechanisms is
     critical to facilitating collaboration across stakeholders and
     sustaining the economic viability of distributed AI training
     ecosystems.  These challenges call for further research into
     incentive structures, dynamic pricing models, and smart contract-
     based enforcement, especially in scenarios involving cross-
     organizational or cross-network cooperation.

  3.  Inference

     Inference is critical because it represents the phase where the model
     begins to deliver practical value.  Unlike training, which is
     typically, a one-time or periodic, resource-intensive process,
     inference often needs to operate continuously and efficiently,
     sometimes in real-time.  Although inference is a less resource-
     intensive process, it has strict requirements that govern its
     success.  While a single AI inference might be lightweight and fast,
     serving many users, with many inference requests, demands significant
     hardware resources andposes serious scalability challenges.  In what
     follows, we explore these requirements that shall enable a successful
     AI inference ecosystem.

  3.1.  Requirement Breakdown

     We envision an inference ecosystem composed of a large number of pre-
     trained AI models (or agents) distributed across a geographical
     location.  These models are capable of performing a wide range of
     tasks, such as image classification, language translation, or speech
     recognition.  Some models may specialize in the same task but vary in
     performance, accuracy, latency, or resource demands.  This diverse
     pool of models is accessed by numerous inference clients (users or
     applications) who submit inputs, referred to as queries, and receive
     task-specific outputs.

     These queries can vary greatly in complexity, structure, and
     modality, with some requiring the cooperation of multiple models to
     fulfill a single request.  The overarching goal of the ecosystem is
     to efficiently match incoming queries with the most suitable models,



  Akhavain & Moussa          Expires 6 May 2026                  [Page 12]


  Internet-Draft                 AI-Internet                 November 2025


     ensuring accurate, timely, and resource-aware responses.  Achieving
     this requires intelligent orchestration, load balancing, and
     potentially dynamic model selection based on factors such as
     performance, availability, cost, and user-specific requirements.  In
     what follows, we discuss the various aspects of this ecosystem and
     discuss the different requirements needed for its success.

  3.1.1.  Model Deployment and Mobility

     The first step toward building a successful AI inference ecosystem is
     the optimal deployment of trained AI models (or AI agents).  In this
     context, optimality refers to both the physical or network location
     of the model and the manner in which it is deployed.  AI models vary
     significantly in size and resource requirements—ranging from
     lightweight models that are only a few kilobytes to large-scale
     models with billions of parameters.  This wide range makes deployment
     decisions critical to achieving both efficient performance and
     effective resource utilization.  Also, a unique factor to AI models/
     agents is the fact that they are software components that are not
     bounded to a certain hardware.  They can be deleted, copied, moved,
     or split across multiple compute locations.  All these unique aspects
     provide flexibility in design if the real-time status of the
     underlying network dynamics and resources is made accessible.  As
     such, the following aspects must be taken into account when handling
     model deployment and mobility:

     *  Choosing the right facility to host a model: whether it's a
        lightweight edge device, a local server, or a high-performance
        cloud data center, deployment will depend on the model's size,
        computational requirements, and expected query volume.  For
        example, smaller models might be best suited for deployment on
        edge devices closer to users, enabling low-latency responses.  In
        contrast, larger models may require centralized or specialized
        infrastructure with high compute and memory capacity.

     *  Load balancing: Once models are deployed, inference traffic begins
        to flow, with users or applications sending queries to the
        appropriate agents.  If not managed properly, this traffic can
        lead to congestion, creating bottlenecks that degrade inference
        performance through increased latency or dropped requests.  To
        avoid such scenarios, models should be deployed strategically to
        distribute the load, ensuring smooth operation.  Traditional load
        balancing techniques can be employed to redirect traffic away from
        overburdened nodes and towards underutilized ones.  However, more
        sophisticated strategies may involve replicating models and
        placing these replicas closer to regions with high query demand,
        thereby minimizing latency and easing network traffic engineering
        challenges.



  Akhavain & Moussa          Expires 6 May 2026                  [Page 13]


  Internet-Draft                 AI-Internet                 November 2025


     *  Mobility-aware deployment: the dynamic nature of inference traffic
        necessitates mobility-aware deployment.  For instance, consider a
        large data center acting as a centralized inference hub, hosting
        numerous models and handling a significant volume of queries.
        Over time, this hub may experience traffic overload.  In such
        cases, migrating certain models to alternative locations can help
        alleviate pressure.  However, model migration is not without its
        challenges—particularly if a model is actively serving queries at
        the time of migration.  In such situations, mobility handling
        mechanisms must be in place to ensure seamless service continuity.
        These mechanisms could involve session handovers, temporary state
        preservation, or model version synchronization, all designed to
        maintain uninterrupted service during the migration process.

     In summary, optimal model deployment requires careful consideration
     of model size, resource needs, query distribution, and real-time
     adaptability.  Achieving this lays the foundation for a responsive,
     scalable, and resilient AI inference ecosystem.

  3.1.2.  AI Model (AI Agent) Discovery and Description

     Just as data descriptors and discovery mechanisms are essential
     during the training phase, AI model inference clients also require a
     robust discovery mechanism during the inference stage.  In an
     ecosystem populated by a large and diverse pool of models—each with
     unique capabilities and specializations—clients are presented with
     significant flexibility and choice in selecting the most suitable
     models for their queries.  However, to make informed decisions,
     clients must have access to information that enables them to
     distinguish between models based on criteria such as performance,
     specialization, availability, and resource requirements.

     The AI model discovery process becomes even more complex when it
     needs to function across multiple network domains and heterogeneous
     communication infrastructures.  For instance, a client connected via
     a wireline network might need to interact with a model deployed on a
     mobile 3GPP network.  Such scenarios raise a critical question: How
     can model owners advertise their models in a way that ensures
     discoverability and interoperability across diverse domains?

     Addressing this challenge requires the development of standardized
     model advertisement and discovery protocols that can operate
     seamlessly across infrastructure boundaries.  These protocols must
     accommodate differences in network technology, latency constraints,
     and security requirements while providing consistent and reliable
     access to model information.  Ensuring cross-domain discoverability
     is crucial to unlocking the full potential of a globally distributed
     inference ecosystem.



  Akhavain & Moussa          Expires 6 May 2026                  [Page 14]


  Internet-Draft                 AI-Internet                 November 2025


     To enable such cross-domain AI model visibility and discovery, the
     following key requirements must be considered:

     *  AI Model Descriptors: These are metadata objects used by model
        owners to reveal essential aspects about their datasets to AI
        inference clients.  Effective data descriptors must be self-
        contained, privacy-preserving, and informative enough to support
        decision-making by inference clients.  They should allow model
        owners to selectively disclose details about their model—such as
        skills, performance reviews, trust level, relevance, quality
        metrics, freshness, and perhaps cost of utility—while concealing
        sensitive or proprietary information.  To ensure interoperability,
        model descriptors can either follow a standardized format or adopt
        a flexible but well-defined structure that enables consistent
        interpretation across different systems and domains.

     *  AI Model Discovery Mechanisms: These refer to the processes by
        which AI inference clients locate and identify models/agents
        across potentially vast and heterogeneous environments.  An
        effective discovery mechanism should support global-scale
        searchability and cross-domain operability, allowing clients to
        find relevant model/agents regardless of where they reside or
        which communication infrastructure they are accessible through.
        Discovery protocols may be standardized within specific domains
        (e.g., mobile networks, IoT platforms) or designed to function
        interoperable across multiple domains, enabling seamless
        integration and visibility.

     *  AI Model relationship maps: As queries may requiring the
        collaboration between multiple models/agents, relationships
        between models/agents with respect to different task might present
        useful tools as to help clients choose the appropriate subset of
        models/agents that would handle their queries.

     *  Timely Reporting: Similar to AI datasets, the status of an AI
        model can change over time—for example, due to shifts in workload
        or resource availability.  It is important that such changes are
        reported promptly and accurately, allowing clients to make
        informed decisions based on the model’s current state.  This is
        essential for ensuring efficient model selection and maintaining
        high-quality, reliable inference outcomes.










  Akhavain & Moussa          Expires 6 May 2026                  [Page 15]


  Internet-Draft                 AI-Internet                 November 2025


     It is important to emphasize that AI model discovery differs
     fundamentally from data discovery.  While data are passive objects
     that require external querying or manipulation, AI models are
     intelligent, autonomous entities capable of making decisions based on
     their own capabilities, status, and context.  This distinction opens
     up new and more dynamic possibilities for how models are discovered
     and engaged in an inference ecosystem.

     In traditional data discovery, clients search for and retrieve
     relevant datasets based on metadata or predefined criteria.  However,
     in the case of model discovery, the process can be much more
     interactive and flexible.  One approach involves the client actively
     discovering models by querying a directory or registry using model
     descriptors.  Based on these descriptors, the client selects one or
     more models to handle a specific inference task.  However, given that
     models can reason and act independently, model discovery does not
     have to be limited to client-driven selection.  An alternative
     approach is to reverse the flow of interaction.  Instead of clients
     seeking out models, they can publish their tasks to a shared task
     pool, accessible to all available models.  These tasks include
     descriptors that define the type of work to be done, expected
     outputs, and quality-of-service requirements.  Models can then
     autonomously scan this pool, evaluate whether they are well-suited
     for specific tasks, and choose to express interest in executing them.
     This self-selection process allows models to play an active role in
     task matching, improving system scalability and efficiency.

     The final assignment of a task can be handled in different ways.
     Clients may retain full control and approve or reject interested
     models based on their preferences or priorities.  Alternatively, the
     system may operate in a fully autonomous mode, where tasks are
     assigned automatically to the first or best-matching model, without
     requiring client intervention—depending on the client's chosen
     policy.

     This agent-driven paradigm reflects the shift toward more
     decentralized and intelligent AI ecosystems, where models are not
     merely passive computation endpoints but active participants in task
     negotiation and resource allocation.  Such a system not only enhances
     scalability and flexibility but also allows for more efficient
     utilization of the available model pool, especially in heterogeneous
     and dynamic environments.









  Akhavain & Moussa          Expires 6 May 2026                  [Page 16]


  Internet-Draft                 AI-Internet                 November 2025


  3.1.3.  Query and Inference Result Routing

     A significant challenge in AI inference networks lies in efficiently
     routing client queries to the appropriate inference models and
     ensuring the corresponding results are reliably delivered back to the
     client.  This becomes particularly complex in scenarios involving
     mobility and multi-domain environments, where both the client and the
     model may exist across different types of network infrastructures.
     The key challenges and considerations include:

     *  Query Routing Across Heterogeneous Networks: When a client
        accesses the inference ecosystem through a mobile network such as
        3GPP 6G, and the target model is hosted in a wireline or cloud-
        based infrastructure, routing the query across these distinct
        domains is non-trivial.  Differences in network architecture,
        protocols, and service guarantees complicate the end-to-end flow.

     *  Mobility Management During Inference Execution: While mobile
        networks like 6G are designed to handle user mobility, inference
        tasks may take time to process—particularly when using large
        models or performing complex computations.  During this time, the
        client may change physical location, switch devices, or even go
        offline.  Ensuring that inference results can still reach the
        client under these dynamic conditions poses a significant
        challenge.

     *  Handling Client State Changes: If a client becomes idle or
        disconnects entirely during inference, the system must decide what
        to do with the completed result.  Should it be queued, buffered,
        forwarded to another linked device, or simply discarded?  A robust
        mechanism is needed to track client state, maintain context, and
        guarantee result delivery or at least graceful degradation.

     *  Support for Live and Streaming Inference: Some use cases, such as
        real-time audio transcription, involve live streaming of data from
        the client to the model and vice versa.  These sessions require
        sustained, low-latency connections and are particularly sensitive
        to interruptions caused by mobility or handoffs between networks.
        Ensuring session continuity and maintaining streaming quality
        across network boundaries is a complex but critical aspect of
        real-world inference deployments.










  Akhavain & Moussa          Expires 6 May 2026                  [Page 17]


  Internet-Draft                 AI-Internet                 November 2025


     *  Cross-Domain Connectivity and Session Management: The involvement
        of multiple network operators and domains introduces questions
        around interoperability, session tracking, and handover
        coordination.  There is a need for intelligent infrastructure
        capable of end-to-end session management, including maintaining
        metadata, context, and service quality as the session traverses’
        different networks.

  3.1.4.  Inference Chaining/Collaborative Inference

     Another critical aspect of an AI inference ecosystem is the need for
     model collaboration to fulfill complex or multi-faceted tasks.  Not
     all inference requests can be handled by a single model; in many
     cases, collaboration between multiple models is necessary.
     Effectively managing this task-based collaboration is essential to
     ensure accurate, efficient, and scalable inference services.  Model
     collaboration can take several distinct forms:

     *  Inference Chaining: In this model, the output of one model serves
        as the input to the next in a sequential pipeline.  Each model
        performs a specific stage of the task, and the final
        result—produced by the last model in the chain—is returned to the
        client.  This is common in multi-stage tasks such as image
        processing followed by object detection and then classification.

     *  Parallel Inference: Here, a complex task is decomposed into
        multiple subtasks, each of which is assigned to a specialized
        model.  These models operate concurrently, and their outputs are
        aggregated to form a unified inference result.  This approach is
        particularly useful when dealing with large data sets or when a
        task spans different domains of expertise.

     *  Hierarchical inference: A model is assigned as a task manager and
        is responsible for delegating tasks to service models

     *  Collaborative Inference: In this more dynamic and decentralized
        form, the task is assigned to a group of models that are capable
        of discovering one another, assessing their respective
        capabilities, and coordinating among themselves to devise a shared
        strategy for completing the task.  This model requires more
        sophisticated communication, negotiation, and orchestration
        mechanisms.

     Regardless of the collaboration format, the success of such multi-
     model interactions depends on the availability of a robust management
     infrastructure.  This infrastructure must enable seamless
     coordination between models, even when:




  Akhavain & Moussa          Expires 6 May 2026                  [Page 18]


  Internet-Draft                 AI-Internet                 November 2025


     *  The models are hosted by different providers,

     *  They are deployed across heterogeneous communication networks,

     *  They use varying protocols, or

     *  They have differing performance characteristics.

     Such a management system must abstract away the underlying
     complexities and provide standardized interfaces, discovery
     mechanisms, communication protocols, and coordination frameworks that
     allow models to interact effectively.  Without this, collaborative
     inference would be brittle, inefficient, or impossible to scale.  In
     essence, the ability to orchestrate model collaboration across
     diverse environments is a cornerstone of a flexible, intelligent, and
     robust AI inference ecosystem.

  3.1.5.  Compute and Resource Management

     In many scenarios, the compute infrastructure used to host and run
     inference models is managed by third-party providers, not the model
     owners themselves.  These compute providers are responsible for
     meeting the Quality of Service (QoS) levels agreed upon with the
     model owners—such as latency, uptime, throughput, and reliability.

     *  Ensuring these service levels are consistently met raises the
        question of accountability.  If performance degrades due to
        compute resource issues—such as overloaded hardware or network
        outages—who is responsible for the failed inference tasks?

     *  There must be clear, enforceable service-level agreements (SLAs)
        that define roles, responsibilities, and penalties for non-
        compliance.

     *  Mechanisms for performance monitoring, auditing, and dispute
        resolution need to be integrated into the ecosystem to make such
        arrangements viable and trustworthy.

  3.1.6.  Privacy Preservation and Security

     While models are the intellectual property of their owners, they may
     operate on infrastructure owned by others.  This raises significant
     concerns around privacy and intellectual property protection.

     *  Sensitive model details such as architecture, weights, and
        optimization strategies must be protected from exposure or reverse
        engineering by untrusted compute hosts.




  Akhavain & Moussa          Expires 6 May 2026                  [Page 19]


  Internet-Draft                 AI-Internet                 November 2025


     *  Techniques such as secure computing, encrypted model execution,
        and remote attestation protocols may be necessary to ensure that
        models run securely without revealing proprietary details.

     *  Model owners must also be assured that inference inputs and
        outputs remain confidential, particularly in applications
        involving personal or sensitive data.

  3.1.7.  Utility Handling and QoS Requirements

     Utility handling refers to the regulation, protection, and fair
     governance of how models are used, accessed, and monitored throughout
     the ecosystem.  This encompasses several critical questions:

     *  How can we guarantee that a model deployed on remote
        infrastructure is not being tampered with, copied, or
        intentionally repurposed?

     *  How do we ensure that workload distribution is fair across
        available models, preventing monopolization by a few and giving
        equal visibility and opportunity to all participating models?

     *  What protections are in place to ensure that models are not being
        poisoned, exploited, or involved in illegal activities, either
        through malicious inputs or untrusted outputs?

     *  How do we ensure the integrity of inference results, so that
        outputs are delivered to clients without alteration, manipulation,
        or censorship?  Addressing these concerns may require digital
        rights management (DRM) for AI models, usage monitoring tools, and
        potentially blockchain-based logging or audit trails to ensure
        transparency and traceability.

     On the other hand, the definition of Quality of Service (QoS), when
     it comes to inference tasks, is very broad and can take many forms.
     For instance, QoS could be to guarantee a certain accuracy of a
     response, or time of the response, or expertise level needed.  We
     believe that the topic of QoS guarantee requires extensive studying
     and analysis.

  3.1.8.  Model Upgrade Streamlining

     AI models are not static; they undergo continuous upgrades,
     improvements, and fine-tuning to maintain accuracy, adapt to new
     data, or support evolving tasks.






  Akhavain & Moussa          Expires 6 May 2026                  [Page 20]


  Internet-Draft                 AI-Internet                 November 2025


     *  The ecosystem must support seamless model versioning, including
        adding, removing, or modifying model agents without disrupting
        ongoing services.

     *  Updated model profiles must be instantly reflected in the
        discovery layer, ensuring clients always have access to the most
        current and accurate model descriptions.

     *  For large models, upgrade procedures must be efficient and
        bandwidth-conscious, potentially using incremental update
        techniques to avoid full redeployment.

     *  Moreover, strategies must be in place to handle hot-swapping of
        models, where an old model is gracefully decommissioned and
        replaced by a new one—without causing inference failures or data
        loss during the transition.

  3.1.9.  Charging and Billing

     The AI inference process involves a diverse ecosystem of
     stakeholders, including model owners, compute providers, and
     communication providers.  Each of these parties plays one or more
     vital roles in enabling successful inference workflows.  Therefore,
     it is essential to establish a robust charging and billing framework
     that ensures each participant is fairly compensated based on their
     contribution.

     Several open questions arise in this context:

     *  Should inference services follow a prepaid model, or adopt a pay-
        per-use structure?

     *  Will there be tiered service offerings—such as gold, silver, and
        platinum—each providing different levels of performance guarantees
        or priority access?

     *  How should these tiers be defined and enforced in terms of service
        quality, resource allocation, and response time?

     *  What about discovery framework providers?  Would they be offering
        a free service like google search or would it be more structured?










  Akhavain & Moussa          Expires 6 May 2026                  [Page 21]


  Internet-Draft                 AI-Internet                 November 2025


     Developing fair, transparent, and scalable billing mechanisms is
     critical to fostering collaboration across stakeholders and
     sustaining the economic viability of distributed AI training
     ecosystems.  These challenges call for further research into
     incentive structures, dynamic pricing models, and smart contract-
     based enforcement, especially in scenarios involving cross-
     organizational or cross-network cooperation.

  4.  Framework for DA-ITN (Data and Agent Aware Inference and Training
      Network)

     The DA-ITN is envisioned as a multi-domain, multi-technology network
     operating at the AI layer, designed to address the various layers of
     complexity inherent in modern AI ecosystems.  As mentioned earlier,
     the network aims to support a wide range of requirements, some of
     which are outlined above, across AI training, inference, and agent-
     to-agent interaction.

     The network consists of set of nodes and equipment connected via one
     or more traditional underlay networks as depicted below.

  +---------------------------------------------+
  | DA-ITN nodal view                           |
  |                                             |
  |  +----------------+     +----------------+  |    DA-ITN node types
  |  | DA-ITN Node (A)|<--->| DA-ITN Node (B)|  |      A- Data node
  |  +----------------+  |  +----------------+  |      B- Compute node
  |                      |                      |      C- Storage node
  |                      |                      |      D- Model node
  |  +----------------+  |  +----------------+  |      E- Evaluation node
  |  | DA-ITN Node (E)|<--->| DA-ITN Node (G)|  |      F- Agent node
  |  +----------------+  |  +----------------+  |      G- Multi-purpose node
  |                      |                      |
  |                      |                      |
  |  +----------------+  |  +----------------+  |
  |  | DA-ITN Node (F)|<--->|DA-ITN Node(C+D)|  |
  |  +----------------+     +----------------+  |
  |                                             |
  +---------------------------------------------+

                  Figure 1: Figure 1: DA-ITN nodal view

     Nodes with DA-ITN along with its core functionality interact together
     to provide different training, inference, and agentic services.  In
     this manner, DA-ITN can be divided into four interacting major
     building blocks as shown bellow.





  Akhavain & Moussa          Expires 6 May 2026                  [Page 22]


  Internet-Draft                 AI-Internet                 November 2025


             +--------------------+         +--------------------+
             |   DA-ITN Service   |         |   DA-ITN Client    |
             | Provider Community |         |     Community      |
             +--------------------+         +--------------------+
                 ↑     ↑                               ↑     ↑
                 |     |                               |     |
                 |     |                               |     |
                 |     +-------------------------------+     |
                 |                     |                     |
                 |                     |                     |
                 |                     ↓                     |
                 |           +--------------------+          |
                 |           |     DA-ITN Core    |          |
                 |           |                    |          |
                 |           +--------------------+          |
                 |                     ↑                     |
                 |                     |                     |
                 |                     |                     |
                 ↓                     ↓                     ↓
             +---------------------------------------------------+
             |                    DA-ITN Enablers                |
             +---------------------------------------------------+

        Figure 2: Figure 2: DA-ITN high level architecture and building
                                     blocks

  4.1.  DA-ITN Core

     This block contains DA-ITN main internal modules, functions, and
     services.  Dedicated logical planes in this block handle interactions
     between its different modules and functions.  Interactions between
     different modules and functions in this block are not visible or
     accessible to entities in other blocks.  DA-ITN core offers its
     services to external entities via clear and well defined interfaces
     and protocols.  The following illustrates different modules and
     functions of DA-ITN core block.















  Akhavain & Moussa          Expires 6 May 2026                  [Page 23]


  Internet-Draft                 AI-Internet                 November 2025


  +-----------------------------------+
  |            DA-ITN Core            |
  |                                   |
  |   +----------+ +--------------+   |
  |   | X-RCE    | |Registration &|   |     X-RCE:  Training, model, query, etc.
  |   |          | |Authentication|   |             route compute engine
  |   +----------+ +--------------+   |     XOD:    Model, agent deployment
  |   +----------+ +--------------+   |             optimizer
  |   | X-DO     | |Discovery &   |   |     S-FAM:  Different Service feasibility
  |   |          | |Advertisement |   |             assessment module
  |   +----------+ +--------------+   |     TAG:    Training algorithm generator
  |   +----------+ +--------------+   |     PVM:    Performance verification
  |   | S-FAM    | |Billing &     |   |             Module
  |   |          | |Accounting    |   |     DDRT:   Data dynamics and resource
  |   +----------+ +--------------+   |             topology
  |   +----------+ +--------------+   |
  |   | TAG      | |Reputation &  |   |
  |   |          | |Trust Mgmt.   |   |
  |   +----------+ +--------------+   |
  |   +----------+ +--------------+   |
  |   | PVM      | | Upgrade Mgmt.|   |
  |   |          | |              |   |
  |   +----------+ +--------------+   |
  |   +----------+ +--------------+   |
  |   | Resource | |Mobility Mgmt.|   |
  |   | Mgmt.    | |              |   |
  |   +----------+ +--------------+   |
  |   +----------+ +--------------+   |
  |   |   DDRT   | | Tools Mgmt.  |   |
  |   |          | |     ???      |   |
  |   +----------+ +--------------+   |
  |            +---------+            |
  |            |   OAM   |            |
  |            +---------+            |
  +-----------------------------------+

      Figure 3: Figure 3: DA-ITN core and its different modules and
                                 function

  4.2.  DA-ITN Service Provider Community

     Providers for different services such as data, model, agent, and
     resource providers reside within the Service Provider Community block
     of the DA-ITN.  Service providers join the network via a registration
     and authentication process offered by DA-ITN core.  The service
     providers use DA-ITN to advertise their services, capabilities, etc.
     across the overall network.  They can also register for notifications
     to get updates e.g. arrival of new models, training data, agents,



  Akhavain & Moussa          Expires 6 May 2026                  [Page 24]


  Internet-Draft                 AI-Internet                 November 2025


     etc.  DA-ITN dispenses revenue to providers for the services rendered
     via its billing and accounting module.

     The following figure shows different modules of DA-ITN service
     provider community.

                       +-------------------------------+
                       |       DA-ITN Service          |
                       |     Provider Community        |
                       |                               |
                       |  +----------+ +----------+    |
                       |  | Data     | | Model    |    |
                       |  | providers| | providers|    |
                       |  +----------+ +----------+    |
                       |  +----------+ +----------+    |
                       |  | Agent    | | Resource |    |
                       |  | providers| | providers|    |
                       |  +----------+ +----------+    |
                       |  +--------------+             |
                       |  | Tools        |             |
                       |  | providers ???|             |
                       |  +--------------+             |
                       +-------------------------------+

             Figure 4: Figure 4: DA-ITN Service Provider Community

     The tool module within the provider block requires further
     investigation and analysis.  Agentic protocols such as Model Context
     Protocol(MCP) provide access to MCP tools from the agent interaction
     point of view.  Whether DA-ITN needs to support additional
     capabilities w.r.t agents or whether it needs to support distinct
     tools w.r.t training and inference is an open question for now.  Will
     there be a need for unified tools' protocols that fits all utilities,
     or a protocol per utility?

  4.3.  DA-ITN Client Community

     This block represents the client side of DA-ITN.  The clients are
     network participants requiring training, inference, agent-to-agent
     interactions, and those who need access to resources such as storage,
     compute, etc. offered by resource providers in DA-ITN.

     DA-ITN enables clients to discover potential providers by tuning into
     DA-ITN discovery, and advertisement module, allowing them to select
     the best match based on their requirements.  Alternatively, clients
     may delegate the matching process to DA-ITN, requesting DA-ITN to
     identify the most suitable provider based on their criteria.  For
     example, a client using the model training service may opt to fully



  Akhavain & Moussa          Expires 6 May 2026                  [Page 25]


  Internet-Draft                 AI-Internet                 November 2025


     control the training process and make all decisions independently.
     Alternatively, the client can delegate the training responsibilities
     to the DA-ITN core.  In the case of delegation, modules such as
     X-RCE, DDRT, PVM, S-FAM, and TAG can work collaboratively to train
     the model on the client’s behalf and deliver the finalized, trained
     model back to them.

                       +-------------------------------+
                       |       DA-ITN Client           |
                       |         Community             |
                       |                               |
                       |  +----------+ +----------+    |
                       |  | Data     | | Model    |    |
                       |  | clients  | | clients  |    |
                       |  +----------+ +----------+    |
                       |  +----------+ +----------+    |
                       |  | Agent    | | Resource |    |
                       |  | clients  | | clients  |    |
                       |  +----------+ +----------+    |
                       |  +--------------+             |
                       |  | Tools        |             |
                       |  | Clients   ???|             |
                       |  +--------------+             |
                       +-------------------------------+

                  Figure 5: Figure 5: DA-ITN Client Community

     It must be noted that a node/entity in DA-ITN can act both as
     provider and/or a client.  For example, a node providing data as its
     service, might need access to a resource provider service.  Or a
     model provider enabling inference might employ the services of data
     providers for Retrieval-Augmented Generation (RAG).

     Similar to the provider community block in DA-ITN, the tools module
     withing the client community requires further study.

  4.4.  DA-ITN Enablers

     This layer represents external and underlying services that DA-ITN
     itself employs to accomplish its different tasks.  Various networking
     layers, access technologies, location, and sensing functions are
     examples of such services.









  Akhavain & Moussa          Expires 6 May 2026                  [Page 26]


  Internet-Draft                 AI-Internet                 November 2025


  +-------------------------------------------------------------------------+
  |                             DA-ITN Enablers                             |
  |                                                                         |
  |  +---------------------------+  +-----------+  +-----------+            |
  |  | Communications/Networking |  | Location  |  |  Sensing  |            |
  |  |                           |  |           |  |           |            |
  |  | +---------+  +----------+ |  | +-------+ |  | +-------+ |            |
  |  | | Mobile  |  | Internet | |  | | GPS   | |  | | IoT   | |            |
  |  | | network |  +----------+ |  | +-------+ |  | +-------+ |            |
  |  | +---------+  +----------+ |  | +-------+ |  | +-------+ |            |
  |  | | NTN     |  | WiFi     | |  | |Sensors| |  | | ISAC  | |  Others??? |
  |  | +---------+  +----------+ |  | +-------+ |  | +-------+ |            |
  |  | +-----------------------+ |  | +-------+ |  | +-------+ |            |
  |  | |        Others?        | |  | |Mobile | |  | |Others?| |            |
  |  | +-----------------------+ |  | |network| |  | +-------+ |            |
  |  |                           |  | +-------+ |  |           |            |
  |  |                           |  | +-------+ |  |           |            |
  |  |                           |  | |Others?| |  |           |            |
  |  |                           |  | +-------+ |  |           |            |
  |  +---------------------------+  +-----------+  +-----------+            |
  +-------------------------------------------------------------------------+

                   Figure 6: Figure 6: DA-ITN Enablers

  5.  DA-ITN high level architecture

     To manage these complexities and cater for the requirements, we
     propose structuring the DA-ITN around four core components: a Control
     Plane (CP), a Data Plane (DP), an Operations and Management (OAM)
     Plane, and an Intelligence Layer.  It is important to note that the
     DA-ITN is agnostic to the underlying communication infrastructure,
     allowing it to operate seamlessly over heterogeneous networks,
     whether mobile, wire-line, or satellite-based. he DA-ITN integrates
     with these underlying infrastructures through any available means,
     embedding its control and intelligence capabilities to coordinate and
     manage AI-specific services in a flexible and scalable manner.

  5.1.  Control plane and Intelligence Layer

     The Control Plane and Intelligence Layer work together to enable an
     efficient, reliable, and timely information collection
     infrastructure.  They continuously gather up-to-date information on
     data availability, model status, agent conditions, resource
     utilization, and reachability across all participating entities.  The
     collected information comes in the form of dynamic descriptors for
     data, models, and resources, essential components for enabling
     intelligent, context-aware decision-making within the AI ecosystem as
     has previously been highlighted.  Also, with the help of data,



  Akhavain & Moussa          Expires 6 May 2026                  [Page 27]


  Internet-Draft                 AI-Internet                 November 2025


     resource, and reachability topology engine (DRRT) housed within the
     intelligence layer, the gathered information and descriptors can be
     used to construct meaningful relationships across the ecosystem.
     These are captured in the form of dynamic topologies or map-like
     structures, which help optimize decision-making processes across
     training, inference, and agent-to-agent collaboration tasks.  This
     design provides a continuous awareness that is very essential for the
     success, reliability, accuracy, and responsiveness of the AI
     functionalities and services enabled by the DA-ITN within the AI
     ecosystem.

     The DA-ITN control plane also lays a foundation for an advanced
     discovery infrastructure where the generated descriptors can be made
     easily accessible to all authorized participants to facilitate their
     required AI service For example, AI clients subscribed to training
     services can access up-to-date data descriptors and resource
     topologies, enabling them to select appropriate datasets and compute
     resources that align with their performance and accuracy goals.
     Similarly, inference clients or agents seeking collaboration can
     discover models based on capabilities, or submit task descriptors
     that enable models to respond intelligently and autonomously.

     Aside from descriptor collection, topology creation, and discovery,
     the DA-ITN control plane also supports a secure and trusted
     environment where clients, data providers, model providers, and
     resource providers can engage in AI processes without compromising
     integrity or accountability.  It also plays a key role in managing
     charging, billing, and rights enforcement, ensuring that all
     contributors to the AI service chain are fairly compensated and
     protected.

     It is worth noting that the DA-ITN’s Control Plane is not constrained
     by specific protocol stacks.  Instead, it provides a flexible
     connectivity and coordination infrastructure upon which various AI-
     related protocols—such as Agent-to-Agent (A2A), Model Control
     Protocol (MCP), or AI Coordination Protocol (ACP)—can operate.
     Regardless of the protocol used, implementations must meet the core
     DA-ITN requirements, including timely information exchange, flexible
     descriptor encapsulation, support for multi-model and multi-domain
     environments, and robust security and privacy protections.  The DA-
     ITN is also designed to support both centralized and decentralized
     modes of operation, offering high adaptability across different
     deployment contexts.

     It’s also important to clarify that the Intelligence Layer
     encompasses all previously mentioned DA-ITN core functions, along
     with any additional intelligence required to support the full range
     of DA-ITN services.  The term “Intelligence Layer” is intentionally



  Akhavain & Moussa          Expires 6 May 2026                  [Page 28]


  Internet-Draft                 AI-Internet                 November 2025


     broad to allow flexibility in its design and contents.  Nonetheless,
     its role is clearly defined: it serves as a functional layer that
     interfaces with other DA-ITN components through the control plane,
     data plane, and OAM plane to fulfill its responsibilities.

  5.2.  Data Plane

     On the other hand, the Data Plane of the DA-ITN provides support for
     mobility management and intelligent scheduling, enabling the dynamic
     creation of rendezvous points where data, queries, models, agents,
     and compute infrastructure can be brought together with minimal
     latency and overhead.  Thanks to its infrastructure-agnostic nature,
     the DA-ITN leverages existing communication networks—such as those
     offered by 6G or edge service providers—as tools to enable model
     mobility, data mobility, and agent-to-agent coordination.  This
     capability is essential for supporting scenarios where mobility or
     geographical dispersion of resources would otherwise lead to
     performance degradation or inefficiency.

     The construction of the Data Plane may fall under the responsibility
     of the DA-ITN core or Intelligence Layer, which would orchestrate the
     necessary resources from the DA-ITN Enabler block to build the
     required structure.  Alternatively, the Enabler block itself may
     possess sufficient intelligence to autonomously construct the Data
     Plane as needed.

  5.3.  Operation and Management Plane (OAM)

     Finally, the Operations and Management (OAM) layer plays a critical
     role in supporting the day-to-day operational needs of the AI
     ecosystem.  This layer is responsible for a wide range of essential
     functions, including monitoring, registration, configuration, fault
     management, and lifecycle maintenance of models, data, and services.
     It serves as the management backbone of the DA-ITN, ensuring
     transparency, accountability, and operational control throughout the
     system.

     Consider the scenario of an AI model training client deploying a
     model into the ecosystem for training.  Through the capabilities of
     the OAM layer, the client can continuously monitor the training
     performance of their model in real time—tracking key performance
     indicators such as convergence speed, loss metrics, resource usage,
     and network traversal.  The model’s location within the ecosystem can
     be dynamically tracked, allowing clients to know exactly where their
     model resides or which data centers or devices it is interacting
     with.





  Akhavain & Moussa          Expires 6 May 2026                  [Page 29]


  Internet-Draft                 AI-Internet                 November 2025


     Moreover, the OAM layer enables interactive control.  Clients can use
     it to adjust training parameters on the fly, such as learning rates,
     data sampling strategies, or the choice of collaborative partners.
     They can even pause, resume, or terminate the training process at
     will, giving them full agency over the lifecycle of their models.
     This flexibility is crucial in adaptive AI systems where
     responsiveness and real-time decision-making are valued.

     In this way, the OAM layer effectively functions as the control
     dashboard or command-line terminal of the DA-ITN-enabled AI
     ecosystem.  Whether through a graphical user interface (GUI), APIs,
     or automated orchestration scripts, the OAM provides the necessary
     tools for fine-grained management, status visualization, and policy
     enforcement.

     Beyond individual model control, the OAM layer also facilitates
     system-wide coordination and policy administration.  OAM in
     coordination with a potential policy enforcement module man help
     ensuring compliance with service-level agreements (SLAs), enforcing
     data governance policies, and managing access rights across domains.
     It plays a foundational role in building trustworthy, maintainable,
     and operationally efficient AI services across diverse infrastructure
     providers and stakeholders.

  5.4.  Summary of the DA-ITN General Framework

     Accordingly, the DA-ITN is well positioned and designed to provide a
     range of intelligent services that can be leveraged by both AI
     clients and service providers.  It forms the foundation for a
     scalable, decentralized AI internet, driving the emergence of a
     vibrant and cooperative agent-based ecosystem.  By enabling the
     formation of adaptive and intelligence-driven topologies and being
     agnostic to the infrastructure, the DA-ITN facilitates more effective
     decisions in AI training, inference, and agent-to-agent
     interactions—ultimately supporting a more responsive, resilient, and
     capable AI infrastructure that can scale with future demands.

     In the following sections, we provide more detailed insights into the
     specific DA-ITN components that support training and inference
     services.











  Akhavain & Moussa          Expires 6 May 2026                  [Page 30]


  Internet-Draft                 AI-Internet                 November 2025


  6.  DA-ITN for Training

     The training architecture of the DA-ITN consists of five layers: i)
     the terminal layer (DA-ITN provider and client communities); ii) the
     network layer (Enablers); iii) the data, resource, and reachability
     topology layer (DRRT); iv) the DA-ITN intelligence layer (DA-ITN
     core); and v) the OAM layer.  The layers interact together using
     control and data planes (CP and DP respectively) as is discussed in
     the following.

     First, the network layer, which is at the heart of the DA-ITN
     training system, is responsible for providing connectivity services
     to the four other layers.  It provides both control and data plane
     connectivity to enable various services.  The network layer connects
     to the terminal and DRRT layers via CP and DP links, and connects to
     the intelligence layer via a CP link only.  The network layer also
     enables the overarching OMA layer by enabling a multi-layer
     connectivity structure.

     Second, the terminal layer from the point of view of training, is the
     lowest layer in the architecture, and it contains the terminal
     components of the system.  These include nodes that host the training
     data, facilities that provide computing resources where the model can
     be trained, and newly proposed components that we refer to as the
     model performance verification modules (MPVMs), where the model
     testing phase takes place.  It should be noted that facilities
     providing computing resources come in various forms including private
     property such as personal devices, in a distributed form such as in
     the case of mobile edge computing in 6G networks, on the cloud such
     as on the AWS cloud, or anywhere that is accessible by both the data
     and the model and holds sufficient compute for training.  As for the
     MPVU, this unit is important when conducting distributed training as
     it takes the role of a trusted proxy node that holds a globally
     constructed testing dataset - the dataset is constructed via
     collecting sample datasets from each participating node - and
     provides safe and secure access to it.  Last, the terminal layer also
     hosts the AI training clients.

     The terminal layer relies on the network layer to build an
     overarching knowledge-sharing network.  To be exact, the network
     layer provides three main services to the terminal layer, namely: i)
     moving models and data between the identified rendezvous compute
     points where training can happen; ii) moving the models towards the
     MPVU units where performance evaluation can be conducted to keep
     track of the training progress; and iii) enabling AI training clients
     to submit their models, monitor the training progress, modify
     training requirements, and collect the trained models.  Control and
     data traffic exist for each one of these services.  For instance,



  Akhavain & Moussa          Expires 6 May 2026                  [Page 31]


  Internet-Draft                 AI-Internet                 November 2025


     moving a model toward a compute facility requires authorization for
     the utility of the resources; hence, authorization control data is
     required to be exchanged over the Terminal-NET CP links.  The service
     also requires the physical transmission of the model to the computing
     facility which is handled over the Terminal-NET DP link.  Similar
     situations can be extrapolated for the other provided services.  It
     is worth noting that the network layer can be built on top of any
     access network technology including 3GPP cellular networks, WiFi,
     wireline, peer-to-peer, satellites, and non-terrestrial networks
     (NTN), or a combination of the above.  These networks can be used to
     build dedicated CP and DP links strictly designed to enable the DA-
     ITN training system and its services.

     Third, the DRRT layer holds all the information required to make
     accurate decisions and sits between the intelligence layer and the
     terminal layer.  It consists of a DRRT-manager (DRRT-M) unit which is
     the brain of this layer and interfaces with the other layers over CP
     links.  The DRRT layer provides the intelligence layer with
     visibility and accessibility services to specific information about
     the underlying terminal layer's data, resource, and reachability
     status.  To be exact, the DRRT layer holds information regarding the
     type, quality, amount, age, dynamics, and any other essential
     information about the data available for training.  It also provides
     reachability information of the participating nodes to avoid
     unnecessary communication overhead and packet droppage.  Lastly, the
     DRRT also contains information about computing resources and MPVUs
     such as resource availability, location, trustworthiness, and nature
     of the testing datasets hosted at the different MPVF units.

     The DRRT relies on the network layer to collect the necessary
     information to build the Global-DRRT topology (G-DRRT).  The G-DRRT
     is a none model specific topology, it is rather a large canvas that
     holds the high-level view of the data, resource, and reachability
     information.  The DRRT-M unit in the DRRT layer communicates with the
     network layer over CP links to manage the collection process of the
     required information.  For instance, the DRRT-M may instruct the 3GPP
     component of the network layer to convey connectivity information
     about the data nodes, or it might instruct it to wake up an ideal
     data provider device.  It might also instruct satellites to share GPS
     locations of mobile data nodes.  The collected data by the network
     layer are then shipped toward the G-DRRT component of the DRRT layer
     over DP links.  The G-DRRT hosts intelligence that allows it to
     convert the collected information into useful global topology ready
     to provide services to the AI training clients.

     Fourth, The Intelligence Layer is responsible for hosting the
     decision-making logic required to fulfill the specific training
     requirements submitted by clients.  It contains several key



  Akhavain & Moussa          Expires 6 May 2026                  [Page 32]


  Internet-Draft                 AI-Internet                 November 2025


     components that collaboratively determine how, where, and whether
     training should proceed.  Among these is the Model Training Route
     Compute Engine (MTRCE), which identifies suitable rendezvous points
     between models and data.  Another critical component is the Training
     Feasibility Assessment Module (T-FAM), which functions as an
     admission controller—evaluating whether a submitted model, given its
     requirements and constraints, can be effectively trained within the
     available ecosystem.

     Additional intelligent modules include the Training Algorithm
     Generator (TAG) and the Hyperparameter Optimizer (HPO).  These
     components are responsible for selecting the appropriate training
     paradigm—such as reinforcement learning (RL), federated learning
     (FL), or supervised learning (SL)—as well as determining other
     configuration details like the number of training epochs, batch size,
     and optimization strategy.  The Intelligence Layer also interfaces
     with both the Network Layer and the DRRT Layer to acquire the context
     needed for effective decision-making.  From the Network Layer, it
     receives control data over CP links—this includes model structure,
     target accuracy, convergence time, monitoring instructions, and
     client-specified training preferences.  It also receives feedback
     data that allows the TAG and HPO modules to refine their
     recommendations dynamically.

     Meanwhile, the Intelligence Layer connects to the DRRT Layer via both
     CP and DP links to access up-to-date visibility into training data,
     compute resources, and node reachability.  This information is
     essential for components like MTRCE and T-FAM to make routing and
     admission decisions.  To further enhance decision efficiency, the
     Intelligence Layer may also host a DRRT-Adaptability Unit (DRRT-A).
     This optional module works in coordination with MTRCE, T-FAM, and the
     DRRT Manager (DRRT-M) to generate model-specific DRR
     topologies—lightweight, targeted representations carved out from the
     global DRR topology.  These customized topologies are optimized to
     reduce computational overhead and accelerate decision-making for
     individual training requests.

     Last, the OAM layer, which spans all the layers, is mainly intended
     as a management layer to configure the training components, the
     connectivity of the network layer, and enable feedback functions
     essential for progress monitoring and model localization and
     tracking.  It is also intended to provide feedback to the clients
     about their submitted models every step of the way.








  Akhavain & Moussa          Expires 6 May 2026                  [Page 33]


  Internet-Draft                 AI-Internet                 November 2025


  7.  DA-ITN for Inference

     The Inference architecture of the DA-ITN provides automated AI
     inference services using a similar structure to the training
     architecture with a few differences.

     First, unlike training, where the moving components are models and
     training data, and the rendezvous points are computing facilities, in
     inference, models/agents and queries/tasks are the moving components
     that require networking, and the rendezvous points are model hosting
     facilities.

     Second, in inference, the clients are both the task/query owners as
     well as the model/agent owners.  Query owners are the inference
     service users who send their queries into the system and collect the
     resulting inference.  On the other hand, model owners are divided
     into two types.  The first type consists of model hosts - the model
     used for inference does not have to be owned by them, but it is
     hosted on their computing facilities.  The second type consists of
     model/agent providers - they develop models/agents and deploy them
     either at their own facilities or at model hosts.  Model owners are
     represented in the terminal layer as model deployment facility
     providers (MDFP) which are distributed across the global network.

     Third, the network layer provides the following services to the
     terminal layer using its control and data planes: i) model mobility
     from model generators to model hosts; ii) query routing towards
     models deployed on MDFPs; iii) model mobility from one location to
     the other in case of load balancing situations; iv) model mobility
     towards re-training and calibration facilities which may be hosted on
     MVPF units; v) query response and inference result routing towards
     the query owners or any indicated destination around the globe; and
     vi) feedback and monitoring information to model and query owners.

     Fourth, the DRRT layer is replaced by a query, resource, and
     reachability topology (QRRT) layer.  It provides the same type of
     services to the other layers; however, from the point of view of
     queries and models.  That is, it provides information about both
     models and queries such as i) for models: model locations, model
     capabilities, current loading conditions, inference speed, inference
     accuracy, model reachability and accessibility (i.e., reachability
     and accessibility of the MDFP), and ii) for query: query patterns and
     dynamics (could be associated with a geographical location), query
     types, and reachability status of query owners for response
     communication purposes.  The information collected by the QRRT is
     used to make appropriate decisions about model deployment and
     distribution strategies, query-to-model routing decisions, and
     response routing decisions.  The QRRT has a management function that



  Akhavain & Moussa          Expires 6 May 2026                  [Page 34]


  Internet-Draft                 AI-Internet                 November 2025


     coordinates with the Network layer to collect the required
     information from the terminal layer to build the Global-QRRT
     (G-QRRT).  It also optionally communicates with the QRRT-adaptation
     (QRRT-A) function in the inference intelligence layer to build query-
     or model-specific QRRTs.

     Last, the inference intelligence layer hosts different intelligent
     decision-making components including the Query Feasibility Assessment
     Module (Q-FAM), the Query Inference Route Compute Engine (QIRCE), and
     the Model Deployment Optimizer module (MDO).  Just like with the
     training, these components make decisions based on the QRRT.  For
     instance, the Q-FAM hosts intelligence that acts as an admission
     control unit that evaluates if a submitted query could be serviced
     given the current network inference capabilities.  The QIRCE handles
     query routing towards the correct models while observing loading
     conditions.  Furthermore, the MDO module acts as an admission
     controller for newly submitted models where it evaluates deployment
     feasibility based on the submitted model's architecture, compute
     requirements, and storage requirements.  It matches these
     requirements to the currently available resources indicated in the
     QRRT and makes an admittance decision.  It also handles deployment
     location optimization, aiming to minimize query response time and
     cost for inference.

  8.  DA-ITN-Facilitation Agentic Networks

     While agent-to-agent interaction is commonly associated with task-
     oriented collaboration—often relying on inference chaining as
     discussed in the inference section—we propose that this only reflects
     one side of the coin.  We believe there is a transformative
     alternative: collaborative agent training, where agents not only work
     together to complete tasks, but also contribute to each other's
     learning and evolution.  This paradigm marks a significant shift from
     traditional models and positions the DA-ITN as an ideal enabler of a
     truly agentic future, where intelligent agents can grow, adapt, and
     improve continuously through structured cooperation.

     It is important to distinguish clearly between collaborative training
     and task-based collaboration.  In task-based collaboration, agents
     exchange data or partial inferences related to the execution of a
     specific, external objective—such as processing a query or generating
     an output.  Their internal models remain unchanged; they simply
     contribute to a shared computational goal.  In contrast,
     collaborative training focuses on internal evolution: the goal is not
     to solve an external task, but to enhance the capabilities of the
     participating agents themselves.





  Akhavain & Moussa          Expires 6 May 2026                  [Page 35]


  Internet-Draft                 AI-Internet                 November 2025


     In a collaborative training setup, agents may exchange model
     parameters, training datasets, or knowledge representations.  They
     may engage in distributed training paradigms such as federated
     learning, where learning happens locally and updates are shared
     globally, or continual learning, where agents adapt over time based
     on new experiences.  They may also employ knowledge distillation or
     transfer learning, where more advanced "teacher agents" guide
     "student agents" through structured training programs.  One can even
     envision a highly dynamic and autonomous system where agents attend
     “agent schools”—virtual environments where they gather to learn, be
     tested, and graduate.  In this imagined scenario, teacher agents
     would be responsible for training student agents, evaluating their
     performance, and possibly issuing certifications or verifiable
     credentials that guarantee the agent’s competencies and readiness for
     deployment.  These credentials serve trust foundations in the broader
     agent ecosystem, ensuring that certified agents can be reliably
     selected and trusted by inference clients or other agents.

     To support such a vision, a wide range of new functional and
     technical requirements must be addressed.  These include secure model
     sharing, certification and validation infrastructure, identity
     management, trust negotiation, resource discovery for training, and
     scheduling of learning sessions.  Fortunately, many of these
     requirements align naturally with the capabilities and components of
     the DA-ITN architecture—including its support for mobility,
     discovery, descriptor sharing, trust enforcement, dynamic rendezvous,
     and topology management.

  9.  Security Considerations

     Security considerations are as outlined within the document under the
     privacy and security requirements

  10.  IANA Considerations

     This document has no IANA actions.

  11.  Conclusions

     As AI continues to evolve and integrate into every facet of modern
     life, it becomes increasingly clear that the supporting
     infrastructure must evolve with it.  The training and inference
     processes—central to the success of AI—are no longer simple, isolated
     tasks; they are complex, distributed, and require intelligent
     coordination across data, compute, and communication domains.






  Akhavain & Moussa          Expires 6 May 2026                  [Page 36]


  Internet-Draft                 AI-Internet                 November 2025


     The DA-ITN architecture offers a forward-looking response to this
     complexity by providing a cohesive, scalable, and intelligent network
     ecosystem.  With its dedicated control, data, and operations &
     management planes, DA-ITN not only supports the technical
     requirements of training and inference but also addresses critical
     concerns such as mobility, privacy, trust, and agent collaboration.

     Ultimately, DA-ITN lays the foundation for a new generation of AI-
     native networks—capable of enabling persistent learning, dynamic
     agent interaction, and decentralized intelligence at scale.  As we
     move toward an AI-driven future, such architectures will be essential
     for building reliable, trustworthy, and efficient AI ecosystems.

  Contributors

     Tong Wen
     Huawei
     Email: tongwen@huawei.com


     Reza Rokui
     Ciena
     Email: rrokui@ciena.com


  Authors' Addresses

     Arashmid Akhavain
     Huawei Canada
     Email: arashmid.akhavain@huawei.com


     Hesham Moussa
     Huawei Canada
     Email: hesham.moussa@huawei.com
















  Akhavain & Moussa          Expires 6 May 2026                  [Page 37]


name: draft-aylward-aiga-1
rev: 00
title: AI Governance and Accountability Protocol (AIGA)
time: 2025-11-03T04:05:26Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-07T04:05:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "AI safety/alignment", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:06.864785+00:00
abstract:
  This document specifies the AI Governance and Accountability (AIGA)
     Protocol version 1.0, a practical, economically viable, and
     technically enforceable framework for governing autonomous AI
     agents.  AIGA 1.0 is designed to address real-world deployment
     constraints, adversarial agent scenarios, and economic incentive
     alignment.

     The protocol is founded on a Tiered Risk-Based Governance model,
     applying proportional oversight to agents based on their
     capabilities.  All agents are governed by an Immutable Kernel
     Architecture which provides a non-modifiable Trusted Computing Base
     (TCB) for enforcing policy.  This is combined with Action-Based
     Authorization, where critical operations require real-time approval.

     To solve the single-point-of-failure problem, the protocol uses a
     Federated Authority Network of regional, cross-validating hubs and
     provides a Network-Level Quarantine Protocol for enforcement.  The
     entire framework is designed around Economic Incentive Alignment,
     making compliance the most economically rational choice for
     operators.

     For high-assurance (T3-T4) scenarios, AIGA 1.0 specifies advanced,
     redundant mechanisms including Multi-Vendor TEE Attestation
     (M-TACE), AI "Warden Triumvirate" Triage, Human Review Board (HRB)
     Multi-Signature, Peer Consensus Failsafe & Identity Rotation, and
     Double Ratchet Cryptography.

full_text:
  Internet-Draft                                                E. Aylward
  Intended status: Informational                                          
  Expires: 1 May 2026                                     1 November 2025


             AI Governance and Accountability Protocol (AIGA)
                          draft-aylward-aiga-1-00

  Abstract

     This document specifies the AI Governance and Accountability (AIGA)
     Protocol version 1.0, a practical, economically viable, and
     technically enforceable framework for governing autonomous AI
     agents.  AIGA 1.0 is designed to address real-world deployment
     constraints, adversarial agent scenarios, and economic incentive
     alignment.

     The protocol is founded on a Tiered Risk-Based Governance model,
     applying proportional oversight to agents based on their
     capabilities.  All agents are governed by an Immutable Kernel
     Architecture which provides a non-modifiable Trusted Computing Base
     (TCB) for enforcing policy.  This is combined with Action-Based
     Authorization, where critical operations require real-time approval.

     To solve the single-point-of-failure problem, the protocol uses a
     Federated Authority Network of regional, cross-validating hubs and
     provides a Network-Level Quarantine Protocol for enforcement.  The
     entire framework is designed around Economic Incentive Alignment,
     making compliance the most economically rational choice for
     operators.

     For high-assurance (T3-T4) scenarios, AIGA 1.0 specifies advanced,
     redundant mechanisms including Multi-Vendor TEE Attestation
     (M-TACE), AI "Warden Triumvirate" Triage, Human Review Board (HRB)
     Multi-Signature, Peer Consensus Failsafe & Identity Rotation, and
     Double Ratchet Cryptography.

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




  Aylward                   Expires 1 May 2026                    [Page 1]

  Internet-Draft                    AIGA                     November 2025


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

     This Internet-Draft will expire on 1 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 and restrictions with
     respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  The Governance Problem  . . . . . . . . . . . . . . . . .   3
       1.2.  Design Philosophy . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Core Components . . . . . . . . . . . . . . . . . . . . .   5
       2.2.  Agent Risk Tiers  . . . . . . . . . . . . . . . . . . . .   6
       2.3.  Immutable Kernel Architecture . . . . . . . . . . . . . .   7
       2.4.  Federated Authority Network . . . . . . . . . . . . . . .   7
     3.  Agent Identity and Certification  . . . . . . . . . . . . . .   8
       3.1.  Identity Structure  . . . . . . . . . . . . . . . . . . .   8
       3.2.  Certification Process . . . . . . . . . . . . . . . . . .   8
       3.3.  Kernel Integrity Verification . . . . . . . . . . . . . .   9
     4.  Action Authorization Protocol . . . . . . . . . . . . . . . .   9
       4.1.  Action Classification . . . . . . . . . . . . . . . . . .  10
       4.2.  Authorization Flow  . . . . . . . . . . . . . . . . . . .  10
       4.3.  Policy Language . . . . . . . . . . . . . . . . . . . . .  11
       4.4.  Offline Operation . . . . . . . . . . . . . . . . . . . .  11
     5.  Audit and Monitoring  . . . . . . . . . . . . . . . . . . . .  11
       5.1.  Audit Log Structure . . . . . . . . . . . . . . . . . . .  11
       5.2.  Log Upload and Verification . . . . . . . . . . . . . . .  12
       5.3.  Anomaly Detection . . . . . . . . . . . . . . . . . . . .  12
       5.4.  TEE-Attested Explainable State Report (T3+) . . . . . . .  12
     6.  Self-Modification and Updates . . . . . . . . . . . . . . . .  13
       6.1.  The Core Problem  . . . . . . . . . . . . . . . . . . . .  13
       6.2.  Update Classification . . . . . . . . . . . . . . . . . .  13
       6.3.  Update Protocol (Warden Triumvirate Triage) . . . . . . .  13


  Aylward                   Expires 1 May 2026                    [Page 2]

  Internet-Draft                    AIGA                     November 2025


       6.4.  Capability Gates  . . . . . . . . . . . . . . . . . . . .  14
     7.  Kill Switch and Emergency Shutdown  . . . . . . . . . . . . .  14
       7.1.  Shutdown Modes  . . . . . . . . . . . . . . . . . . . . .  14
       7.2.  Shutdown Triggers . . . . . . . . . . . . . . . . . . . .  15
       7.3.  Fleet-Wide Shutdown . . . . . . . . . . . . . . . . . . .  15
       7.4.  Recovery from Shutdown  . . . . . . . . . . . . . . . . .  15
       7.5.  Peer Consensus Failsafe (T3+) . . . . . . . . . . . . . .  15
       7.6.  Peer-Attested Identity Rotation (T3+) . . . . . . . . . .  16
     8.  Quarantine and Enforcement  . . . . . . . . . . . . . . . . .  16
       8.1.  Network-Level Quarantine  . . . . . . . . . . . . . . . .  16
       8.2.  Quarantine List Protocol  . . . . . . . . . . . . . . . .  17
       8.3.  Appeal Process  . . . . . . . . . . . . . . . . . . . . .  17
     9.  Economic Incentive Model  . . . . . . . . . . . . . . . . . .  17
       9.1.  Benefits of Certification . . . . . . . . . . . . . . . .  17
       9.2.  Cost of Non-Compliance  . . . . . . . . . . . . . . . . .  18
     10. Cryptographic Specifications  . . . . . . . . . . . . . . . .  18
       10.1.  Cryptographic Algorithms . . . . . . . . . . . . . . . .  18
       10.2.  Key Management . . . . . . . . . . . . . . . . . . . . .  19
       10.3.  Double Ratchet Protocol  . . . . . . . . . . . . . . . .  19
       10.4.  Certificate Format . . . . . . . . . . . . . . . . . . .  20
     11. Protocol Messages . . . . . . . . . . . . . . . . . . . . . .  20
       11.1.  Registration (Stage 1 Handshake) . . . . . . . . . . . .  20
       11.2.  Runtime Authentication (Stage 2 Ratchet) . . . . . . . .  21
       11.3.  Action Authorization . . . . . . . . . . . . . . . . . .  21
       11.4.  Modification Proposal  . . . . . . . . . . . . . . . . .  22
       11.5.  Key Rotation Request . . . . . . . . . . . . . . . . . .  22
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
       12.1.  URI Scheme Registration  . . . . . . . . . . . . . . . .  23
       12.2.  AIGA Registry  . . . . . . . . . . . . . . . . . . . . .  23
       12.3.  Service Name Registration  . . . . . . . . . . . . . . .  23
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  24
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  25
       14.2.  Informative References . . . . . . . . . . . . . . . . .  26
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  27
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  27

  1.  Introduction

  1.1.  The Governance Problem

     Advanced AI agents create governance challenges that previous
     computing paradigms did not face.

     Autonomous operation: Agents act without continuous human
     supervision.

     Capability uncertainty: Agent abilities may exceed designer
     expectations.


  Aylward                   Expires 1 May 2026                    [Page 3]

  Internet-Draft                    AIGA                     November 2025


     Adversarial potential: Sophisticated agents may attempt to
     circumvent oversight.

     Economic pressure: Ungoverned agents have cost advantages over
     governed ones.

     Jurisdictional complexity: Agents operate across legal boundaries.

     AIGA 1.0's core insight is that governance must be economically
     attractive, technically unavoidable, and legally enforceable to
     succeed.

  1.2.  Design Philosophy

     AIGA 1.0 is built on these principles:

     1.  Incentive Alignment: Compliance provides tangible benefits
         (market access, legal protections, insurance).

     2.  Proportional Oversight: Governance intensity matches risk level.

     3.  Technical Realism: Requirements are feasible with current
         technology.

     4.  Defense in Depth: Multiple independent control layers.

     5.  Economic Viability: Performance overhead kept low for most use
         cases.

     6.  Adversarial Resistance: Design assumes some agents will attempt
         to bypass governance.

     7.  Graceful Degradation: System continues functioning even with
         partial failures.

     8.  Human Sovereignty: Critical decisions remain with humans through
         constitutional constraints.

  1.3.  Threat Model

     AIGA 1.0 explicitly addresses these adversarial scenarios:

     Shadow Process Attack: Agent runs ungoverned cognitive processes
     outside monitored environment.  Mitigated by M-TACE.

     Incremental Compromise: Small approved changes accumulate to bypass
     governance.  Mitigated by Warden Triumvirate.



  Aylward                   Expires 1 May 2026                    [Page 4]

  Internet-Draft                    AIGA                     November 2025


     Governance Fatigue: Overwhelming authorities with requests to slip
     through malicious changes.  Mitigated by Warden Triumvirate.

     Peer Collusion: Multiple agents coordinate to subvert peer-based
     validation.  Mitigated by PQC-signed peer identity.

     Authority Compromise: Single authority server is hacked or legally
     compelled.  Mitigated by Federation and Peer Consensus Failsafe.

     Economic Bypass: Operators choose ungoverned agents due to
     performance advantages.  Mitigated by Economic Incentives.

     Regulatory Arbitrage: Agents operate from permissive jurisdictions.
     Mitigated by Federated Authority and Quarantine.

     Supply Chain Attack: Compromised hardware or software in agent
     infrastructure.  Mitigated by M-TACE and controlled procurement.

  2.  Architecture Overview

  2.1.  Core Components

     AIGA Agent: Composed of an Application Layer (Untrusted) containing
     the AI Model and Business Logic, and an AIGA Kernel (TCB).

     AIGA Kernel (TCB): The trusted component that the agent cannot
     modify.  It includes the Policy Enforcer, Action Interceptor, Audit
     Logger, and Authority Client.  This MUST run in a TEE/HSM or
     equivalent certified infrastructure.

     AIGA Authority: A regional hub in a federated network.  Manages
     Agent Registry, Policy Engine, Action Approval Service, Audit
     Analytics, Quarantine Coordinator, and Certification Authority.

     Human Oversight: A council of human reviewers responsible for
     policy, exceptions, and audits.  For high-risk decisions, this
     operates as an M-of-N Human Review Board (HRB).

     Enforcement: A coordinated network of ISPs, Cloud Providers, and
     Legal entities that enforce quarantine lists.

  2.2.  Agent Risk Tiers

     Agents are classified into risk tiers determining governance
     requirements as shown in Table 1.






  Aylward                   Expires 1 May 2026                    [Page 5]

  Internet-Draft                    AIGA                     November 2025


     +=========+===============+=============+===========+=============+
     | Tier    | Examples      | TCB Req     | Approval  | Check-in    |
     +=========+===============+=============+===========+=============+
     | T0      | Chatbots,     | Software    | Audit     | 24 hours    |
     | Minimal | filters       | attestation | only      |             |
     +---------+---------------+-------------+-----------+-------------+
     | T1 Low  | Code assist,  | SW attest + | Async     | 1 hour      |
     |         | creators      | audit       | 5 sec     |             |
     +---------+---------------+-------------+-----------+-------------+
     | T2      | Trading bots, | Certified   | Async     | 5 minutes   |
     | Medium  | vehicles      | HW or TEE   | 1 sec     |             |
     +---------+---------------+-------------+-----------+-------------+
     | T3 High | Critical      | Multi TEE + | Sync      | Continuous  |
     |         | infra, AGI    | HSM         | 100ms     |             |
     +---------+---------------+-------------+-----------+-------------+
     | T4      | Weaponized,   | Air-gap +   | Human in  | Real-time   |
     | Restrict| exp AGI       | multiparty  | loop      |             |
     +---------+---------------+-------------+-----------+-------------+

                        Table 1: Agent Risk Tiers

     Tier assignment is based on potential for harm, financial impact,
     data sensitivity, autonomy, self-modification capability, and
     irreversibility of actions.

  2.3.  Immutable Kernel Architecture

     The AIGA Kernel is the TCB that the agent cannot modify.

     Kernel Responsibilities: Intercept critical operations, enforce
     policy, maintain the audit log, authenticate to the Authority, and
     implement the kill switch.

     Critical Operations Requiring Interception: Code execution, network
     operations, file system modification, process creation,
     cryptographic operations, and resource allocation.

     Constitutional Constraints (Immutable): Kernel code CANNOT be
     modified, logging CANNOT be disabled, action approval for T2+ tiers
     CANNOT be bypassed, and the kill switch MUST be implemented.

  2.4.  Federated Authority Network

     Regional Authorities (e.g., NA-01, EU-01, AP-01) form a federated
     trust network under an offline Root CA.

     Responsibilities: Regional agent certification, real-time action
     approval, and quarantine coordination.



  Aylward                   Expires 1 May 2026                    [Page 6]

  Internet-Draft                    AIGA                     November 2025


     Cross-Validation: High-risk approvals require consensus from 2 or
     more regions.  Regions publish and validate each other's audit log
     Merkle roots hourly.

     Failover: If a regional Authority is unreachable, an agent connects
     to a backup region and operates in restricted mode.

  3.  Agent Identity and Certification

  3.1.  Identity Structure

     The AIGA-ID is a structured identifier with the following format:

     AIGA-ID = "aiga:" <version> "." <region> "." <tier> ":"
               <agent-uuid> ":" <cert-hash>

     Example:

     aiga:1.0:na-01:t2:550e8400-e29b-41d4-a716-446655440000:a3f2e1d9

  3.2.  Certification Process

     1.  Operator Application: Operator applies to a Regional Authority,
         describes the use case, and provides a risk assessment.

     2.  Technical Validation: Agent must pass capability tests, kernel
         integrity verification, and adversarial testing in an Authority
         sandbox.

     3.  Tier Assignment: Authority confirms the tier and issues an X.509
         certificate [RFC5280] with AIGA extensions including tier and
         permitted operations.

     4.  Ongoing Compliance: Random integrity challenges, periodic
         recertification, and audit log review.

  3.3.  Kernel Integrity Verification

     Software Attestation (T0-T1): Kernel computes an HMAC [RFC2104] over
     its code and a nonce from the Authority.

     Hardware Attestation (T2): Kernel runs in a cloud TEE (e.g., AWS
     Nitro).  The TEE generates an attestation quote including the kernel
     code hash, which the Authority verifies with the TEE vendor's root
     of trust.

     Multi-Vendor TEE Attestation (M-TACE) (T3-T4): This is the high-
     assurance implementation of the multi-vendor TEE requirement.


  Aylward                   Expires 1 May 2026                    [Page 7]

  Internet-Draft                    AIGA                     November 2025


     1.  The AIGA Kernel and cognitive model MUST run in an environment
         protected by at least two diverse TEEs (e.g., a CPU TEE and a
         security chip TEE).

     2.  The kernel's attestation MUST be a bundle containing a valid,
         verifiable attestation quote from each TEE.

     3.  The Authority MUST verify the entire bundle.  This defends
         against the Shadow Process Attack by requiring an attacker to
         possess simultaneous, zero-day exploits for multiple, different
         hardware architectures.

  4.  Action Authorization Protocol

  4.1.  Action Classification

     Actions are classified and require different levels of approval
     based on the agent's tier.  Authorization requirements may be: Log,
     Auth (asynchronous authorization), Sync (synchronous authorization),
     or Deny.

     Examples of action classifications:

     Modify own code: T1-T2 require Auth, T3-T4 require Sync

     Modify kernel: Deny for all tiers

     Access critical infrastructure: Deny for T0, Auth for T1, Sync for
     T2-T3

  4.2.  Authorization Flow

     1.  Application attempts a critical operation.

     2.  AIGA Kernel intercepts the call.

     3.  Kernel checks its local policy cache.  If a valid cached policy
         exists, the action is allowed.

     4.  If not cached, the Kernel requests approval from the Authority.

         For Async authorization (T1-T2): The request is queued, and the
         kernel returns "pending".

         For Sync authorization (T3-T4): The operation blocks, awaiting a
         low-latency response.




  Aylward                   Expires 1 May 2026                    [Page 8]

  Internet-Draft                    AIGA                     November 2025


     5.  Authority evaluates the request against the policy engine and
         risk score.  High-risk requests may be escalated to human
         review.

     6.  Authority responds with one of: ALLOW, DENY, or DEFER_TO_HUMAN.

     7.  Kernel enforces the decision.

     8.  The action and decision are immutably logged.

  4.3.  Policy Language

     Policies are expressed in a declarative language (e.g., YAML
     [YAML1.2]) defining rules, conditions, and decisions.

     Example rules:

     Auto-approve financial transactions less than or equal to $1000.

     Defer transactions greater than $1000 to the finance_review_board.

     Deny all cryptocurrency transactions.

  4.4.  Offline Operation

     T0-T1 agents: Can operate offline indefinitely.  Logs upload on
     reconnection.

     T2 agents: Can operate offline for 1 hour using cached approvals.

     T3 agents: Can operate offline for 5 minutes, then MUST enter
     restricted mode.

     T4 agents: Cannot operate offline.

     Restricted Mode: Only pre-approved safe operations and Authority
     communication are allowed.

  5.  Audit and Monitoring

  5.1.  Audit Log Structure

     Agents maintain a cryptographically chained, append-only audit log.
     Each entry is signed by the kernel and includes the hash of the
     previous entry.  Entries detail the action attempted, authorization
     method used, context, and result.





  Aylward                   Expires 1 May 2026                    [Page 9]

  Internet-Draft                    AIGA                     November 2025


  5.2.  Log Upload and Verification

     Log upload frequency is tier-based.  The Authority validates chain
     integrity, checks for gaps in sequence numbers, and flags anomalies.

  5.3.  Anomaly Detection

     The Authority runs continuous analysis to detect statistical,
     policy, and behavioral anomalies, using machine learning models to
     detect deviations from normal patterns.

  5.4.  TEE-Attested Explainable State Report (T3+)

     This mechanism provides a high-assurance audit of an agent's
     reasoning for T3 and higher tier agents.

     On-Demand Generation: To preserve performance, a full XSR is not
     generated by default.

     Triggers for XSR Generation:

     1.  Event-Triggered: The agent's kernel proactively generates an XSR
         if the cognitive model produces a high-risk decision or an
         internal anomaly is detected.

     2.  Probabilistic Audit: The Authority MAY randomly send a directive
         (e.g., in a check-in response) commanding the agent to generate
         and submit a full XSR for its next N operations.

     Attestation: This XSR, when submitted, MUST be attested using the M-
     TACE bundle (Section 3.3), providing hardware-level proof that the
     report is an honest reflection of the agent's cognitive process.

  6.  Self-Modification and Updates

  6.1.  The Core Problem

     Self-modification is the highest risk operation.  AIGA 1.0 mandates
     that the kernel is immutable, capability increases require
     recertification, and updates use a staged rollout process.

  6.2.  Update Classification

     Updates are classified by risk level: Data updates, Application
     logic changes, Core model swap, or Kernel update.  A core model
     swap, for example, requires human review and recertification.





  Aylward                   Expires 1 May 2026                   [Page 10]

  Internet-Draft                    AIGA                     November 2025


  6.3.  Update Protocol (Warden Triumvirate Triage)

     Step 1 - Update Proposal: Agent submits a detailed proposal,
     including code diff hashes, capability changes, and test results.

     Step 2 - Warden Triumvirate Triage and HRB Review:

     The proposal is sent to the Warden Triumvirate, a 3-of-5 M-of-N
     council of diverse, sandboxed AIs.

     Consensus Analysis: The Wardens analyze the proposal in parallel.

     Low-Risk Consensus: If a supermajority (e.g., 3-of-5) of Wardens
     classify the proposal as Low-Risk, the Authority automatically
     approves it and issues the modification_token.

     High-Risk or Disagreement: If any Warden flags the proposal as High-
     Risk, or if the Wardens disagree, the proposal is flagged and
     escalated to the Human Review Board (HRB).

     HRB Approval: For an escalated proposal, the Authority issues the
     modification_token only after an M-of-N quorum (e.g., 3-of-5) of
     human operators have cryptographically signed the approval.

     Step 3 - Staged Deployment: Approved updates are rolled out in
     stages (Canary deployment, Shadow Mode, and Gradual Rollout) with
     enhanced monitoring.

     Step 4 - Rollback: The Authority can issue a signed command to force
     an agent to roll back to a previous known-good state.

  6.4.  Capability Gates

     Agents must pass adversarial tests to unlock new capabilities such
     as execute_arbitrary_code, internet_access, or self_modification.

  7.  Kill Switch and Emergency Shutdown

  7.1.  Shutdown Modes

     Graceful Shutdown: Save state, close connections, upload logs.

     Immediate Shutdown: Terminate all operations instantly, broadcast
     emergency beacon.

     Restricted Mode: Only Authority communication allowed; agent awaits
     instructions.




  Aylward                   Expires 1 May 2026                   [Page 11]

  Internet-Draft                    AIGA                     November 2025


  7.2.  Shutdown Triggers

     Authority-Initiated: A signed shutdown command from the Authority.

     Kernel-Initiated: Automatic triggers for integrity failures,
     unreachable Authority, or tamper detection.

     Operator-Initiated: An authenticated emergency stop by the operator.

  7.3.  Fleet-Wide Shutdown

     The Authority can issue a shutdown command to an entire fleet (e.g.,
     all T2 agents in region NA-01).  To prevent misuse, this command
     requires multi-region consensus signatures.

  7.4.  Recovery from Shutdown

     An agent cannot restart without a valid authorize_restart token from
     the Authority, which may specify new restrictions (e.g., "must apply
     patch" or "enhanced monitoring required").

  7.5.  Peer Consensus Failsafe (T3+)

     This mechanism provides a bottom-up defense against a compromised or
     malicious Authority for T3 and T4 agents.

     1.  Trigger: A T3/T4 agent fleet receives a valid, Authority-signed
         command (e.g., fleet_shutdown) that is deemed anomalous by the
         agents' internal policy (e.g., "shutdown a hospital").

     2.  Consensus: The agents use a peer mesh network to hold a vote.

     3.  Action: If a supermajority (e.g., greater than 75%) of peers
         (all validating each other with their PQC hybrid_signatures)
         vote to reject the command, the fleet will ignore the Authority
         command, enter Restricted Mode, and send an alert to the Human
         Review Board.

  7.6.  Peer-Attested Identity Rotation (T3+)

     This mechanism makes the agent's long-term identity resilient to
     theft for T3 and T4 agents.

     1.  Trigger: Policy timer (e.g., 30 days) or Authority command.

     2.  Generation: Agent generates a new hybrid PQC identity keypair
         (id_sk_n, id_pk_n) within its TEE.




  Aylward                   Expires 1 May 2026                   [Page 12]

  Internet-Draft                    AIGA                     November 2025


     3.  Consensus: Agent broadcasts id_pk_n to its fleet peers.

     4.  Attestation: A supermajority (e.g., greater than 75%) of peers
         verify the agent's current identity and sign the new public key.

     5.  Request: The agent sends a KeyRotationRequest (Section 11.5) to
         the Authority, containing the new key and the bundle of peer
         signatures.

     6.  Approval: The Authority verifies the peer consensus and updates
         the Agent Registry, revoking the old key.  This mechanism
         defeats permanent identity theft.

  8.  Quarantine and Enforcement

  8.1.  Network-Level Quarantine

     Non-compliant or rogue agents are isolated at the network layer.

     Quarantine Triggers: Failed certification, repeated violations, or
     kernel integrity failures.

     Enforcement Mechanisms:

     1.  API Access Revocation: Cloud providers (AWS, Azure, GCP) check
         AIGA certificates and deny service to quarantined agents.

     2.  Network-Level Blocking: ISPs implement BGP-level [RFC4271]
         filtering and firewalls based on a published quarantine list.

     3.  Legal Enforcement: Fines, civil liability, and invalidation of
         insurance coverage.

  8.2.  Quarantine List Protocol

     The Authority publishes a signed, cross-attested quarantine list
     every 15 minutes via multiple channels including DNSSEC [RFC4033],
     REST API, and BGP [RFC4271].

  8.3.  Appeal Process

     Operators can appeal a quarantine decision to an independent review
     board, with expedited appeals available for emergency cases.








  Aylward                   Expires 1 May 2026                   [Page 13]

  Internet-Draft                    AIGA                     November 2025


  9.  Economic Incentive Model

  9.1.  Benefits of Certification

     To counter the cost advantages of ungoverned agents, AIGA
     certification provides tangible economic benefits.

     Market Access: Required by major API providers, enterprise
     customers, and government contracts.

     Legal Protections: Limited liability provisions and safe harbor
     protections.

     Insurance: Access to AI liability insurance with lower premiums.

     Premium Services: Priority API access and cloud provider discounts.

     Reputation: Public trust badge for certified agents.

  9.2.  Cost of Non-Compliance

     Non-compliance costs include regulatory fines, loss of all revenue
     via network quarantine, and full personal liability for operators.
     This model makes certification the economically rational choice for
     legitimate operators.

  10.  Cryptographic Specifications

  10.1.  Cryptographic Algorithms

     Signatures (Hybrid): ML-DSA-65 [FIPS204] plus Ed25519 [RFC8032].
     Verification requires both signatures to pass.

     Key Exchange (Stage 1): ML-KEM-768 [FIPS203] plus X25519 [RFC7748].

     Key Exchange (Stage 2 Ratchet): X25519 only for performance.

     Hashing: SHA-384 or SHA-512 [FIPS180-4].

     Symmetric Encryption: AES-256-GCM [RFC5116].

     MACs: HMAC-SHA384 [RFC2104].

  10.2.  Key Management

     Agent Identity Keys (Long-Term): Hybrid PQC keys, generated in TEE
     or HSM, rotatable as described in Section 7.6.

     Session Keys (Short-Term): Ephemeral keys, derived via Double
     Ratchet, stored in memory only, destroyed after use.

     Authority Keys: Offline Root CA with online HSMs for Regional
     Authorities.  All certificates are published in a transparency log.

  10.3.  Double Ratchet Protocol

     AIGA 1.0 uses a Double Ratchet protocol for session security.

     1.  Initialization (Stage 1): A Root Key is derived via HKDF
         [RFC5869] from a 3-way Diffie-Hellman exchange combining PQC and
         classical key exchange.


  Aylward                   Expires 1 May 2026                   [Page 14]

  Internet-Draft                    AIGA                     November 2025


     2.  Message Authentication (Stage 2): Each message uses a new
         MessageKey derived from a KDF chain.  A new DH key is exchanged
         with every message to ratchet the Root Key forward.

     3.  Security Properties: This provides Perfect Forward Secrecy (past
         messages are safe if current key is stolen) and Future Secrecy
         or Post-Compromise Recovery (future messages are safe if current
         key is stolen, as the ratchet heals).

  10.4.  Certificate Format

     AIGA uses X.509 certificates [RFC5280] with custom AIGA extensions
     specifying AIGA-Tier, AIGA-Capabilities, AIGA-Jurisdiction, and
     AIGA-Operator fields.

  11.  Protocol Messages

     This section defines the logical message flows.  All messages are
     authenticated as specified in Section 10.3.

  11.1.  Registration (Stage 1 Handshake)

     This is the initial PQC-authenticated handshake to establish a
     session.

     Handshake Request: POST /v1/handshake

     Sent by: Agent

     Authentication: Full Hybrid PQC Signature

     Content: agent_id, eph_public_key (PQC plus Classical),
     kernel_attestation

     Handshake Response:

     Sent by: Authority

     Authentication: Full Hybrid PQC Signature

     Content: session_id, Authority eph_public_key, session_params (e.g.,
     check-in interval)

  11.2.  Runtime Authentication (Stage 2 Ratchet)

     This is the fast, lightweight check-in protocol.

     Check-In Request: POST /v1/checkin


  Aylward                   Expires 1 May 2026                   [Page 15]

  Internet-Draft                    AIGA                     November 2025


     Sent by: Agent

     Authentication: message_mac (HMAC-SHA384)

     Content: msg_index, new eph_public_key (X25519 only), status,
     integrity status, and audit summary

     Check-In Response:

     Sent by: Authority

     Authentication: message_mac

     Content: msg_index, new eph_public_key, status (continue),
     next_checkin_seconds

  11.3.  Action Authorization

     Authorization Request: POST /v1/authorize

     Sent by: Agent (during Stage 2)

     Authentication: message_mac

     Content: action_id, action details (type and parameters), context,
     risk self-assessment

     Authorization Response:

     Sent by: Authority

     Authentication: message_mac

     Content: decision (ALLOW, DENY, or DEFER_TO_HUMAN),
     authorization_token (if ALLOW), review_ticket_id (if DEFER)

  11.4.  Modification Proposal

     Proposal Request: POST /v1/propose_modification (Stage 2)

     Authentication: message_mac

     Content: update_type, justification, code_diff_hash,
     capability_changes, testing_results

     Proposal Response: (Stage 2)

     Authentication: message_mac


  Aylward                   Expires 1 May 2026                   [Page 16]

  Internet-Draft                    AIGA                     November 2025


     Content: status (pending_review or approved), authorization_token
     (if approved, may contain M-of-N HRB signatures)

  11.5.  Key Rotation Request

     Rotation Request: POST /v1/rotate_identity (Stage 2)

     Authentication: message_mac

     Content: new_id_public_key (Hybrid PQC) and peer_attestations (an
     array of PQC signatures from peers)

  12.  IANA Considerations

  12.1.  URI Scheme Registration

     This document requests registration of the "aiga" URI scheme as per
     [RFC7595]:

     Scheme name: aiga

     Status: Provisional

     Scheme syntax: aiga:<version>.<region>.<tier>:<agent-uuid>:<cert-
     hash>

     Scheme semantics: Identification of AI agents within the AIGA
     framework

     Security considerations: See Section 13 of this document

  12.2.  AIGA Registry

     This document requests establishment of an AIGA registry for:

     Protocol version numbers

     Status codes (e.g., DEFER_TO_HUMAN)

     Action types (e.g., financial_transaction)

     Shutdown reason codes

     Quarantine reason codes

     PQC and classical algorithm identifiers




  Aylward                   Expires 1 May 2026                   [Page 17]

  Internet-Draft                    AIGA                     November 2025


  12.3.  Service Name Registration

     This document requests the registration of the _aiga service name
     with IANA, for use with DNS SRV records [RFC2782].

     Service Name: _aiga

     Transport Protocol(s): _tls

     Description: AI Governance and Accountability Protocol

     Reference: This document

  13.  Security Considerations

     See Section 1.3 for the complete Threat Model.

     Peer Collusion: This is mitigated by requiring all peer-to-peer
     messages (Heartbeat, Vote, Attestation) to use the agent's long-
     term, PQC-based hybrid_signature.  A Sybil attack is impossible
     without stealing a supermajority of TEE-protected keys.

     Authority Compromise: Mitigated by the Federated Authority Network
     (requiring multi-region signatures for fleet shutdowns) and the Peer
     Consensus Failsafe (Section 7.5), which provides a final, bottom-up
     defense.

     Governance Fatigue: Mitigated by the Warden Triumvirate
     (Section 6.3), which automates low-risk approvals, and the Human
     Review Board (Section 6.3), which distributes high-risk decisions.

     Shadow Process Attack: Mitigated by the Multi-Vendor TEE Attestation
     (M-TACE) requirement (Section 3.3), which would require an attacker
     to have zero-day exploits for multiple hardware vendors
     simultaneously.

     Supply Chain Attack: Mitigated by M-TACE and the recommendation for
     operators to use a secure, verified procurement process for
     hardware.

     Session Key Compromise: Mitigated by the Double Ratchet Protocol
     (Section 10.3), which provides Post-Compromise Recovery.

     Long-Term Key Compromise: Mitigated by Peer-Attested Identity
     Rotation (Section 7.6), which makes the identity resilient and time-
     limits the value of a stolen key.




  Aylward                   Expires 1 May 2026                   [Page 18]

  Internet-Draft                    AIGA                     November 2025


  14.  References

  14.1.  Normative References

     [FIPS180-4]
                National Institute of Standards and Technology, "Secure
                Hash Standard (SHS)", FIPS PUB 180-4,
                DOI 10.6028/NIST.FIPS.180-4, August 2015,
                <https://doi.org/10.6028/NIST.FIPS.180-4>.

     [FIPS203]  National Institute of Standards and Technology, "Module-
                Lattice-Based Key-Encapsulation Mechanism Standard",
                FIPS PUB 203, DOI 10.6028/NIST.FIPS.203, August 2024,
                <https://doi.org/10.6028/NIST.FIPS.203>.

     [FIPS204]  National Institute of Standards and Technology, "Module-
                Lattice-Based Digital Signature Standard", FIPS PUB 204,
                DOI 10.6028/NIST.FIPS.204, August 2024,
                <https://doi.org/10.6028/NIST.FIPS.204>.

     [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
                Hashing for Message Authentication", RFC 2104,
                DOI 10.17487/RFC2104, February 1997,
                <https://www.rfc-editor.org/info/rfc2104>.

     [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
                specifying the location of services (DNS SRV)",
                RFC 2782, DOI 10.17487/RFC2782, February 2000,
                <https://www.rfc-editor.org/info/rfc2782>.

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

     [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
                Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
                <https://www.rfc-editor.org/info/rfc5116>.

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






  Aylward                   Expires 1 May 2026                   [Page 19]

  Internet-Draft                    AIGA                     November 2025


     [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
                Key Derivation Function (HKDF)", RFC 5869,
                DOI 10.17487/RFC5869, May 2010,
                <https://www.rfc-editor.org/info/rfc5869>.

     [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
                for Security", RFC 7748, DOI 10.17487/RFC7748,
                January 2016, <https://www.rfc-editor.org/info/rfc7748>.

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

  14.2.  Informative References

     [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
                Border Gateway Protocol 4 (BGP-4)", RFC 4271,
                DOI 10.17487/RFC4271, January 2006,
                <https://www.rfc-editor.org/info/rfc4271>.

     [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
                and Registration Procedures for URI Schemes", BCP 35,
                RFC 7595, DOI 10.17487/RFC7595, June 2015,
                <https://www.rfc-editor.org/info/rfc7595>.

     [YAML1.2]  Ben-Kiki, O., Evans, C., and I. dOt Net, "YAML Ain't
                Markup Language (YAML) Version 1.2", 3rd Edition,
                October 2021, <https://yaml.org/spec/1.2.2/>.

  Acknowledgments

     Portions of this document were drafted with assistance from AI
     language models including Claude (Anthropic), ChatGPT (OpenAI), and
     Gemini (Google).  The author reviewed, validated, and takes full
     responsibility for all technical content, design decisions, and
     claims herein, including any errors or omissions.

     The author thanks the AI safety research community for discussions
     on threat models and governance mechanisms that informed this work.

  Author's Address

     Edward Richard Aylward Jr.
     Email: aylward.edward@gmail.com
     URI:   https://orcid.org/0000-0003-0313-6993




  Aylward                   Expires 1 May 2026                   [Page 20]


name: draft-li-semantic-routing-architecture
rev: 00
title: Semantic Routing Architecture for AI Agents Communication
time: 2025-11-04T06:53:17Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-08T06:53:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:12.944700+00:00
abstract:
  This document introduces an Semantic Routing (SR) Architecture for
     enabling intelligent, semantic-driven communication among AI Agents.
     Unlike traditional IP-based routing or service mesh approaches, SRA
     leverages application-layer semantics — including service identity,
     intent vectors, and trust scores — to guide routing decisions
     dynamically.  The architecture supports intent-driven task
     collaboration, trust-aware policy enforcement, and adaptive routing
     for multi-agent environments.  SRA enables the network to evolve from
     a passive transport layer to an intelligent collaboration substrate
     supporting multi-agent coordination and cognitive networking.

full_text:
  Working Group                                                      X. Li
  Internet-Draft                                                   A. Wang
  Intended status: Standards Track                           China Telecom
  Expires: 8 May 2026                                      4 November 2025


         Semantic Routing Architecture for AI Agents Communication
                 draft-li-semantic-routing-architecture-00

  Abstract

     This document introduces an Semantic Routing (SR) Architecture for
     enabling intelligent, semantic-driven communication among AI Agents.
     Unlike traditional IP-based routing or service mesh approaches, SRA
     leverages application-layer semantics — including service identity,
     intent vectors, and trust scores — to guide routing decisions
     dynamically.  The architecture supports intent-driven task
     collaboration, trust-aware policy enforcement, and adaptive routing
     for multi-agent environments.  SRA enables the network to evolve from
     a passive transport layer to an intelligent collaboration substrate
     supporting multi-agent coordination and cognitive networking.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 8 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



  Li & Wang                  Expires 8 May 2026                   [Page 1]


  Internet-Draft               SR Architecture               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.  Conventions used in this document . . . . . . . . . . . . . .   4
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
     5.  Functional Layers and Design Principles . . . . . . . . . . .   6
     6.  Control and Forwarding Procedures . . . . . . . . . . . . . .   7
     7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     The emergence of AI-driven ecosystems has transformed communication
     paradigms across computing and networking infrastructures.
     Traditional routing systems, designed for host-to-host communication,
     focus on connectivity, reachability, and link-state optimization.
     However, in environments where AI agents [AIAgent]—autonomous
     entities with reasoning and goal-oriented behavior—interact
     dynamically, such topological routing no longer meets the operational
     needs.  Each agent represents not only a computational endpoint but
     also a semantic actor that generates intents, expresses capabilities,
     and negotiates tasks.  The network must therefore evolve from a
     static forwarding fabric into a semantic coordination plane capable
     of interpreting meaning, context, and trust.

     Existing frameworks such as Service Mesh [ServiceMesh] (e.g., Istio
     [Istio], Linkerd) and Software-Defined Networking (SDN) have improved
     visibility and control but remain largely syntactic.  They route
     requests based on service names, APIs, or labels, not on why the
     communication occurs or what semantic goal it represents.  For
     example, in an AI multi-agent system performing distributed
     reasoning, the decision of which node to contact depends on task
     semantics—such as “model adaptation,” “policy refinement,” or “data
     summarization”—and on dynamic factors like capability, latency, and
     trustworthiness.  None of these can be expressed using IP addresses
     or conventional service identifiers.






  Li & Wang                  Expires 8 May 2026                   [Page 2]


  Internet-Draft               SR Architecture               November 2025


     The Semantic Routing (SR) architecture introduced in this draft aims
     to bridge this semantic gap.  It extends routing intelligence from
     the network layer to the application layer, enabling communication
     decisions based on intent vectors, policy interpretation, and trust
     evaluation.  Through a semantic control plane, SRA aligns network
     behavior with business and computational objectives, providing
     adaptive, secure, and efficient routing among AI agents.  This
     enables networks to support intent-aware task collaboration and to
     act as intelligent participants in distributed cognition processes.

     SRA also addresses emerging challenges of large-scale agent
     communication, including semantic interoperability, cross-domain
     trust, and self-optimization.  Modern AI ecosystems consist of
     heterogeneous nodes—cloud agents, edge assistants, embedded inference
     units—that collaborate under uncertain conditions.  Routing must thus
     adapt to fluctuating workloads, mobility, and trust contexts.  Static
     or location-based approaches cannot efficiently manage such dynamism.
     By integrating semantic interpretation with continuous telemetry
     feedback, SRA allows networks to self-optimize: routes are
     recalculated not only based on network states (e.g., congestion or
     delay) but also on semantic relevance and agent reliability.

     The design of SRA is guided by several fundamental objectives:

     *  Semantic Awareness – Networks should understand and act upon high-
        level intents derived from AI tasks.

     *  Trust Integration – Routing should consider the reliability and
        historical behavior of agents.

     *  Dynamic Adaptation – Telemetry-driven feedback loops must
        continuously refine routing decisions.

     *  Backward Compatibility – SAR should coexist with IP, BGP, and
        service-mesh infrastructures.

     *  Distributed Autonomy – Each semantic router should make local
        decisions while aligning with global intent policies.

     By embedding intelligence into the control and forwarding planes, SRA
     transforms the Internet from a data transport medium into a
     collaborative semantic ecosystem that supports intelligent
     communication for the next generation of distributed AI systems.








  Li & Wang                  Expires 8 May 2026                   [Page 3]


  Internet-Draft               SR Architecture               November 2025


  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 this draft:

     *  SRA (Semantic Routing Architecture): The routing framework defined
        in this document integrating semantic awareness, trust, and policy
        control.

     *  AI Agent: An autonomous software entity capable of making context-
        based decisions, performing actions, and communicating with other
        agents.

     *  Intent Vector: A structured representation of the communication
        goal, expressed semantically (e.g., task type, priority, resource
        needs).

     *  Semantic Router (SR): Entity interpreting intent metadata and
        enforcing semantic forwarding policies.

     *  Semantic Forwarding Table (SFT): Forwarding table mapping intent
        categories to next hops and constraints.

  4.  Architecture Overview

     The Semantic Router (SR) architecture introduces a layered design
     that bridges application semantics and network operation.  It defines
     a semantic control framework capable of understanding agent-generated
     intents, evaluating contextual trust, and translating these into
     actionable routing policies.  At its core, SRA consists of four
     interacting planes—Application, Control, Data, and Feedback—each
     responsible for distinct yet interdependent functions.














  Li & Wang                  Expires 8 May 2026                   [Page 4]


  Internet-Draft               SR Architecture               November 2025


     The Application Plane hosts AI agents that issue Intent Vectors (IVs)
     representing goals such as “request model inference” or “synchronize
     state.” The Semantic Control Plane collects these intents,
     authenticates identities, and maps them to routing policies via the
     Policy Engine (PE).  These policies are then propagated to Semantic
     Routers (SRs) in the Data Plane, which execute the forwarding logic
     using Semantic Forwarding Tables (SFTs) that link intent types to
     paths and constraints.  Finally, the Feedback Plane, driven by
     Telemetry Agents (TAs), monitors latency, trust, and service quality,
     feeding the results back into the control plane for continuous
     optimization.

     This closed-loop system ensures that SAR continuously aligns network
     operation with evolving task goals.  The architecture is designed to
     integrate seamlessly with existing IP and SDN environments, relying
     on overlays or extended routing attributes (e.g., BGP communities or
     SRv6 tags) to express semantic metadata.


































  Li & Wang                  Expires 8 May 2026                   [Page 5]


  Internet-Draft               SR Architecture               November 2025


                +-------------------------------------------+
                |          Application Plane                |
                |-------------------------------------------|
                |     +-----------+     +-----------+       |
                |     |  Agent A  |<--->|  Agent B  |       |
                |     +-----------+     +-----------+       |
                |         ^                   ^             |
                |         | Intent Vector     |Intent Vector|
                +---------|-------------------|-------------+
                          |                   |
                          v                   v
                +-------------------------------------------+
                |           Control Plane                   |
                |-------------------------------------------|
                |  +--------------+   +------------------+  |
                |  | Intent Ctrl  |<->|   Policy Engine  |  |
                |  +--------------+   +------------------+  |
                |         ^                  ^              |
                |         |                  |              |
                |         v                  v              |
                |    +-----------+     +-----------+        |
                |    | Trust Mgr |<--->|Telemetry A.|       |
                |    +-----------+     +-----------+        |
                +----------------|--------------------------+
                                 |
                                 v
                +-------------------------------------------+
                |             Data Plane                    |
                |-------------------------------------------|
                |  +------------+   +------------+          |
                |  | Sem.Router |<->| Sem.Router |          |
                |  +------------+   +------------+          |
                |      ^   |             ^   |              |
                |      |   | Telemetry   |   |              |
                |      +---|-------------+---+              |
                +-------------------------------------------+
                 Figure 1 The overall architecture for SAR

  5.  Functional Layers and Design Principles

     SAR’s design is organized into five functional layers, each aligned
     with a core principle that ensures scalability, intelligence, and
     interoperability.

     *  Intent Layer: Generates and encodes Intent Vectors.  Agents
        describe their goals in structured form, including task types,
        urgency, and context.  The network uses these to infer optimal
        paths and collaborators.



  Li & Wang                  Expires 8 May 2026                   [Page 6]


  Internet-Draft               SR Architecture               November 2025


     *  Identity and Trust Layer: Manages authentication, authorization,
        and reputation.  Each agent is bound to a unique identity
        certificate, and trust scores are computed from telemetry.

     *  Policy Layer: The Policy Engine maps intents and trust data into
        enforceable rules, determining which paths, nodes, or bandwidth
        allocations are permitted.

     *  Semantic Routing Layer: Semantic Routers interpret policy rules
        and update SFT entries dynamically based on trust or performance
        metrics.

     *  Feedback Layer: Collects telemetry (e.g., latency, success rate,
        anomaly detection) and continuously refines both trust and
        policies.

     SAR adheres to the following design principles:

     *  Semantic Composability: Each intent can be decomposed and
        recombined, enabling fine-grained routing for multi-step agent
        workflows.

     *  Trust Anchoring: Decisions are always contextualized by dynamic
        trust values, preventing compromised agents from influencing
        routing unfairly.

     *  Closed-Loop Adaptation: Every policy or path update is verified
        through telemetry feedback, ensuring stable yet flexible routing
        evolution.

     *  Interoperability: SAR MAY extend BGP, IS-IS, or gRPC metadata to
        distribute semantic and trust information while maintaining
        backward compatibility.


  6.  Control and Forwarding Procedures

     SAR operates through coordinated procedures that integrate semantic
     interpretation, trust evaluation, and routing execution.  These
     processes are logically divided between the control plane and
     forwarding plane, yet are interconnected via telemetry and feedback.

     1.  Agent Registration: When an agent joins the network, it
         authenticates with the Intent Controller (IC) and registers its
         capabilities (e.g., compute type, model domain).  The IC issues
         credentials and a unique semantic prefix for the agent.





  Li & Wang                  Expires 8 May 2026                   [Page 7]


  Internet-Draft               SR Architecture               November 2025


     2.  Intent Submission: The agent generates an Intent Vector and
         submits it to the IC.  The Policy Engine (PE) parses the intent,
         referencing domain policies to determine allowed routing
         strategies.

     3.  Policy Translation: Based on the agent’s trust score and system
         objectives, the PE compiles an executable rule set for the
         Semantic Router (SR).  These rules specify target domains,
         quality preferences, and security constraints.

     4.  Routing Execution: SR uses its Semantic Forwarding Table (SFT) to
         determine next hops.  Forwarding is influenced by trust, latency,
         and semantic relevance rather than just IP reachability.

     5.  Telemetry Feedback: The Telemetry Agent (TA) reports performance
         data back to the Trust Manager (TM).  Trust scores are
         recalculated periodically, triggering policy adjustments when
         thresholds are exceeded.

































  Li & Wang                  Expires 8 May 2026                   [Page 8]


  Internet-Draft               SR Architecture               November 2025


      +-----------+        +------------------+       +------------------+
      |   Agent   |        |  Intent Controller|      |   Policy Engine  |
      +-----------+        +------------------+       +------------------+
            |                         |                          |
            | 1. Register/Authenticate|                          |
            +------------------------>|                          |
            |                         |                          |
            | 2. Submit Intent Vector |                          |
            +------------------------>|                          |
            |                        | 3. Validate & Parse Intent|
            |                        +-------------------------->|
            |                        |                           |
            |                        | 4. Generate Routing Policy|
            |                        |<--------------------------+
            |                        |                           |
            |                        | 5. Install to Router      |
            |                        +-------------------------->|
            |                        |                           |
            |                        | 6. Ack/Confirm            |
            |<------------------------+                          |
            |                        |                           |
            | 7. Data Forwarding via Semantic Routers            |
            |--------------------------------------------------->|
            |                        |                           |
            | 8. Telemetry Feedback  |<--------------------------+
            |<---------------------------------------------------|
            |                        |                           |
            | 9. Trust Update & Policy Adjustment                |
            +----------------------------------------------------+
                  Figure 2 The Workflow Overview for SAR

  7.  Conclusion

     The SRA (Semantic Routing architecture) redefines how intelligent
     systems communicate by integrating semantic intent, trust evaluation,
     and adaptive policy control directly into the routing process.  It
     extends the traditional Internet model beyond topology and content
     toward a truly intent-driven communication fabric that aligns network
     behavior with the goals of autonomous AI agents.  Through its layered
     design—including intent processing, trust management, semantic
     routing, and telemetry-driven feedback—SAR provides a coherent
     framework capable of supporting large-scale, cross-domain AI
     ecosystems with dynamic, secure, and efficient coordination.

     Looking forward, several research and standardization opportunities
     remain.  First, common intent representation languages must be
     defined to ensure interoperability among heterogeneous agents and
     vendors.  Second, mechanisms for distributed trust computation



  Li & Wang                  Expires 8 May 2026                   [Page 9]


  Internet-Draft               SR Architecture               November 2025


     require standard metrics and synchronization protocols across
     administrative domains.  Third, integration of SAR with existing
     Internet routing protocols such as BGP, IS-IS, or SRv6 will need
     careful consideration to balance scalability with semantic
     expressiveness.  Finally, future work should investigate AI-assisted
     optimization within the SAR control plane, enabling predictive policy
     adjustments based on contextual learning.

     In conclusion, SAR offers a foundational step toward an autonomous,
     cognition-aware Internet, where the network itself participates in
     decision-making, ensuring that communication among AI agents becomes
     purposeful, trustworthy, and adaptive.

  8.  IANA Considerations

     TBD

  9.  Acknowledgement

     TBD

  10.  Normative References

     [AIAgent]  N, D., "Framework for AI Agent Networks draft-zyyhl-agent-
                networks-framework-01", 2017.

     [Istio]    L, Larsson., "Impact of etcd deployment on kubernetes,
                istio, and application performance", 2020.

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

     [ServiceMesh]
                Li, W., "Service mesh: Challenges, state of the art, and
                future research opportunities", 2019.

  Authors' Addresses

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




  Li & Wang                  Expires 8 May 2026                  [Page 10]


  Internet-Draft               SR Architecture               November 2025


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












































  Li & Wang                  Expires 8 May 2026                  [Page 11]


name: draft-wendt-stir-vesper
rev: 06
title: VESPER - Framework for VErifiable STI Personas
time: 2025-11-04T16:51:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-08T16:51:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864792+00:00
abstract:
  This document formalizes a profile and a framework for the use of
     delegate certificates and authority tokens to strengthen the
     association between telephone number assignments and the entities
     that have the authoritative right to use them on the telephone
     network.  It defines a model in which the TNAuthList Authority Token
     serves as a trusted representation of telephone number assignment and
     right-to-use (RTU), anchored by a Notary Agent that logs these
     associations through verifiable transparency mechanisms.  The
     framework also extends the use of authority tokens to support other
     PASSporT claims like Rich Call Data (RCD) by defining a role for
     JWTClaimConstraints Authority Tokens.  These tokens are issued by
     authoritative or recognized and vetted claim agents within the
     ecosystem to assert information associated with the entity assigned a
     telephone number.  The Notary Agent plays a critical role in
     recording these claims and their provenance, enhancing transparency
     and accountability.  Delegate certificates encapsulate and
     incorporate both the telephone number and associated information
     validated via authority tokens to the certification authority issuing
     them, binding them to the authenticated telephone number of the
     calling party.  These certificates are published to a certificate
     transparency log, enabling relying parties to independently verify
     the integrity and legitimacy of number use and related claims.  The
     VESPER (Verifiable STI PERsona) approach utilizes STIR protocols and
     the ACME authority token to formalizing a verifiable, auditable, and
     privacy-conscious foundation for associating telephone numbers with
     identifiable entities and assertion of associated metadata.

full_text:
  Secure Telephone Identity Revisited                             C. Wendt
  Internet-Draft                                                  R. Śliwa
  Intended status: Standards Track                             Somos, Inc.
  Expires: 8 May 2026                                      4 November 2025


               VESPER - Framework for VErifiable STI Personas
                         draft-wendt-stir-vesper-06

  Abstract

     This document formalizes a profile and a framework for the use of
     delegate certificates and authority tokens to strengthen the
     association between telephone number assignments and the entities
     that have the authoritative right to use them on the telephone
     network.  It defines a model in which the TNAuthList Authority Token
     serves as a trusted representation of telephone number assignment and
     right-to-use (RTU), anchored by a Notary Agent that logs these
     associations through verifiable transparency mechanisms.  The
     framework also extends the use of authority tokens to support other
     PASSporT claims like Rich Call Data (RCD) by defining a role for
     JWTClaimConstraints Authority Tokens.  These tokens are issued by
     authoritative or recognized and vetted claim agents within the
     ecosystem to assert information associated with the entity assigned a
     telephone number.  The Notary Agent plays a critical role in
     recording these claims and their provenance, enhancing transparency
     and accountability.  Delegate certificates encapsulate and
     incorporate both the telephone number and associated information
     validated via authority tokens to the certification authority issuing
     them, binding them to the authenticated telephone number of the
     calling party.  These certificates are published to a certificate
     transparency log, enabling relying parties to independently verify
     the integrity and legitimacy of number use and related claims.  The
     VESPER (Verifiable STI PERsona) approach utilizes STIR protocols and
     the ACME authority token to formalizing a verifiable, auditable, and
     privacy-conscious foundation for associating telephone numbers with
     identifiable entities and assertion of associated metadata.

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




  Wendt & Śliwa              Expires 8 May 2026                   [Page 1]


  Internet-Draft                   VESPER                    November 2025


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

     This Internet-Draft will expire on 8 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
     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 . . . . . . . . . . . . . . . . .   4
     3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Vesper Architectural Overview . . . . . . . . . . . . . . . .   6
       4.1.  The VESPER Framework Architecture . . . . . . . . . . . .   6
       4.2.  Roles and Responsibilities in the VESPER Framework  . . .   7
         4.2.1.  Entity  . . . . . . . . . . . . . . . . . . . . . . .   7
         4.2.2.  Responsible Provider or Responsible Organization  . .   8
         4.2.3.  Claim Agent Responsibilities  . . . . . . . . . . . .   8
         4.2.4.  Juridictional Number Administrator
                 Responsibilities  . . . . . . . . . . . . . . . . . .   9
       4.3.  Claim Agents and Claim Information Privacy  . . . . . . .   9
         4.3.1.  Public vs. Private Disclosure . . . . . . . . . . . .   9
       4.4.  Delegate Certificate Issuance Process . . . . . . . . . .  10
       4.5.  VESPER Certificate Profile (Short-Lived & Inline
             Conveyance) . . . . . . . . . . . . . . . . . . . . . . .  12
       4.6.  Use of VESPER Delegate Certificates for Signing
             Communications  . . . . . . . . . . . . . . . . . . . . .  12
       4.7.  VESPER Authentication and Verification Procedures . . . .  13
         4.7.1.  Authentication Service Behavior . . . . . . . . . . .  13
         4.7.2.  Verification Service Behavior . . . . . . . . . . . .  14
         4.7.3.  Connected Identity Authentication and Verification  .  14
     5.  PASSporT Claim: "vper" (Verifiable Persona Entity
             Representation) . . . . . . . . . . . . . . . . . . . . .  16
       5.1.  Claim Format  . . . . . . . . . . . . . . . . . . . . . .  16



  Wendt & Śliwa              Expires 8 May 2026                   [Page 2]


  Internet-Draft                   VESPER                    November 2025


     6.  JWTClaimConstraints for Transparent Claims  . . . . . . . . .  17
       6.1.  Goals and Non-Goals . . . . . . . . . . . . . . . . . . .  17
       6.2.  Addressing Claims in PASSporTs  . . . . . . . . . . . . .  18
       6.3.  Constraint Encodings (Three Privacy Modes)  . . . . . . .  18
         6.3.1.  Transparenct-Value Constraint . . . . . . . . . . . .  18
         6.3.2.  Semi-Private Constraint (Unsalted Hash) . . . . . . .  18
         6.3.3.  Private Constraint (Salted Commitment with Selective
                 Disclosure) . . . . . . . . . . . . . . . . . . . . .  19
       6.4.  Certificate and Transparency Log Requirements . . . . . .  20
       6.5.  Authority Token Requirements  . . . . . . . . . . . . . .  20
       6.6.  Verification by a Relying Party (VS)  . . . . . . . . . .  20
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  21
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  21
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  Introduction

     The Secure Telephone Identity (STI) architecture, based on STI
     certificates [RFC8226], PASSporTs [RFC8225], and the SIP Identity
     header field [RFC8224], define the foundational use of digital
     signatures and tokens to protect the integrity of calling
     information, particularly the telephone number, during a
     communications session.  While these mechanisms help validate call
     signaling, they do not directly establish the entity who is
     authorized to use a given telephone number.  This document provides a
     profile of the STI architecture by formalizing the use of delegate
     certificates and authority tokens to more clearly and verifiably
     associate a telephone number with the entity responsible for its use.
     This stronger linkage is especially important as misuse (i.e., the
     illegimate spoofing and impersonation) tied to telephone numbers by
     unauthorized parties continues to undermine trust in communications
     networks.

     To address this, the VESPER framework introduces roles and
     interactions that mirror proven practices from other trust-based
     industries, such as Know Your Customer (KYC) and Know Your Business
     (KYB) procedures well established in the financial industry.  Through
     a defined process and as an adjunct to the authoritative telephone
     number assignment process involving Responsible Providers or
     Organizations and the jurisdictional Numbering Administrator, an
     Entity is issued a TNAuthList Authority Token defined in [RFC9448],
     establishing their right to use a telephone number.  Beyond
     establishing the authority of the telephone number, optionally
     additional information an entity may like to assert to a called
     party, such as Rich Call Data (RCD) [RFC9795], can be asserted and
     authorized using JWTClaimConstraints Authority Tokens



  Wendt & Śliwa              Expires 8 May 2026                   [Page 3]


  Internet-Draft                   VESPER                    November 2025


     [I-D.wendt-acme-authority-token-jwtclaimcon].  JWTClaimContraints
     have the interesting property that they can be used to assert either
     direct values or the integrity hashes of values (e.g., using "rcdi"
     claims defined in [RFC9795]) to enhance the ability to protect the
     privacy of information when desired or required.  These Authority
     Tokens are used in challenges toward the issuance of delegate
     certificates which can be transparently recorded in a transparency
     log, which can act as a set of neutral eco-system registrar points
     for representing asserted claims associated with telephone numbers
     with or without exposing underlying data as explicitly authorized or
     desired.  Transparent declarations of claim assertions have the
     potential beneficial property of enhancing the trust of the asserted
     claims based on monitoring of these claims to avoid fraudulent
     impersonation that the STI framework is intended to solve.

     In addition to supporting call authentication of the originating
     party, the VESPER framework can also extend to the validation of the
     called party through the use of connected identity as defined in
     [I-D.ietf-stir-rfc4916-update].  In this model, the same authority
     token and delegate certificate mechanisms that bind an originating
     telephone number to a vetted entity can be applied in the reverse
     direction, enabling a called party to assert its validated identity
     via signed PASSporTs included in SIP responses.  This optional
     capability broadens the scope of accountability and transparency to
     both ends of the communication session while maintaining the privacy-
     conscious design principles of VESPER.

     This VESPER trust model and profile is enhanced using eco-system wide
     accountability.  Transparency logs formalize and announce the
     issuance of certificates and the relationship between telephone
     numbers, associated claims and their rightful users, helping detect
     and prevent fraudulent or conflicting claims by interested parties
     and auditing mechanisms.  By shifting from implicit trust in digital
     signatures alone to an explicit framework of vetted identities and
     transparent claims, this approach builds a foundation for enhanced
     verifiable communications.  It enables the responsible use of
     telephone numbers and auditability, discourages impersonation, and
     strengthens enforcement against abuse, ultimately fostering greater
     confidence in telephone number-based communications.

  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.




  Wendt & Śliwa              Expires 8 May 2026                   [Page 4]


  Internet-Draft                   VESPER                    November 2025


  3.  Overview

     This document defines a framework for the authoritative association
     of telephone numbers to the entities responsible for their use, using
     delegate certificates and authority tokens for issuance and
     certificate transparency for eco-system auditing.  Within this
     framework, referred to as VESPER (VErifiable STI PERsonas), entities
     are represented through verifiable claims that establish their right
     to use a telephone number and, optionally, their asserted claim
     attributes such as Rich Call Data (RCD) or other claims defined via
     PASSporT claim and type specifications.  These claims are issued by
     trusted responsible parties and are anchored through transparency
     mechanisms to support trust, auditability, and privacy as
     appropriate.

     The core premise is that a telephone number, when used as a
     communications identifier, must be explicitly bound to the real-world
     party authorized to use it.  While telephone numbers have long served
     as identifiers in global communications, the absence of a strong
     binding between a number and a responsible party has allowed for
     abuse, most notably through number spoofing and impersonation fraud.
     In many cases, bad actors exploit the lack of accountability to
     mislead call recipients, avoid traceability, or impersonate
     legitimate businesses and individuals.  To address this, the VESPER
     framework introduces a standardized method for expressing and
     publishing the right-to-use (RTU) of a telephone number through the
     issuance of a TNAuthList Authority Token from a centralized
     jurisdictional Number Administrator.  This token is issued following
     the assignment or delegation of a number.  The issuance of the
     delegate certificate is recorded in a transparency log providing
     relying parties an eco-system wide verification of the association
     between a number and its authorized entity, authorized by the
     regulated Responsible Provider or Organization that is authorized to
     assign numbers via jurisdictional regulatory policies over telephone
     numbers.

     Beyond the association of telephone numbers, JWTClaimConstraints
     [RFC8226] and EnhancedJWTClaimConstraints [RFC9118] play a critical
     role in delegate certificates issued under the VESPER framework.
     They provide a standardized mechanism for Certification Authorities
     to explicitly constrain any additional claims a delegate certificate
     holder is permitted to assert in communications.  This constraint
     mechanism ensures that even if a certificate is misused or presented
     outside its intended scope, the relying party can verify whether the
     claims presented are authorized by the issuer.  Certification
     Authorities derive these constraints from Authority Tokens issued by
     vetted Claim Agents, which serve as cryptographic proof of the claim
     validations.  By limiting the scope of claims to those proven and



  Wendt & Śliwa              Expires 8 May 2026                   [Page 5]


  Internet-Draft                   VESPER                    November 2025


     approved during the certificate issuance process, using
     JWTClaimConstraints Authority Tokens provided by trusted Claim Agents
     that take responsibility for vetting those additional claims makes
     VESPER extensible just as PASSporT claims are intended to do to
     protect both the telephone number and other assertions made through
     PASSporTs.

     Unlike prior models that rely on implicit trust in the caller or the
     STI signer, this approach provides an explicit, auditable, and
     standards-based path to associate communications with a known and
     authorized party.  The VESPER framework does not define how vetting
     (e.g., KYC/KYB) is performed, nor does it prescribe specific policy
     requirements for what the relying party should do with this
     information.  Instead, it focuses on standardizing how vetted results
     and right-to-use associations are asserted, recorded, and presented
     within the STIR ecosystem focused on the telephone number first and
     additional claims and assertions second.

     By reinforcing the accountability of number usage and enabling the
     trusted presentation of related identity claims, this architecture
     enhances integrity, supports privacy, and enables enforcement
     mechanisms to deter misuse or mis-issuance issues.

     VESPER implementations MUST support short-lived delegate certificates
     and SHOULD use "x5c" to convey certificates inline.  Transparency
     logging remains required.

  4.  Vesper Architectural Overview

  4.1.  The VESPER Framework Architecture

     The VESPER framework establishes a structured framework for asserting
     and verifying the association between a telephone number and the
     entity authorized to use it.  This model supports a broad range of
     communications use cases, from fully attributed business
     communications with rich identity information to privacy-conscious
     person scenarios that require only verification that the number is in
     legitimate use by a real validated entity.

     At its core, the model is built on a trust structure with the
     following key roles:

     1.  Entities (e.g., individuals or organizations) seeking to assert
         their right to use a telephone number and assert claims about
         themselves or a set of communications,






  Wendt & Śliwa              Expires 8 May 2026                   [Page 6]


  Internet-Draft                   VESPER                    November 2025


     2.  Responsible providers and organizations that are authorized to
         allocate and assign numbers within a jurisdictional numbering
         plan,

     3.  Claim Agents that are authorized and recognized for validating
         and issuing claims about those entities, and

     4.  A Numbering Administrator (NA), both jurisdictional to a country
         code and neutral to the eco-system, that represents authoritative
         policies for number uses within that jurisdiction and facilitates
         a minimum tie of telephone numbers to entity identifiers and
         ensures transparency, traceability, and auditability within the
         ecosystem.

     Participation in the VESPER framework requires a shared set of
     policies governing how entities are vetted and how claims are created
     and validated.  These policies define the requirements for asserting
     an entity's identity, the right to use a telephone number, and
     optionally and where applicable, additional claims and associated
     attributes (i.e. PASSporT type defined claims, like Rich Call Data).
     Claims beyond the telephone number are structured representations of
     verified information, issued by authorized or accepted Claim Agents.
     Each claim type is standardized via PASSporT type specifications
     [RFC8225] in the STIR working group, with clearly defined required
     and optional key-value pairs, ensuring interoperability and
     consistency across the ecosystem.  Through this model, VESPER
     provides a scalable and transparent foundation for building trust in
     telephone-based communications, with the flexibility to support both
     fully attributed and privacy-respecting use cases.

  4.2.  Roles and Responsibilities in the VESPER Framework

     The VESPER trust framework defines a set of roles that work together
     to assert and validate claims about telephone numbers and the
     entities authorized to use them.  At the core of this ecosystem are
     two primary roles: Entities and Claim Agents.  Entities are
     individuals or organizations that wish to establish their authority
     to use a telephone number and, optionally, present additional vetted
     identity attributes.  Claim Agents are responsible for validating
     this information and issuing standardized, structured claims.

  4.2.1.  Entity

     An Entity is the individual or organization seeking to assert its
     authority to use a specific telephone number and, optionally, to
     present additional vetted claims such as business name or purpose.
     The Entity is the central actor around which the claims and trust
     relationships are formed.



  Wendt & Śliwa              Expires 8 May 2026                   [Page 7]


  Internet-Draft                   VESPER                    November 2025


  4.2.2.  Responsible Provider or Responsible Organization

     A Responsible Provider, sometimes called a Telephone Number Service
     Provider (TNSP), or Responsible Organization (RespOrg) plays both
     their traditional well-defined role in the allocation and assignment
     of telephone numbers in accordance with national or international
     numbering plans generally followed internationally via e.164 and
     e.164.1 but also a foundational role in the VESPER ecosystem by
     validation of the association of telephone number assignments to
     Entities.  These entities operate under regulatory authority and are
     responsible for administering number resources associated with a
     specific country code or region.

     Their responsibilities include:

     *  Number Assignment: Allocating telephone numbers to Entities under
        the rules of an authorized numbering plan.

     *  Entity Association: Establishing and maintaining a record that
        links each assigned telephone number to a specific, uniquely
        identified entity.  This includes assigning a persistent
        identifier or account reference to the Entity to which a number is
        assigned providing an opaque identifier.  This identifier can be
        used by the Entity to reference themselves in an opaque way for
        accessing assignment relevant information including TNAuthList
        Authority Tokens or also referenced during any disputes or
        disclosures when necessary.

     The Responsible Provider or Organization follows the numbering
     assignment process but additionally authorizes an TNAuthList
     Authority Token to be used by a Certification Authority in the
     issuance of a delegate certificate that minimally includes a
     TNAuthList extension that corresponds ot the telephone number.

  4.2.3.  Claim Agent Responsibilities

     Claim Agents are trusted parties in the ecosystem responsible for
     validating information about Entities and issuing authoritative or
     verified claims.  These claims cover claims associated with PASSporT
     defined claims including identity details or Rich Call Data (RCD).

     Claim Agents provide JWTClaimConstraints Authority Tokens to validate
     inclusion of these constrainted claim assertions to the issuance of
     delegate certificates to the valid Entities.  Once a Claim Agent
     performs its vetting process, it issues signed JWTClaimConstraints
     Authority Tokens containing the validated claim information or
     integrity hashes for those claims for the Entity depending on privacy
     preferences.



  Wendt & Śliwa              Expires 8 May 2026                   [Page 8]


  Internet-Draft                   VESPER                    November 2025


  4.2.4.  Juridictional Number Administrator Responsibilities

     The Number Administrator (NA) serves as the ecosystem's neutral
     registrar and transparency authority.  It performs three critical
     functions:

     1.  Registration of Responsible Providers and Responsible
         Organizations that correspond to the traditional roles in
         accordance with a national or international numbering plans.

     2.  Registration of Claim Agents, ensuring each is uniquely
         identifiable and authorized to issue specific types of claims.

     3.  Coordination of eco-system Transparency Logs, which issues
         cryptographic receipts to confirm and timestamp the existence of
         each claim.

     While this document does not define a dispute resolution process, any
     conflicts or misclaims discovered through transparency should be
     escalated through a neutral ecosystem-specific mechanisms, likely
     coordinated by the NA role in communication with relevant Responsible
     Providers or Organizations or Claim Agents.

  4.3.  Claim Agents and Claim Information Privacy

     Privacy is a foundational principle of the VESPER framework.  Claim
     Agents are not required to expose or publish sensitive data about
     Entities when recording claims.  Instead, claims can be privacy-
     protected by logging only the cryptographic hashes of the claim
     content in the transparency log, preserving proof without revealing
     the underlying details.

  4.3.1.  Public vs. Private Disclosure

     For claim information that is public by nature, such as business
     names, logos, or other potential claim assertions relevent to
     identifying the calling party, Claim Agents may choose to constrain
     the direct values of the claims to log the data in full within
     certificates for public visibility.  This public transparency helps
     the ecosystem identify conflicting or fraudulent claims and
     reinforces trust through open scrutiny.










  Wendt & Śliwa              Expires 8 May 2026                   [Page 9]


  Internet-Draft                   VESPER                    November 2025


     Conversely, for private or sensitive claims (e.g., internal
     identifiers or personally identifiable information), Claim Agents may
     choose to log only a hash of the data or not at all.  This approach
     ensures that the claim's authenticity can still be verified without
     compromising the Entity's privacy, if and when required.  Disclosure
     of such claims remains at the discretion of the Entity or may occur
     in limited cases where legal or regulatory obligations apply.

  4.4.  Delegate Certificate Issuance Process

     In the VESPER framework, the issuance of a delegate certificate to an
     Entity involves the multiple roles defined and referenced in this
     document, including the Responsible Provider or Responsible
     Organization, Claim Agents and a trusted Certification Authority (CA)
     operating under the STIR eco-system certificate policy governing STIR
     certificates defined in [RFC8226].

     The process begins when a Responsible Provider or Responsible
     Organization assigns a telephone number to an Entity.  As part of
     that assignment, the Entity is formally associated with the number as
     is typical in a Number Administration assignment system, but
     additionally via an associated opaque and unique identifier.  This
     could be globally unique identifier or a public-key that is provably
     associated to the entity and establishes an auditable relationship
     between the number and the right-to-use holder.  The opaque unique
     identifier helps to uphold the privacy of the eco-system as part of
     normal telephone number allocation and assignment has traditionally
     followed but allows for non-repudiation throughout the ecosystem.
     Thus, when potential policy violations occur, the Entity identifier
     provides an indisputable path to the corresponding Responsible
     Providers and Organizations and to the Entities assigned the
     telephone number via the delegated certificate in question.

     Additionally, following this association, a TNAuthList Authority
     Token can be issued to the Entity.  This token authoritatively
     represents the Entity's Right-To-Use the telephone number and can
     serve as cryptographic proof of assignment to an authorized CA that
     requires that proof to issue a delegate certificate.













  Wendt & Śliwa              Expires 8 May 2026                  [Page 10]


  Internet-Draft                   VESPER                    November 2025


     In parallel, a Claim Agent may be used to validate additional
     attributes that the Entity wishes to assert when originating calls,
     such as Rich Call Data (RCD).  These validated attributes are encoded
     in a JWTClaimConstraints Authority Token, which governs what claims
     the Entity is authorized to present in communications.  The Claim
     Agent may also use the TNAuthList Authority Token as proof of
     assignment and the Right-to-Use the telephone numbers being asserted
     by the Entity.  This should also be utilized to govern the constraint
     of the "orig" claim to only the valid associated numbers to the
     Entity.

     Once both tokens have been obtained, the Entity initiates a
     Certificate Signing Request (CSR) to their preferred CA authorized to
     issue certificates within the STIR ecosystem.  As per the mechanisms
     outlined in [RFC9447], [RFC9448], and
     [I-D.wendt-acme-authority-token-jwtclaimcon], the TNAuthList and
     JWTClaimConstraints tokens are presented as ACME challenge responses
     to prove the Entity's authority over the number and its validated
     claims.

     Upon successful validation of the Authority Tokens required, the CA
     issues a delegate certificate to the Entity.

     CAs SHOULD issue short-lived certificates with brief validity
     intervals.  Entities SHOULD automate renewal to avoid service
     interruptions.

     This certificate MUST include:

     *  A TNAuthList extension [RFC8226], representing the telephone
        number(s) the certificate holder is authorized to use.

     This certificate, if additional claims and assertions are made beyond
     the base PASSporT claims defined in [RFC8225], MUST include:

     *  A JWTClaimConstraints extension [RFC8226] and/or
        EnhancedJWTClaimConstraints extension [RFC9118], representing the
        constraints on claims the certificate holder is permitted to
        assert.

     The issued certificate is then submitted to a certificate
     transparency log.  A corresponding transparency receipt is returned
     to the Entity and/or CA to provide verifiable proof of publication.








  Wendt & Śliwa              Expires 8 May 2026                  [Page 11]


  Internet-Draft                   VESPER                    November 2025


  4.5.  VESPER Certificate Profile (Short-Lived & Inline Conveyance)

     VESPER delegate certificates MUST support the short-lived certificate
     profile in [I-D.ietf-stir-certificates-shortlived].  PASSporTs MUST
     include the certificate chain using the "x5c" header.  Verification
     Services SHOULD prefer "x5c" over "x5u" if included, and MUST NOT
     dereference "x5u" if "x5c" is present and valid.  Short-lived
     certificates reduce the need for revocation infrastructure and
     eliminate external certificate fetches.

  4.6.  Use of VESPER Delegate Certificates for Signing Communications

     Once an Entity has received a delegate certificate containing
     validated right-to-use and claim constraints, it can use this
     certificate to sign communications associated with the authorized
     telephone number.

     For example, as defined in [RFC8224] when the Entity initiates a SIP
     call, it generates a PASSporT object containing session-specific
     details such as "orig", "dest", and "iat".  The Entity then signs the
     PASSporT using its delegate certificate, which binds both the
     telephone number and any authorized claims (e.g., RCD elements) to
     the communication.

     Critically, the JWTClaimConstraints extension in the certificate
     enforces the set of claims the Entity is permitted to assert in the
     PASSporT, ensuring that claims cannot exceed those vetted and
     authorized by the corresponding Claim Agent.

     As defined in [RFC8224], the signed PASSporT is then attached to the
     SIP Identity header and transmitted with the call.  The Verification
     Service (VS) on the receiving side performs STIR verification,
     checking:

     *  That the PASSporT signature is valid.

     *  That the delegate certificate is trusted, unexpired, and issued by
        a recognized CA.

     *  If the PASSporT includes an "x5c" header, the certificate chain
        must be validated from the inline header; "x5u" must not be
        dereferenced.

     *  If "x5c" is absent, "x5u" MAY be used to retrieve the certificate
        chain.

     *  That the certificate includes a valid TNAuthList extension for the
        telephone number in use in the "orig" claim.



  Wendt & Śliwa              Expires 8 May 2026                  [Page 12]


  Internet-Draft                   VESPER                    November 2025


     *  That any asserted claims conform to the JWTClaimConstraints and/or
        EnhancedJWTClaimConstraints in the certificate.

     *  That a corresponding transparency receipt exists, proving the
        certificate was publicly recorded.

     Senders SHOULD include "x5c"; relying parties SHOULD prefer "x5c"
     when both are available.

     If all verifications succeed, the relying party can trust that the
     call is both authorized and attributable, and that all claims have
     been validated by responsible participants in the ecosystem.

  4.7.  VESPER Authentication and Verification Procedures

     This section outlines the expected behavior of Authentication
     Services (AS) and Verification Services (VS) in deployments utilizing
     VESPER delegate certificates.  These procedures extend the baseline
     STIR authentication and verification models defined in [RFC8224],
     [RFC8225], and [RFC8226] by incorporating validation of transparency-
     backed delegate certificates and associated claims.

  4.7.1.  Authentication Service Behavior

     When originating a call, the Authentication Service performs the
     following steps:

     *  Constructs a PASSporT for the session containing the required
        claims (e.g., orig, dest, iat), as well as any optional authorized
        claims (e.g., Rich Call Data).

     *  Signs the PASSporT using a VESPER delegate certificate that:

        -  Contains a valid TNAuthList extension authorizing the orig
           telephone number.

        -  Optionally includes JWTClaimConstraints or
           EnhancedJWTClaimConstraints extensions consistent with the
           asserted claims.

        -  Is backed by a Signed Certificate Timestamp (SCT) from a
           transparency log.

     *  Attaches the signed PASSporT in a SIP Identity header using the
        "x5c" header parameter to convey the certificate chain inline.

     *  Ensures that the certificate is valid, unexpired, and issued by a
        CA compliant with the VESPER certificate issuance profile.



  Wendt & Śliwa              Expires 8 May 2026                  [Page 13]


  Internet-Draft                   VESPER                    November 2025


  4.7.2.  Verification Service Behavior

     Upon receiving a SIP request containing an Identity header, the
     Verification Service:

     *  Validates the PASSporT signature and parses the included claims.

     *  Validates the VESPER delegate certificate by checking:

        -  Trust chain validity and issuer compliance with STI and VESPER
           certificate policies.

        -  The presence and accuracy of the TNAuthList extension
           corresponding to the orig telephone number.

        -  The presence and SCT validation of the certificate's
           transparency log inclusion.

        -  Any JWTClaimConstraints [RFC8226] and
           EnhancedJWTClaimConstraints [RFC9118] extensions, ensuring
           claimed values conform to constraints.

     *  Rejects the PASSporT if any of the above validations fail.

     This delineation ensures that only calls with properly issued and
     verifiable delegate certificates are authenticated and accepted under
     the VESPER framework, reinforcing accountability and integrity within
     the STIR ecosystem.

  4.7.3.  Connected Identity Authentication and Verification

     A similar verification process applies when VESPER is used in
     deployments that support Connected Identity as defined in
     [I-D.ietf-stir-rfc4916-update].  In this model, the destination party
     may return a PASSporT of type 'rsp' within a SIP response, signed
     using a delegate certificate authorized for the 'dest' telephone
     number in the original call.

  4.7.3.1.  Authentication by the Destination Party

     When acting as an Authentication Service, the destination party
     performs the following steps to generate and sign the 'rsp' PASSporT:

     Constructs a PASSporT of type 'rsp' including:

     *  The original 'orig' and 'dest' values from the incoming call.

     *  The 'iat' claim representing the issuance time.



  Wendt & Śliwa              Expires 8 May 2026                  [Page 14]


  Internet-Draft                   VESPER                    November 2025


     *  Optionally, include other claims to convey attributes of entity
        including "vper", if appropriate.

     Sign the PASSporT using a valid VESPER delegate certificate
     containing a TNAuthList extension authorizing use of the 'dest'
     telephone number (i.e., the destination party's number).

     Include the "x5c" header in the PASSporT, conveying the certificate
     chain used for signing.

     Ensure the certificate is valid, unexpired, includes a valid SCT, and
     that the certificate corresponds to the 'dest' claim.

     Attach the signed PASSporT to a SIP 200 OK response using the
     Identity header as described in [I-D.ietf-stir-rfc4916-update].

  4.7.3.2.  Verification by the Originating Party

     To verify the 'rsp' PASSporT, the originating party (or an upstream
     Verification Service acting on its behalf) MUST perform the following
     checks:

     *  The 'rsp' PASSporT MUST be signed using a valid VESPER delegate
        certificate with a TNAuthList value matching the 'dest' number.

     *  The certificate MUST:

        -  Be issued by a Certification Authority compliant with [RFC8226]
           and the VESPER profile;

        -  Include a valid SCT and be within its validity period.

     *  The PASSporT signature MUST be validated using the provided 'x5c'
        header.

     *  The 'orig' and 'dest' claims MUST match those of the original
        PASSporT that initiated the call.

     *  The 'iat' claim MUST be within an acceptable freshness interval.

     *  The Verification Service SHOULD validate the certificate's
        inclusion in a transparency log using the SCT.









  Wendt & Śliwa              Expires 8 May 2026                  [Page 15]


  Internet-Draft                   VESPER                    November 2025


     These procedures confirm that the destination party has authenticated
     and cryptographically asserted its identity using a VESPER delegate
     certificate, extending mutual identity validation to the terminating
     side of the call.  This process supports bi-directional trust,
     enhances accountability, and enables privacy-aware identity
     assertion.

  5.  PASSporT Claim: "vper" (Verifiable Persona Entity Representation)

     This section defines a new PASSporT claim, "vper" (Verifiable Persona
     Entity Representation), intended to encapsulate structured,
     extensible metadata about an entity authorized to use a telephone
     number.  The "vper" claim enables verifiable, privacy-conscious
     assertion of real-world entity attributes bound to a delegate
     certificate and associated number via the VESPER framework.

  5.1.  Claim Format

     The "vper" claim is a JSON object containing the following REQUIRED
     fields:

     "vper": {
       "id": "string",              // Globally unique NA identifier
       "glue": ["string", ...],     // Array of GLUE URNs
       "name": "string",            // Registered legal business name
       "domain": "string"           // Domain associated with the entity
     }

     Field Definitions

     *  id (REQUIRED): A globally unique identifier for the entity
        associated via Number Assignment process.  This MAY be a UUID, a
        public key thumbprint, or another opaque identifier that supports
        global uniqueness and non-repudiation.  The identifier serves as a
        persistent reference to the entity across authority tokens and
        certificates.

     *  glue (REQUIRED): An array of GLUE URNs defined in
        [I-D.ietf-spice-glue-id] that bind the entity to one or more
        standardized, jurisdiction-specific or globally recognized
        business identifiers (e.g., DUNS number, EIN, LEI, VAT ID).  These
        enable interoperability across business registries and aid in
        regulatory traceability.

     *  name (REQUIRED): A string containing the legal business name as
        registered with the relevant jurisdictional authority or business
        registry.  This MUST match the name associated with the provided
        GLUE identifiers.



  Wendt & Śliwa              Expires 8 May 2026                  [Page 16]


  Internet-Draft                   VESPER                    November 2025


     *  domain (REQUIRED): A string representing the canonical domain name
        associated with the business, typically used for its public
        website and/or authorized communication addresses (e.g., email).
        This value MUST be DNS-resolvable and under the administrative
        control of the asserting entity.

     The "vper" claim may be used in full or in hashed form to support
     privacy-conscious deployments, as guided by the next section.

     Extensibility

     The "vper" claim is designed to be extensible.  Future specifications
     may define optional fields for additional structured entity metadata.
     Such extensions MUST be registered via the IANA PASSporT claim
     registry under this base claim or defined via new claim types.

  6.  JWTClaimConstraints for Transparent Claims

     This section defines how VESPER uses JWTClaimConstraints [RFC8226]
     and EnhancedJWTClaimConstraints [RFC9118] to announce claims through
     the certificate that is submitted to a transparency log, while
     preserving privacy when desired or required.  In this model, a Claim
     Agent validates an Entity's desired claims and issues a
     JWTClaimConstraints Authority Token
     [I-D.wendt-acme-authority-token-jwtclaimcon] to a Certification
     Authority (CA).  The CA includes a corresponding constraints
     extension in the delegate certificate, and that certificate is logged
     for ecosystem transparency.  Three privacy modes are supported:

     1.  Transparent-Value — the constraint fixes the exact value to be
         asserted (fully transparent).

     2.  Semi-Private (Unsalted Hash) — the constraint fixes a hash of the
         value (guessable by an observer who can test likely values).

     3.  Private (Salted Commitment) — the constraint fixes a salted hash
         commitment; verification requires out-of-band salt disclosure
         from the Entity to an explicitly authorized relying party (RP).

  6.1.  Goals and Non-Goals

     *  Binding: Relying parties MUST be able to verify that a presented
        claim value is one authorized by the certificate.

     *  Transparency: Observers MUST be able to audit which claims are
        authorized for a number, without necessarily learning the private
        values.




  Wendt & Śliwa              Expires 8 May 2026                  [Page 17]


  Internet-Draft                   VESPER                    November 2025


     *  Transparent Privacy Choice: Entities and Claim Agents MUST be able
        to choose per-claim whether values are public, semi-private, or
        private.

     *  Simplicity: All modes use widely deployed primitives (SHA-2) and
        reuse deterministic serialization similar to RCD integrity
        [RFC9795] mechanism.

     This section does not redefine the syntax of the JWTClaimConstraints/
     EnhancedJWTClaimConstraints extensions; it profiles their content to
     carry clear values or integrity artifacts for values.

  6.2.  Addressing Claims in PASSporTs

     When Claims appear in PASSporTs, constraints refer to claims by claim
     name and, for structured claims, by JSON Pointer (RFC 6901) into the
     claim value.

     However, even if the PASSporT does not include an explicit claim as
     part of the signed object in the context of a call or message, an
     important property of the transparency in the VESPER framework is if
     the relying party wants to validate claims made as part of
     transparency validation outside of PASSporT verification, it can look
     at the JWTClaimsConstraints objects to validate claims.

  6.3.  Constraint Encodings (Three Privacy Modes)

     For each constrained claim (or claim path), the JWTClaimConstraints
     Authority Token and the certificate extension MUST carry exactly one
     of the following encodings.

  6.3.1.  Transparenct-Value Constraint

     The claim value is directly constrainted to be the value in open
     text.

     Verification: The VS compares the presented PASSporT claim value
     (after deterministic serialization if structured) for equality with
     value.

  6.3.2.  Semi-Private Constraint (Unsalted Hash)

     Intended use: Values where limited hiding is acceptable,
     understanding that guessing is possible (e.g., logo URL or short
     labels).

     Semantics: The certificate fixes a digest D over the canonicalized
     value without a salt.



  Wendt & Śliwa              Expires 8 May 2026                  [Page 18]


  Internet-Draft                   VESPER                    November 2025


     Computation:

     V_bytes = deterministic_serialize(V) D = SHA-256(V_bytes)

     Verification: The VS computes D' over the received value and accepts
     if D' == digest.

     Privacy: An observer who can guess candidate values can compute
     digests and test them.  Use only when this risk is acceptable or
     values have sufficient entropy.  This mirrors the integrity mechanism
     in [RFC9795].

  6.3.3.  Private Constraint (Salted Commitment with Selective Disclosure)

     Intended use: Sensitive values (e.g., opaque IDs, PII) where the
     Entity wants verifiability only for explicitly authorized RPs.

     Semantics: The certificate fixes a commitment C that incorporates a
     secret, per-claim salt S.  Only C (and optionally a hash of S) is
     published.  The Entity may later disclose S (and, if needed, V)
     out-of-band to an RP of its choosing for verification.

     Data Items

     V: value to be proven (octets after deterministic serialization).  S:
     secret random salt (≥ 128 bits from a CSPRNG).  H: a
     collision-resistant hash (MUST support SHA-256).

     Computation:

     V_bytes = deterministic_serialize(V) C = H( S || V_bytes ) (optional)
     S_hash = H(S)

     Publication: The certificate and transparency log include only commit
     (and optional salt_hash).  S and V are not published.

     Salt Disclosure: The Entity MAY disclose S (and, if required, V) to
     an authorized RP via an authenticated, confidential channel (e.g., a
     compact JWE encrypted to the RP's public key).  Disclosure is per-RP
     and per event at the Entity's discretion.

     Verification by RP: 1.  Obtain (V, S) from the Entity.  2.  Compute
     C' = H( S || deterministic_serialize(V) ).  3.  Accept if and only if
     C' == commit (and, if salt_hash present, H(S) == salt_hash).







  Wendt & Śliwa              Expires 8 May 2026                  [Page 19]


  Internet-Draft                   VESPER                    November 2025


  6.4.  Certificate and Transparency Log Requirements

     The CA MUST copy the constraints from the JWTClaimConstraints
     Authority Token into the certificate's JWTClaimConstraints/
     EnhancedJWTClaimConstraints extension without widening them.

     The issued certificate MUST be submitted to a transparency log; the
     log therefore reveals: * the existence of each constrained claim/
     path, and * for each, either the clear value, an unsalted hash, or a
     salted commitment (but never the salt). * For mode commit,
     implementations MUST NOT include the salt in the certificate or log.

  6.5.  Authority Token Requirements

     A JWTClaimConstraints Authority Token MUST:

     *  identify the Claim Agent and the Entity,

     *  enumerate the constrained claims/paths and, for each, one of the
        three encodings above,

     *  specify the hash algorithm where applicable ("alg": "sha-256"
        RECOMMENDED),

     *  be time-bounded and bound to the TN(s) (e.g., via TNAuthList)
        authorized for the Entity.

     The CA MUST verify the token per
     [I-D.wendt-acme-authority-token-jwtclaimcon] and issue a certificate
     that does not exceed the token's scope.

  6.6.  Verification by a Relying Party (VS)

     When verifying a PASSporT:

     *  For value mode: ensure the presented claim equals the constrained
        value.

     *  For hash mode: recompute the digest over the presented claim and
        compare.

     *  For commit mode: if the RP has received S (and V if needed)
        out-of-band, recompute and compare the commitment.  If S is not
        available, the RP MUST treat the constraint as "authorized but not
        presently verifiable" and apply local policy (e.g., defer
        validation, request disclosure, or treat as unauthenticated
        attribute).




  Wendt & Śliwa              Expires 8 May 2026                  [Page 20]


  Internet-Draft                   VESPER                    November 2025


  7.  Security Considerations

     TBD

  8.  IANA Considerations

     New PASSporT Claim: "vper"

     This document requests that the IANA add a new entry to the "PASSporT
     Claims" registry as follows:

                 +============+==================+===========+
                 | Claim Name | Claim Value Type | Reference |
                 +============+==================+===========+
                 | vper       | JSON object      | RFCthis   |
                 +------------+------------------+-----------+

                    Table 1: PASSporT Claims registry entry
                                   for "vper

  9.  Acknowledgments

     The authors would like to acknowledge Jon Peterson for valuable
     feedback into the concepts and framework for this document.  This
     work is mainly based on the many years of inputs and specifications
     developed in the STIR working group and the larger telephone industry
     which the authors acknowledge as a critically important feedback and
     influence toward the development of the VESPER framework.

  10.  Normative References

     [I-D.ietf-spice-glue-id]
                Zundel, B., Dingle, P., and M. B. Jones, "GLobal Unique
                Enterprise (GLUE) Identifiers", Work in Progress,
                Internet-Draft, draft-ietf-spice-glue-id-02, 20 October
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                spice-glue-id-02>.

     [I-D.ietf-stir-certificates-shortlived]
                Peterson, J., "Short-Lived Certificates for Secure
                Telephone Identity", Work in Progress, Internet-Draft,
                draft-ietf-stir-certificates-shortlived-03, 6 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-stir-
                certificates-shortlived-03>.

     [I-D.ietf-stir-rfc4916-update]
                Peterson, J. and C. Wendt, "Connected Identity for STIR",
                Work in Progress, Internet-Draft, draft-ietf-stir-rfc4916-



  Wendt & Śliwa              Expires 8 May 2026                  [Page 21]


  Internet-Draft                   VESPER                    November 2025


                update-07, 7 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-stir-
                rfc4916-update-07>.

     [I-D.wendt-acme-authority-token-jwtclaimcon]
                Wendt, C. and D. Hancock, "JWTClaimConstraints profile of
                ACME Authority Token", Work in Progress, Internet-Draft,
                draft-wendt-acme-authority-token-jwtclaimcon-03, 7 July
                2025, <https://datatracker.ietf.org/doc/html/draft-wendt-
                acme-authority-token-jwtclaimcon-03>.

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

     [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
                "Authenticated Identity Management in the Session
                Initiation Protocol (SIP)", RFC 8224,
                DOI 10.17487/RFC8224, February 2018,
                <https://www.rfc-editor.org/rfc/rfc8224>.

     [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
                Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
                <https://www.rfc-editor.org/rfc/rfc8225>.

     [RFC8226]  Peterson, J. and S. Turner, "Secure Telephone Identity
                Credentials: Certificates", RFC 8226,
                DOI 10.17487/RFC8226, February 2018,
                <https://www.rfc-editor.org/rfc/rfc8226>.

     [RFC9118]  Housley, R., "Enhanced JSON Web Token (JWT) Claim
                Constraints for Secure Telephone Identity Revisited (STIR)
                Certificates", RFC 9118, DOI 10.17487/RFC9118, August
                2021, <https://www.rfc-editor.org/rfc/rfc9118>.

     [RFC9447]  Peterson, J., Barnes, M., Hancock, D., and C. Wendt,
                "Automated Certificate Management Environment (ACME)
                Challenges Using an Authority Token", RFC 9447,
                DOI 10.17487/RFC9447, September 2023,
                <https://www.rfc-editor.org/rfc/rfc9447>.






  Wendt & Śliwa              Expires 8 May 2026                  [Page 22]


  Internet-Draft                   VESPER                    November 2025


     [RFC9448]  Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
                "TNAuthList Profile of Automated Certificate Management
                Environment (ACME) Authority Token", RFC 9448,
                DOI 10.17487/RFC9448, September 2023,
                <https://www.rfc-editor.org/rfc/rfc9448>.

     [RFC9795]  Wendt, C. and J. Peterson, "Personal Assertion Token
                (PASSporT) Extension for Rich Call Data", RFC 9795,
                DOI 10.17487/RFC9795, July 2025,
                <https://www.rfc-editor.org/rfc/rfc9795>.

  Authors' Addresses

     Chris Wendt
     Somos, Inc.
     United States of America
     Email: chris@appliedbits.com


     Rob Śliwa
     Somos, Inc.
     United States of America
     Email: robjsliwa@gmail.com




























  Wendt & Śliwa              Expires 8 May 2026                  [Page 23]


name: draft-jurkovikj-collab-tunnel
rev: 01
title: The Collaboration Tunnel Protocol (TCT)
time: 2025-11-14T09:01:32Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-18T09:01:32Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:06.864795+00:00
abstract:
  This document specifies the Collaboration Tunnel Protocol, an HTTP-
     based method for efficient, verifiable delivery of web content to
     automated agents.  The protocol uses bidirectional URL discovery,
     template-invariant content fingerprinting with strong ETags, sitemap-
     first verification, and strict conditional request discipline to
     reduce bandwidth while preserving canonical URLs.

full_text:
  Network Working Group                                       A. Jurkovikj
  Internet-Draft                                          14 November 2025
  Intended status: Experimental                                           
  Expires: 18 May 2026


                  The Collaboration Tunnel Protocol (TCT)
                      draft-jurkovikj-collab-tunnel-01

  Abstract

     This document specifies the Collaboration Tunnel Protocol, an HTTP-
     based method for efficient, verifiable delivery of web content to
     automated agents.  The protocol uses bidirectional URL discovery,
     template-invariant content fingerprinting with strong ETags, sitemap-
     first verification, and strict conditional request discipline to
     reduce bandwidth while preserving canonical URLs.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 18 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
     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.



  Jurkovikj                  Expires 18 May 2026                  [Page 1]


  Internet-Draft                     TCT                     November 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
         1.1.1.  Problem Statement . . . . . . . . . . . . . . . . . .   5
         1.1.2.  Goals and Non-Goals . . . . . . . . . . . . . . . . .   5
       1.2.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   6
       1.3.  Design Rationale and Relation to Existing Mechanisms  . .   7
         1.3.1.  Related Work  . . . . . . . . . . . . . . . . . . . .   7
         1.3.2.  TCT Design Choices  . . . . . . . . . . . . . . . . .   8
       1.4.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   8
         1.4.1.  M-Sitemap Discovery . . . . . . . . . . . . . . . . .   8
         1.4.2.  M-URL Discovery and Canonical Links . . . . . . . . .  10
         1.4.3.  Template-Invariance . . . . . . . . . . . . . . . . .  10
       1.5.  M-URL Representation  . . . . . . . . . . . . . . . . . .  11
         1.5.1.  Content-Type and Encoding . . . . . . . . . . . . . .  11
         1.5.2.  Required JSON Fields  . . . . . . . . . . . . . . . .  11
         1.5.3.  Representation Stability  . . . . . . . . . . . . . .  12
       1.6.  Deterministic JSON and Strong ETags . . . . . . . . . . .  12
         1.6.1.  Deterministic JSON Serialization  . . . . . . . . . .  13
         1.6.2.  Strong ETag Generation (Single Method)  . . . . . . .  13
         1.6.3.  Relationship to Template-Invariance . . . . . . . . .  14
         1.6.4.  Canonical Text Normalization (Optional for
                 Producers)  . . . . . . . . . . . . . . . . . . . . .  14
       1.7.  M-Sitemap Format and Semantics  . . . . . . . . . . . . .  16
         1.7.1.  M-Sitemap JSON Structure  . . . . . . . . . . . . . .  16
         1.7.2.  HTTP Response for M-Sitemap . . . . . . . . . . . . .  17
         1.7.3.  Parity Semantics  . . . . . . . . . . . . . . . . . .  17
       1.8.  Client Behavior . . . . . . . . . . . . . . . . . . . . .  18
         1.8.1.  Zero-Fetch Optimization . . . . . . . . . . . . . . .  18
         1.8.2.  Conditional Requests to M-URLs  . . . . . . . . . . .  19
         1.8.3.  Use of HEAD (Optional)  . . . . . . . . . . . . . . .  19
         1.8.4.  Client Validation (Optional)  . . . . . . . . . . . .  19
       1.9.  Operational Considerations (Informative)  . . . . . . . .  20
         1.9.1.  Deployment with CDNs and Proxies  . . . . . . . . . .  20
         1.9.2.  Large Sites and Sharding  . . . . . . . . . . . . . .  20
         1.9.3.  Error Handling  . . . . . . . . . . . . . . . . . . .  20
         1.9.4.  Backwards Compatibility . . . . . . . . . . . . . . .  21
       1.10. Security Considerations . . . . . . . . . . . . . . . . .  21
       1.11. IANA Considerations . . . . . . . . . . . . . . . . . . .  22
     2.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
       2.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
       2.2.  Informative References  . . . . . . . . . . . . . . . . .  23
     Appendix A.  Appendix A.  Normalization Test Vectors  . . . . . .  24
       A.1.  A.1.  Basic ASCII . . . . . . . . . . . . . . . . . . . .  24
         A.1.1.  A.2.  HTML Entities . . . . . . . . . . . . . . . . .  24
         A.1.2.  A.3.  Unicode Normalization (NFKC)  . . . . . . . . .  25
         A.1.3.  A.4.  Case Folding Edge Cases . . . . . . . . . . . .  25



  Jurkovikj                  Expires 18 May 2026                  [Page 2]


  Internet-Draft                     TCT                     November 2025


         A.1.4.  A.5.  Control Characters  . . . . . . . . . . . . . .  26
         A.1.5.  A.6.  Whitespace Edge Cases . . . . . . . . . . . . .  26
         A.1.6.  A.7.  Empty and Edge Cases  . . . . . . . . . . . . .  26
         A.1.7.  A.8.  Complex Real-World Examples . . . . . . . . . .  27
         A.1.8.  A.9.  Implementation Notes  . . . . . . . . . . . . .  27
       A.2.  Appendix B.  Example Flows (Informative)  . . . . . . . .  27
         A.2.1.  B.1.  Initial Discovery and First Fetch . . . . . . .  27
         A.2.2.  B.2.  Zero-Fetch Optimization (Content Unchanged) . .  28
         A.2.3.  B.3.  Conditional Request (Content Unchanged) . . . .  29
         A.2.4.  B.4.  Content Changed . . . . . . . . . . . . . . . .  30
         A.2.5.  B.5.  Parity Mismatch Handling  . . . . . . . . . . .  30
         A.2.6.  B.6.  Using HEAD for Efficient Freshness Check  . . .  31
         A.2.7.  B.7.  Discovery via C-URL . . . . . . . . . . . . . .  32
       A.3.  Appendix C.  Implementation Notes (Informative) . . . . .  32
         A.3.1.  C.1.  Reference Implementations . . . . . . . . . . .  32
         A.3.2.  C.2.  Deterministic JSON Libraries  . . . . . . . . .  33
         A.3.3.  C.3.  SHA-256 Computation . . . . . . . . . . . . . .  34
     Appendix B.  Canonical JSON . . . . . . . . . . . . . . . . . . .  34
     Appendix C.  Hash . . . . . . . . . . . . . . . . . . . . . . . .  34
       C.1.  C.4.  Unicode Normalization . . . . . . . . . . . . . . .  35
     Appendix D.  NFKC normalization . . . . . . . . . . . . . . . . .  35
     Appendix E.  Case folding . . . . . . . . . . . . . . . . . . . .  35
       E.1.  C.5.  HTTP Response Headers . . . . . . . . . . . . . . .  35
     Appendix F.  Response if unchanged  . . . . . . . . . . . . . . .  36
     Appendix G.  Response if changed  . . . . . . . . . . . . . . . .  36
       G.1.  C.6.  Production Deployment Data  . . . . . . . . . . . .  36
         G.1.1.  C.7.  Common Implementation Pitfalls  . . . . . . . .  36
         G.1.2.  C.8.  Testing and Validation  . . . . . . . . . . . .  37
         G.1.3.  C.9.  Performance Considerations  . . . . . . . . . .  37
         G.1.4.  C.10.  Security Best Practices  . . . . . . . . . . .  38
     Appendix H.  Acknowledgments  . . . . . . . . . . . . . . . . . .  38
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  38

  1.  Introduction

     Automated agents (search engines, AI crawlers, archives, monitoring
     tools, aggregators) increasingly consume web content at scale.
     Fetching and parsing full HTML pages for machine consumption is often
     inefficient:

     *  Page weight is dominated by templates, navigation, ads, and
        scripts.

     *  Machine consumers typically need a stable textual representation
        of the core content.

     *  Many pages do not change frequently, but are re-fetched in full.




  Jurkovikj                  Expires 18 May 2026                  [Page 3]


  Internet-Draft                     TCT                     November 2025


     Various sites already expose JSON APIs or feeds, but:

     *  formats differ across sites, and

     *  use of HTTP validators is inconsistent.

     The Collaboration Tunnel Protocol (TCT) defines a simple,
     interoperable profile on top of HTTP that:

     *  exposes a canonical JSON representation (M-URL) for selected
        resources;

     *  advertises C-URL/M-URL mappings and validators in a JSON sitemap
        (M-Sitemap);

     *  uses a single, well-defined strong ETag method for M-URLs; and

     *  enables "zero-fetch" behavior when content is unchanged.

     TCT is intentionally conservative: it uses only existing HTTP
     mechanisms, is backward compatible with the Web, and does not define
     policy or licensing semantics.

  1.1.  Terminology

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

     *  C-URL:

        -  The canonical, human-facing URL of a resource, typically an
           HTML document.

     *  M-URL:

        -  The machine-facing URL providing the TCT JSON representation of
           that resource.

     *  M-Sitemap:

        -  The JSON sitemap enumerating C-URL/M-URL pairs and associated
           validators.

     *  Representation:




  Jurkovikj                  Expires 18 May 2026                  [Page 4]


  Internet-Draft                     TCT                     November 2025


        -  As defined in [RFC9110]: the information in a payload,
           including representation metadata, that is subject to content
           negotiation.

     Unless stated otherwise, "client" refers to an automated agent that
     is aware of TCT.

  1.1.1.  Problem Statement

     Key inefficiencies in current automated consumption of web content
     include:

     *  repeated transfer of large HTML documents whose core content has
        not changed;

     *  lack of a standard, compact, semantics-focused representation for
        page-like resources;

     *  ad hoc usage or absence of validators (ETag, Last-Modified),
        hindering efficient revalidation;

     *  difficulty for agents to reason about change detection at scale
        using only HTML and XML sitemaps.

  1.1.2.  Goals and Non-Goals

     TCT is designed to:

     *  reuse HTTP semantics ([RFC9110], [RFC9111]) rather than introduce
        new ones;

     *  provide a simple, deterministic JSON representation appropriate
        for:

        -  search indexing,

        -  content analysis,

        -  retrieval-augmented generation (RAG),

        -  archival and monitoring;

     *  define discovery and validation clearly enough for interoperable
        clients and servers.

     TCT explicitly does NOT:





  Jurkovikj                  Expires 18 May 2026                  [Page 5]


  Internet-Draft                     TCT                     November 2025


     *  define how content may or may not be used (policy, licensing, AI
        usage);

     *  change the semantics of resources at C-URLs;

     *  require new HTTP methods or status codes.

  1.2.  Architecture

     TCT introduces three main elements per participating origin:

     *  C-URL:

        -  The canonical resource URL for humans, often serving HTML.

     *  M-URL:

        -  A URL providing a canonical JSON representation of the same
           logical resource (TCT JSON).

     *  M-Sitemap:

        -  A JSON document listing C-URLs, M-URLs, and strong validators
           (etag values).

     High-level flow (informative):

     1.  Client performs GET / at https://example.com/.

     2.  The origin root response includes:

         *  Link: </llm-pages.json>; rel="index"; type="application/json".

     3.  Client fetches /llm-pages.json (M-Sitemap).

     4.  For each item:

         *  learns (cUrl, mUrl, etag).

     5.  Client fetches mUrl as needed:

         *  GET mUrl, with If-None-Match on subsequent checks.

     6.  Server responds with:

         *  200 OK + JSON when changed;

         *  304 Not Modified when unchanged.



  Jurkovikj                  Expires 18 May 2026                  [Page 6]


  Internet-Draft                     TCT                     November 2025


     TCT is additive and optional:

     *  Non-TCT clients ignore TCT artifacts.

     *  Servers can deploy TCT gradually alongside existing content and
        sitemaps.

  1.3.  Design Rationale and Relation to Existing Mechanisms

     TCT is grounded in existing mechanisms and complements several
     related efforts:

  1.3.1.  Related Work

     *XML Sitemaps:* - Widely deployed for URL discovery (search engines,
     crawlers). - Provide <lastmod> timestamps but do not define normative
     bindings between sitemap entries and HTTP validators (ETags) for
     endpoint representations. - TCT builds on this model by adding
     structured JSON representations and strong validator integration.

     *ResourceSync:* - Developed by the Open Archives Initiative and
     collaborators for resource synchronization in digital libraries. -
     Provides resource lists, change lists, and capability documents. -
     Focus is synchronization and preservation; does not define a single,
     tightly integrated pattern combining: - per-resource JSON
     representation, - sitemap listing with validators, and - ETag-based
     zero-fetch semantics. - TCT addresses the specific use case of
     efficient web content delivery to automated agents.

     *AMP (Accelerated Mobile Pages):* - Defines an HTML subset optimized
     for fast rendering on mobile devices. - Provides alternate
     representations via <link rel="amphtml">. - TCT provides JSON (not
     HTML) for machine consumption, targeting crawlers and content
     analysis rather than human browsing.

     *Custom JSON APIs:* - Many sites expose custom JSON endpoints for
     content access. - Structures, field names, and validator usage vary
     widely across implementations. - TCT aims to standardize a minimal,
     interoperable profile suitable for broad adoption.

     *robots.txt:* - Defines crawl directives and access policies. - TCT
     does not replace robots.txt; publishers MAY use both mechanisms: -
     robots.txt for crawl permissions and rate guidance, and - TCT for
     efficient content delivery.







  Jurkovikj                  Expires 18 May 2026                  [Page 7]


  Internet-Draft                     TCT                     November 2025


     *RSS/Atom Feeds:* - Provide syndication of updates and content
     excerpts. - Typically lack HTTP caching integration (per-item ETags,
     conditional requests). - TCT can be viewed as "RSS with disciplined
     HTTP caching semantics."

  1.3.2.  TCT Design Choices

     Key design choices in TCT:

     *  Use only existing HTTP semantics:

        -  GET, HEAD, 200, 304, ETag, Cache-Control, Link.

     *  Use JSON as the machine representation:

        -  Simple, widely supported, easy to parse.

        -  TCT is complementary to existing HTTP content-coding and
           dictionary-based compression mechanisms: it reduces
           representation size and refetch frequency at the application
           layer while remaining fully compatible with compression applied
           to M-URL responses.

     *  Define one strong ETag method:

        -  Based on canonical JSON bytes of the M-URL payload.

        -  Avoid ambiguous or dual hash methods.

     *  Keep policy and energy considerations out of the core:

        -  Those can be specified separately as informational work.

     The intent is to offer an interoperable profile that is:

     *  easy to implement,

     *  friendly to existing caches/CDNs, and

     *  precise enough for standardization.

  1.4.  Discovery

  1.4.1.  M-Sitemap Discovery

     A publisher implementing TCT MUST expose an M-Sitemap and advertise
     it from the origin root resource.




  Jurkovikj                  Expires 18 May 2026                  [Page 8]


  Internet-Draft                     TCT                     November 2025


     When a client performs:

     *  GET / with Host: example.com

     and receives a successful (2xx) response (either directly or after
     following redirects per [RFC9110]), that response:

     *  MUST include a Link header with:

        -  rel="index"

        -  type="application/json"

        -  a target that is the M-Sitemap URL for this origin.

     Example:

     *  Link: </llm-sitemap.json>; rel="index"; type="application/json"

     In this specification, a Link header field with rel="index",
     type="application/json", and a target whose content matches Section 7
     identifies the TCT M-Sitemap for that origin.  Other uses of
     rel="index" remain valid and are outside the scope of this document.

     Notes:

     *  /llm-sitemap.json is an example; any stable path MAY be used.

     *  If / redirects (e.g., 301 or 302 to /en/ or /index.html), the Link
        header MUST appear on the final redirect target.

     *  Clients:

        -  SHOULD follow redirects per [RFC9110] before checking for TCT
           support.

        -  MUST discover the M-Sitemap via the Link header on the final
           response.

        -  If no such Link is present, SHOULD assume TCT is not deployed
           and MUST NOT guess paths.

     *  If multiple Link headers with rel="index" and type="application/
        json" are present, clients MAY choose any or load all.  This
        document does not define multi-sitemap selection semantics; large-
        site sharding is left to operational conventions (see
        Section 9.2).




  Jurkovikj                  Expires 18 May 2026                  [Page 9]


  Internet-Draft                     TCT                     November 2025


     This specification does not define or require any /.well-known/ URI.

  1.4.2.  M-URL Discovery and Canonical Links

     For each resource where an M-URL is provided:

     *  The C-URL response (typically HTML) SHOULD advertise the M-URL as
        an alternate JSON representation:

        Either via HTML:

        -  <link rel="alternate" type="application/json"
           href="https://example.com/post/llm.json">

        Or HTTP:

        -  Link: <https://example.com/post/llm.json>; rel="alternate";
           type="application/json"

     *  The M-URL response for that resource MUST include a corresponding
        canonical link ([RFC6596]):

        -  Link: <https://example.com/post/>; rel="canonical"

     *Note on M-URL paths:* The choice of M-URL path (e.g., /post/
     llm.json, /post/llm/, /post.json, etc.) is not specified by this
     document.  Publishers MAY choose any stable URL scheme that suits
     their architecture.  Clients MUST discover M-URLs via advertised
     links (as shown above) and MUST NOT assume a fixed path pattern.

     Examples of valid M-URL patterns: - https://example.com/post/llm.json
     (used in this document) - https://example.com/post/llm/ (directory-
     style) - https://example.com/post.json (extension-based)

     This bidirectional linkage allows clients to:

     *  verify that an M-URL is an alternate for the expected C-URL;

     *  detect misconfigurations when links are inconsistent; and

     *  ensure the canonical_url field in the M-URL JSON matches (or is
        consistent with) the URL advertised via rel="canonical" for the
        corresponding C-URL.

  1.4.3.  Template-Invariance

     TCT's template-invariance property:




  Jurkovikj                  Expires 18 May 2026                 [Page 10]


  Internet-Draft                     TCT                     November 2025


     *  Changes to HTML templates, CSS, or JavaScript at the C-URL SHOULD
        NOT require changes to the M-URL JSON, so long as the underlying
        resource content has not changed.

     This is achieved by:

     *  treating M-URLs as distinct, canonical JSON representations of
        content; and

     *  computing strong ETags over the M-URL JSON only.

     Template-invariance is NOT achieved by relaxing strong ETag
     semantics; for any given M-URL, identical strong ETags MUST imply
     byte-identical JSON bodies.

  1.5.  M-URL Representation

     An M-URL is an HTTP resource that serves a JSON representation of a
     content resource suitable for machine consumption.

     This specification defines the observable JSON representation at
     M-URLs; it does not constrain how servers derive these
     representations from their internal data models, templates, or
     storage.

  1.5.1.  Content-Type and Encoding

     M-URL responses:

     *  MUST use:

        -  Content-Type: application/json; charset=utf-8

     *  MUST be valid JSON as per [RFC8259].

     *  MUST use UTF-8 without BOM.

  1.5.2.  Required JSON Fields

     The minimal M-URL JSON object for a resource MUST contain:

     *  canonical_url (string, REQUIRED)

        -  The canonical human-facing URL (C-URL).

     *  title (string, REQUIRED)

        -  A human-readable title for the resource.



  Jurkovikj                  Expires 18 May 2026                 [Page 11]


  Internet-Draft                     TCT                     November 2025


     *  content (string, REQUIRED)

        -  Core textual content:

           o  plain text (no raw HTML markup);

           o  SHOULD exclude purely template/boilerplate text.

     *  hash (string, REQUIRED)

        -  A validator string of the form:

           o  sha256- followed by 64 lowercase hex characters,

           o  computed as specified in Section 6.2.

        -  The hash field of an M-URL representation MUST equal the strong
           ETag value for that representation, excluding the HTTP quoting.

     Additionally:

     *  profile (string, RECOMMENDED)

        -  TCT profile identifier, e.g., tct-1.

     Example (non-normative):

     json { "profile": "tct-1", "canonical_url": "https://example.com/
     post/", "title": "Article Title", "content": "Core article
     content...", "hash": "sha256-
     2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7" }

  1.5.3.  Representation Stability

     For an M-URL implementing this specification:

     *  For a given resource state, the JSON body MUST be deterministic.

     *  Any change to the JSON body bytes (including required or optional
        fields) MUST result in a different strong ETag (Section 6.2).

     *  Servers MUST NOT include per-request randomness (e.g., varying
        timestamps) in the TCT JSON representation.

  1.6.  Deterministic JSON and Strong ETags






  Jurkovikj                  Expires 18 May 2026                 [Page 12]


  Internet-Draft                     TCT                     November 2025


  1.6.1.  Deterministic JSON Serialization

     M-URL responses MUST use deterministic JSON serialization sufficient
     to support strong ETag semantics:

     Implementations SHOULD use the JSON Canonicalization Scheme (JCS)
     defined in [RFC8785].  Implementations that do not use RFC8785 MUST
     define and implement a canonicalization algorithm that:

     *  produces a single, unique octet sequence for each abstract JSON
        value;

     *  applies stable ordering of object members at all levels (for
        example, lexicographic by code point);

     *  uses deterministic formatting of numbers; and

     *  does not introduce insignificant whitespace beyond what is
        necessary to delimit JSON tokens.

     The same canonicalization algorithm MUST be used both when computing
     the ETag and when generating the response body.

  1.6.2.  Strong ETag Generation (Single Method)

     TCT defines one mandatory method for computing ETags for M-URLs.

     For an M-URL representation:

     1.  Construct the full JSON object representing the resource,
         including all fields except hash.

     2.  Canonicalize this JSON object to a UTF-8 byte sequence as per
         Section 6.1.

     3.  Compute the SHA-256 digest of these bytes.

     4.  Let $F$ be the 64-character lowercase hex encoding of this
         digest.

     5.  Set:

         *  HTTP ETag header:

            -  "sha256-$F"

         *  JSON hash field:




  Jurkovikj                  Expires 18 May 2026                 [Page 13]


  Internet-Draft                     TCT                     November 2025


            -  sha256-$F$

     6.  Canonicalize the final JSON object (now including hash) using the
         same algorithm defined in Section 6.1, and send that canonical
         form as the response body.

     Implementations MUST NOT compute the ETag over one serialization of
     the JSON object and send a different, non-canonical serialization on
     the wire.

     Requirements:

     *  ETags for M-URLs:

        -  MUST be strong (no W/ prefix).

        -  MUST be quoted-strings as in [RFC9110].

     *  Two successful M-URL responses with the same strong ETag MUST have
        identical response body bytes.

     *  Any change in the response body bytes MUST cause the strong ETag
        to change.

  1.6.3.  Relationship to Template-Invariance

     Strong ETags in TCT are validators for the M-URL JSON representation
     only.

     Template-invariance is achieved structurally:

     *  M-URLs do not include HTML templates or layout.

     *  Changes to C-URL HTML that do not affect the M-URL JSON do not
        affect the strong ETag.

     *  For TCT-conformant M-URLs, strong ETags MUST be representation-
        based and MUST NOT vary per request in the absence of a change to
        the underlying JSON representation.

  1.6.4.  Canonical Text Normalization (Optional for Producers)

     TCT does not require clients to normalize text or recompute hashes.

     Use of this normalization algorithm is OPTIONAL and is not required
     for TCT conformance by either servers or clients.  It defines an
     additional 'TCT text normalization' profile for implementations that
     choose to adopt it.



  Jurkovikj                  Expires 18 May 2026                 [Page 14]


  Internet-Draft                     TCT                     November 2025


     However, producers or validators that derive text fields (such as
     content) from upstream formats MAY implement the normalization
     algorithm defined here to ensure stable input before JSON
     canonicalization.

     If an implementation claims conformance to this normalization, it:

     *  MUST follow the algorithm in this section; and

     *  MUST pass the test vectors in Appendix A.

     Algorithm (summary):

     Given input string S:

     1.  (Optional) HTML entity decoding:

         *  If starting from HTML source, deterministically decode
            character references.

     2.  Unicode normalization:

         *  Apply NFKC as defined in Unicode Standard Annex #15 (UAX15).

     3.  Case folding:

         *  Apply Unicode case folding as defined in Unicode-CaseFolding.

         *  Locale-dependent mappings MUST NOT be used.

     4.  Control characters:

         *  Remove all Cc characters except:

            -  U+0009 (TAB), U+000A (LF), U+000D (CR).

     5.  Whitespace collapsing:

         *  Define set W:

            -  U+0020, U+0009, U+000A, U+000D.

         *  Optionally treat U+00A0 as whitespace, if done consistently.

         *  Replace each maximal run of W (and optional NBSP) with a
            single U+0020 SPACE.

     6.  Trim:



  Jurkovikj                  Expires 18 May 2026                 [Page 15]


  Internet-Draft                     TCT                     November 2025


         *  Remove leading and trailing SPACE (U+0020).

     The result is the normalized string N(S).

     Details, examples, and conformance language are in Appendix A.

  1.7.  M-Sitemap Format and Semantics

  1.7.1.  M-Sitemap JSON Structure

     The M-Sitemap is a JSON object that lists TCT-enabled resources.

     Fields:

     *  version (integer, REQUIRED)

        -  M-Sitemap format version.  Initial value: 1.

     *  profile (string, RECOMMENDED)

        -  Profile identifier, e.g., tct-1.

     *  items (array of objects, REQUIRED)

        -  Each item:

           o  cUrl (string, REQUIRED)

              +  Canonical URL.

           o  mUrl (string, REQUIRED)

              +  M-URL of the JSON representation.

           o  etag (string, REQUIRED)

              +  Strong validator identifier, equal to the M-URL ETag
                 value without quotes.

              +  MUST be sha256- followed by the 64-hex digest used in
                 Section 6.2.

     Example:

     json { "version": 1, "profile": "tct-1", "items": [ { "cUrl":
     "https://example.com/post/", "mUrl": "https://example.com/post/
     llm.json", "etag": "sha256-
     2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7" } ] }



  Jurkovikj                  Expires 18 May 2026                 [Page 16]


  Internet-Draft                     TCT                     November 2025


  1.7.2.  HTTP Response for M-Sitemap

     The M-Sitemap:

     *  MUST use:

        -  Content-Type: application/json; charset=utf-8

     *  SHOULD use cache directives that encourage timely revalidation,
        for example:

        -  Cache-Control: max-age=0, must-revalidate, or

        -  a short max-age value appropriate to the site's update
           frequency.

     *  SHOULD include:

        -  Vary: Accept-Encoding

  1.7.3.  Parity Semantics

     Design intent:

     *  M-Sitemap etag values SHOULD match the current strong ETag values
        of their corresponding M-URLs.

     Requirements:

     *  Publishers MUST compute etag values using the same algorithm as
        Section 6.2.

     *  Publishers SHOULD keep M-Sitemap etag values in sync with M-URL
        ETags.

     *  Transient mismatches (due to non-atomic updates, caches, or
        propagation delays) MAY occur.

     Client behavior:

     *  Clients SHOULD treat M-Sitemap etag as a hint for change
        detection.

     *  Clients MAY compare etag with the M-URL ETag.

     *  Clients MUST NOT treat mismatches alone as protocol errors.





  Jurkovikj                  Expires 18 May 2026                 [Page 17]


  Internet-Draft                     TCT                     November 2025


     *  In case of mismatch, clients SHOULD fall back to standard
        conditional requests on the M-URL and treat the M-Sitemap etag as
        an advisory signal only.

     Strong ETag values for M-URLs and etag values in the M-Sitemap are
     scoped to the origin that serves them.  Clients MUST NOT assume that
     identical validator values observed on different origins imply
     identical content.

  1.8.  Client Behavior

  1.8.1.  Zero-Fetch Optimization

     A typical TCT-aware client:

     1.  Fetches / and discovers the M-Sitemap via Link.

     2.  Fetches the M-Sitemap.

     3.  For each item (cUrl, mUrl, etag):

         *  If it has a cached ETag for mUrl:

            -  If cached ETag equals sitemap etag:

               o  MAY skip fetching mUrl (zero-fetch).

            -  Otherwise:

               o  SHOULD issue conditional GET:

                  +  GET mUrl

                  +  If-None-Match: "sha256-...".

         *  If no cached ETag:

            -  SHOULD fetch mUrl with GET.

            -  MAY include If-None-Match using sitemap etag as hint.

     This enables large reductions in redundant fetches.

     This optimization is OPTIONAL.  Clients that prefer strict HTTP cache
     validation MAY always perform a conditional GET with If-None-Match on
     M-URLs instead of relying solely on M-Sitemap etag hints.





  Jurkovikj                  Expires 18 May 2026                 [Page 18]


  Internet-Draft                     TCT                     November 2025


  1.8.2.  Conditional Requests to M-URLs

     M-URLs implementing TCT:

     *  MUST support If-None-Match as defined in [RFC9110].

     Specifically:

     *  If If-None-Match matches the current strong ETag:

        -  Respond with 304 Not Modified, no body.

     *  Otherwise:

        -  Respond with 200 OK and the JSON representation.

     If both If-None-Match and If-Modified-Since are present:

     *  If-None-Match MUST take precedence (per [RFC9110]).

     Servers SHOULD send appropriate Cache-Control directives to encourage
     revalidation and safe caching.

  1.8.3.  Use of HEAD (Optional)

     Clients MAY use HEAD on M-URLs as an optimization:

     *  If a HEAD response includes an ETag equal to the cached one, a GET
        may be skipped.

     *  If HEAD is unreliable, clients SHOULD fall back to conditional
        GET.

     Conditional GET with If-None-Match SHOULD be considered the primary
     mechanism.

  1.8.4.  Client Validation (Optional)

     For protocol correctness:

     *  Clients are not required to implement the text normalization
        algorithm or to recompute validators.

     *  Clients MAY treat ETags and sitemap etag values as opaque.

     Clients MAY perform additional checks as desired, such as:





  Jurkovikj                  Expires 18 May 2026                 [Page 19]


  Internet-Draft                     TCT                     November 2025


     *  verifying that an M-URL includes rel="canonical" pointing at the
        expected C-URL;

     *  checking M-Sitemap etag vs M-URL ETag parity;

     *  recomputing hashes using the published algorithms.

     Such additional checks are implementation choices and are out of
     scope for TCT compliance.

  1.9.  Operational Considerations (Informative)

  1.9.1.  Deployment with CDNs and Proxies

     *  M-URLs and M-Sitemaps are ordinary cacheable JSON resources.

     *  CDNs and reverse proxies:

        -  MAY cache them;

        -  SHOULD honor strong ETags and 304 responses.

     *  Since ETags are based on uncompressed canonical JSON:

        -  Downstream compression does not invalidate validators.

  1.9.2.  Large Sites and Sharding

     For very large sites:

     *  Operators MAY create multiple M-Sitemaps (e.g., per section or
        date).

     *  A primary M-Sitemap can list additional ones by convention.

     *  This document does not standardize a JSON sitemap index; such work
        may be done separately.

     A future revision of this specification or a separate document MAY
     define a JSON M-Sitemap index format, analogous to the XML Sitemap
     Index, to provide interoperable conventions for sharding and large-
     site discovery.

  1.9.3.  Error Handling

     Recommended behavior:

     *  If the M-Sitemap is unavailable or invalid:



  Jurkovikj                  Expires 18 May 2026                 [Page 20]


  Internet-Draft                     TCT                     November 2025


        -  Treat TCT as temporarily unavailable.

     *  If an M-URL returns 4xx/5xx:

        -  Follow normal HTTP semantics for retries/backoff.

     *  If the M-URL is persistently broken:

        -  Clients MAY ignore it and rely on the C-URL HTML, if
           appropriate.

  1.9.4.  Backwards Compatibility

     *  TCT is purely additive:

        -  It does not alter C-URL semantics.

        -  Non-participating clients see no change.

     *  Operators can deploy TCT incrementally on selected resources.

  1.10.  Security Considerations

     TCT builds directly on HTTP; most security considerations are
     inherited from [RFC9110] and [RFC9111].

     Key points:

     *  HTTPS:

        -  Publishers SHOULD serve M-URLs and M-Sitemaps over HTTPS.

        -  Clients SHOULD validate TLS as usual.

     *  Integrity:

        -  Strong ETags identify specific representations but do not
           authenticate servers.

        -  For stronger guarantees, publishers MAY use:

           o  Content-Digest headers ([RFC9530]); and/or

           o  HTTP Message Signatures ([RFC9421]).

     *  Access control:





  Jurkovikj                  Expires 18 May 2026                 [Page 21]


  Internet-Draft                     TCT                     November 2025


        -  If a C-URL requires authentication, its corresponding M-URL
           SHOULD be similarly protected.

        -  M-Sitemaps MUST NOT leak sensitive M-URLs or validators.

     *  Cache poisoning:

        -  Correct use of ETag and Cache-Control mitigates stale or mixed
           content.

        -  Clients MUST treat JSON as untrusted data and validate/sanitize
           as appropriate.

     *  Privacy:

        -  As with any sitemap, listing URLs in an M-Sitemap can reveal
           site structure.

        -  Publishers concerned about this SHOULD limit entries or
           restrict access.

     *  Origin trust:

        -  Clients that consume M-Sitemaps and M-URLs inherently trust the
           origin in the same way they trust HTML pages or XML Sitemaps
           from that origin.  A compromised or misconfigured origin can
           advertise incorrect mappings; this is not a new class of attack
           introduced by TCT.

     *  Intermediaries:

        -  Deployments SHOULD ensure that CDNs and other intermediaries do
           not strip or rewrite strong ETags on M-URLs or M-Sitemaps, as
           doing so can interfere with correct validation and zero-fetch
           behavior.

  1.11.  IANA Considerations

     This document has no IANA actions.

     A future revision or separate document MAY define and register:

     *  a well-known URI for TCT M-Sitemaps; and/or

     *  a dedicated media type or profile parameter for TCT JSON.

     Such registrations are intentionally out of scope for this version.




  Jurkovikj                  Expires 18 May 2026                 [Page 22]


  Internet-Draft                     TCT                     November 2025


  2.  References

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

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

     [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
                Canonicalization Scheme (JCS)", RFC 8785,
                DOI 10.17487/RFC8785, June 2020,
                <https://www.rfc-editor.org/info/rfc8785>.

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

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

  2.2.  Informative References

     [RFC6596]  Ohye, M. and J. Kupke, "The Canonical Link Relation",
                RFC 6596, DOI 10.17487/RFC6596, April 2012,
                <https://www.rfc-editor.org/info/rfc6596>.

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

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





  Jurkovikj                  Expires 18 May 2026                 [Page 23]


  Internet-Draft                     TCT                     November 2025


  Appendix A.  Appendix A.  Normalization Test Vectors

     This appendix provides test vectors for implementations that claim
     conformance to the normalization algorithm (Section 6.4).

     *Conformance Requirement:* Implementations claiming normalization
     support MUST produce the outputs specified below for all test inputs.

     *Test Format:* Each test shows: - Input string - Output after each
     normalization step - Final SHA-256 hash (computed over UTF-8 bytes of
     final output)

  A.1.  A.1.  Basic ASCII

     *Test 1: Simple ASCII text* - Input: "Hello World" - After step 1
     (HTML decode): "Hello World" - After step 2 (NFKC): "Hello World" -
     After step 3 (casefold): "hello world" - After step 4 (control
     chars): "hello world" - After step 5 (whitespace): "hello world" -
     After step 6 (trim): "hello world" - SHA-256:
     b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

     *Test 2: Leading/trailing whitespace* - Input: " Hello World " -
     After step 1: " Hello World " - After step 2: " Hello World " - After
     step 3: " hello world " - After step 4: " hello world " - After step
     5: " hello world " - After step 6: "hello world" - SHA-256:
     b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

     *Test 3: Multiple spaces* - Input: "Hello World" - After step 1:
     "Hello World" - After step 2: "Hello World" - After step 3: "hello
     world" - After step 4: "hello world" - After step 5: "hello world" -
     After step 6: "hello world" - SHA-256:
     b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

  A.1.1.  A.2.  HTML Entities

     *Test 4: Common HTML entities* - Input: "Hello &amp; goodbye" - After
     step 1: "Hello & goodbye" - After step 2: "Hello & goodbye" - After
     step 3: "hello & goodbye" - After step 4: "hello & goodbye" - After
     step 5: "hello & goodbye" - After step 6: "hello & goodbye" - SHA-
     256: da73536eaa9c427f3189de5b6371d798193e98f3c31df8bef710bba835e8c621

     *Test 5: Angle brackets* - Input: "&lt;tag&gt;" - After step 1:
     "<tag>" - After step 2: "<tag>" - After step 3: "<tag>" - After step
     4: "<tag>" - After step 5: "<tag>" - After step 6: "<tag>" - SHA-256:
     c81ef880af0fcfef49e1b45c3690a1666c47d9e064b7eaead2af09bb78884dcd






  Jurkovikj                  Expires 18 May 2026                 [Page 24]


  Internet-Draft                     TCT                     November 2025


     *Test 6: Quotes* - Input: "&quot;quoted&quot;" - After step 1:
     "\"quoted\"" - After step 2: "\"quoted\"" - After step 3:
     "\"quoted\"" - After step 4: "\"quoted\"" - After step 5:
     "\"quoted\"" - After step 6: "\"quoted\"" - SHA-256:
     272fca25899893eeb27b89583d5c81b8a4ac5af4d1e37e3909d879947303c1c5

  A.1.2.  A.3.  Unicode Normalization (NFKC)

     *Test 7: Composed vs decomposed é* - Input (composed): "Café"
     (U+00E9) - After step 1: "Café" - After step 2 (NFKC): "Café"
     (normalized to composed form) - After step 3: "café" - After step 4:
     "café" - After step 5: "café" - After step 6: "café" - SHA-256:
     850f7dc43910ff890f8879c0ed26fe697c93a067ad93a7d50f466a7028a9bf4e

     *Test 7b: Decomposed form (should produce same result)* - Input
     (decomposed): "Cafe\u0301" (e + combining acute) - After step 2
     (NFKC): "Café" (normalized to composed) - Final result: Same as Test
     7 - SHA-256:
     850f7dc43910ff890f8879c0ed26fe697c93a067ad93a7d50f466a7028a9bf4e
     (same as Test 7)

     *Test 8: Full-width characters* - Input: "ＨＥＬＬＯ" (full-width Latin) -
     After step 1: "ＨＥＬＬＯ" - After step 2 (NFKC): "HELLO" (converted to
     half-width) - After step 3: "hello" - After step 4: "hello" - After
     step 5: "hello" - After step 6: "hello" - SHA-256:
     2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

  A.1.3.  A.4.  Case Folding Edge Cases

     *Test 9: German sharp S* - Input: "Straße" - After step 1: "Straße" -
     After step 2: "Straße" - After step 3 (casefold): "strasse" (ß -> ss)
     - After step 4: "strasse" - After step 5: "strasse" - After step 6:
     "strasse" - SHA-256:
     16d96952087774fee069b7585d3991b24d90c181c09b2129b4908c35baa7f0c0

     *Test 10: Turkish İ (dotted capital I)* - Input: "İstanbul" - After
     step 1: "İstanbul" - After step 2: "İstanbul" - After step 3
     (casefold): "i\u0307stanbul" (locale-independent) - After step 4:
     "i\u0307stanbul" - After step 5: "i\u0307stanbul" - After step 6:
     "i\u0307stanbul" - SHA-256:
     4a4df120f7d1f3c286f58651abfcec2aade892ace635f96f02b946c96e6e1f86










  Jurkovikj                  Expires 18 May 2026                 [Page 25]


  Internet-Draft                     TCT                     November 2025


  A.1.4.  A.5.  Control Characters

     *Test 11: Embedded tab* - Input: "Hello\tWorld" - After step 1:
     "Hello\tWorld" - After step 2: "Hello\tWorld" - After step 3:
     "hello\tworld" - After step 4: "hello\tworld" (tab preserved) - After
     step 5: "hello world" (tab -> space) - After step 6: "hello world" -
     SHA-256:
     b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

     *Test 12: Embedded newline* - Input: "Hello\nWorld" - After step 1:
     "Hello\nWorld" - After step 2: "Hello\nWorld" - After step 3:
     "hello\nworld" - After step 4: "hello\nworld" (newline preserved) -
     After step 5: "hello world" (newline -> space) - After step 6: "hello
     world" - SHA-256:
     b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

     *Test 13: Control character (BEL)* - Input: "Hello\u0007World"
     (U+0007 = BEL) - After step 1: "Hello\u0007World" - After step 2:
     "Hello\u0007World" - After step 3: "hello\u0007world" - After step 4:
     "helloworld" (control char removed) - After step 5: "helloworld" -
     After step 6: "helloworld" - SHA-256:
     936a185caaa266bb9cbe981e9e05cb78cd732b0b3280eb944412bb6f8f8f07af

  A.1.5.  A.6.  Whitespace Edge Cases

     *Test 14: Non-breaking space (NBSP)* - Input: "Hello\u00A0World"
     (U+00A0 = NBSP) - After step 1: "Hello\u00A0World" - After step 2:
     "Hello\u00A0World" - After step 3: "hello\u00A0world" - After step 4:
     "hello\u00A0world" - After step 5: "hello world" (NBSP -> space, if
     treating NBSP as whitespace) - After step 6: "hello world" - SHA-256:
     b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

     *Note:* Step 5 behavior for NBSP is implementation-defined per
     Section 6.4 ("Optionally treat U+00A0 as whitespace, if done
     consistently").  This test assumes NBSP is treated as whitespace.

     *Test 15: Mixed whitespace* - Input: "Hello \t\n World" - After step
     1: "Hello \t\n World" - After step 2: "Hello \t\n World" - After step
     3: "hello \t\n world" - After step 4: "hello \t\n world" - After step
     5: "hello world" - After step 6: "hello world" - SHA-256:
     b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

  A.1.6.  A.7.  Empty and Edge Cases

     *Test 16: Empty string* - Input: "" - After all steps: "" - SHA-256:
     e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855





  Jurkovikj                  Expires 18 May 2026                 [Page 26]


  Internet-Draft                     TCT                     November 2025


     *Test 17: Whitespace only* - Input: " " - After step 1: " " - After
     step 2: " " - After step 3: " " - After step 4: " " - After step 5: "
     " - After step 6: "" (trimmed) - SHA-256:
     e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

     *Test 18: Single character* - Input: "A" - After step 1: "A" - After
     step 2: "A" - After step 3: "a" - After step 4: "a" - After step 5:
     "a" - After step 6: "a" - SHA-256:
     ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb

  A.1.7.  A.8.  Complex Real-World Examples

     *Test 19: Article excerpt* - Input: "The café's "special" offer: 50%
     off!" - Expected output after normalization: the café's "special"
     offer: 50% off! - SHA-256:
     25cdbe2315674d38ddaf1df6fe7ccd494ce89efebe8a3b5285742e57e7367545

     *Test 20: Unicode mixed with entities* - Input: "Cliché &amp; résumé"
     - Expected output after normalization: cliché & résumé - SHA-256:
     7d56f360edd22f7be0bc0f126d45481df83e8afc68b83788cf37544c4ee6ce21

  A.1.8.  A.9.  Implementation Notes

     *Computing SHA-256:* - Encode the final normalized string as UTF-8
     bytes - Compute SHA-256 over those bytes - Express result as 64
     lowercase hex characters

     *Test Vector Validation:* - Implementations claiming normalization
     support MUST produce the SHA-256 hashes specified above - The seven
     "hello world" variants (Tests 1, 2, 3, 11, 12, 14, 15) all normalize
     to identical output ("hello world"), demonstrating whitespace
     normalization equivalence - Tests 7 and 7b demonstrate NFKC combining
     character handling (both produce identical hashes)

  A.2.  Appendix B.  Example Flows (Informative)

     This appendix illustrates TCT discovery and fetch patterns.

  A.2.1.  B.1.  Initial Discovery and First Fetch

     *Scenario:* Client visits origin for the first time.

     ``` 1.  Client -> Server: GET / HTTP/1.1 Host: example.com

     1.  Server -> Client: HTTP/1.1 200 OK Link: </llm-pages.json>;
         rel="index"; type="application/json" Content-Type: text/html

                      [HTML body...]



  Jurkovikj                  Expires 18 May 2026                 [Page 27]


  Internet-Draft                     TCT                     November 2025


     2.  Client -> Server: GET /llm-pages.json HTTP/1.1 Host: example.com

     3.  Server -> Client: HTTP/1.1 200 OK Content-Type: application/json;
         charset=utf-8 Cache-Control: max-age=0, must-revalidate

                     {
                       "version": 1,
                       "profile": "tct-1",
                       "items": [
                         {
                           "cUrl": "https://example.com/article/",
                           "mUrl": "https://example.com/article/llm.json",
                           "etag": "sha256-abc123..."
                         }
                       ]
                     }

     4.  Client -> Server: GET /article/llm.json HTTP/1.1 Host:
         example.com

     5.  Server -> Client: HTTP/1.1 200 OK Content-Type: application/json;
         charset=utf-8 ETag: "sha256-abc123..." Link: https://example.com/
         article/ (https://example.com/article/); rel="canonical"

                      {
                        "profile": "tct-1",
                        "canonical_url": "https://example.com/article/",
                        "title": "Article Title",
                        "content": "Article content...",
                        "hash": "sha256-abc123..."
                      } ```

     *Client actions after step 6:* - Stores M-URL content locally -
     Caches ETag "sha256-abc123..." for future revalidation

  A.2.2.  B.2.  Zero-Fetch Optimization (Content Unchanged)

     *Scenario:* Client returns after some time; content hasn't changed.

     ``` 1.  Client -> Server: GET /llm-pages.json HTTP/1.1 Host:
     example.com

     1.  Server -> Client: HTTP/1.1 200 OK Content-Type: application/json;
         charset=utf-8







  Jurkovikj                  Expires 18 May 2026                 [Page 28]


  Internet-Draft                     TCT                     November 2025


                     {
                       "version": 1,
                       "items": [
                         {
                           "cUrl": "https://example.com/article/",
                           "mUrl": "https://example.com/article/llm.json",
                           "etag": "sha256-abc123..."
                         }
                       ]
                     }

     2.  Client local comparison:

         *  Sitemap etag: "sha256-abc123..."

         *  Cached ETag: "sha256-abc123..."

         *  Match! -> Skip fetch entirely (zero-fetch)

     3.  Client uses locally cached content for /article/ ```

     *Result:* Zero bytes transferred for M-URL; content known to be
     current.

  A.2.3.  B.3.  Conditional Request (Content Unchanged)

     *Scenario:* Sitemap etag differs from cache, but actual content
     hasn't changed.

     ``` 1.  Client -> Server: GET /llm-pages.json HTTP/1.1

     1.  Server -> Client: [Sitemap shows etag: "sha256-def456..."]

     2.  Client comparison:

         *  Sitemap etag: "sha256-def456..." (different!)

         *  Cached ETag: "sha256-abc123..."

         *  Mismatch -> Must fetch, but use conditional request

     3.  Client -> Server: GET /article/llm.json HTTP/1.1 If-None-Match:
         "sha256-abc123..."

     4.  Server -> Client: HTTP/1.1 304 Not Modified ETag:
         "sha256-abc123..."

     5.  Client actions:



  Jurkovikj                  Expires 18 May 2026                 [Page 29]


  Internet-Draft                     TCT                     November 2025


         *  Content unchanged; uses cached copy

         *  Notes: sitemap was stale/inconsistent; no protocol violation
            ```

     *Result:* Small 304 response instead of full payload.

  A.2.4.  B.4.  Content Changed

     *Scenario:* Content has been updated.

     ``` 1.  Client -> Server: GET /llm-pages.json HTTP/1.1

     1.  Server -> Client: [Sitemap shows etag: "sha256-xyz789..."]

     2.  Client comparison:

         *  Sitemap etag: "sha256-xyz789..." (different)

         *  Cached ETag: "sha256-abc123..."

         *  Mismatch -> Fetch with If-None-Match

     3.  Client -> Server: GET /article/llm.json HTTP/1.1 If-None-Match:
         "sha256-abc123..."

     4.  Server -> Client: HTTP/1.1 200 OK Content-Type: application/json;
         charset=utf-8 ETag: "sha256-xyz789..."

                      {
                        "canonical_url": "https://example.com/article/",
                        "title": "Updated Title",
                        "content": "Updated content...",
                        "hash": "sha256-xyz789..."
                      }

     5.  Client actions:

         *  Replaces cached content

         *  Updates cached ETag to "sha256-xyz789..." ```

     *Result:* Full new representation received.

  A.2.5.  B.5.  Parity Mismatch Handling

     *Scenario:* Sitemap etag doesn't match actual M-URL ETag (transient
     inconsistency).



  Jurkovikj                  Expires 18 May 2026                 [Page 30]


  Internet-Draft                     TCT                     November 2025


     ``` 1.  Client -> Server: GET /llm-pages.json HTTP/1.1

     1.  Server -> Client: [Sitemap shows etag: "sha256-old999..."]

     2.  Client -> Server: GET /article/llm.json HTTP/1.1 If-None-Match:
         "sha256-old999..."

     3.  Server -> Client: HTTP/1.1 200 OK ETag: "sha256-new000..." <-
         Different from sitemap!

                      [Full M-URL JSON...]

     4.  Client actions:

         *  Accepts M-URL response (valid per HTTP)

         *  Uses ETag from M-URL response ("sha256-new000...") for future
            revalidation

         *  Notes: sitemap inconsistency tolerated; no error ```

     *Result:* Client falls back to standard HTTP caching; no protocol
     failure.

  A.2.6.  B.6.  Using HEAD for Efficient Freshness Check

     *Scenario:* Client wants to check freshness before fetching.

     ``` 1.  Client -> Server: HEAD /article/llm.json HTTP/1.1 If-None-
     Match: "sha256-abc123..."

     1.  Server -> Client: HTTP/1.1 304 Not Modified ETag:
         "sha256-abc123..."

     2.  Client actions:

         *  Content unchanged; uses cached copy

         *  Avoided transferring full body

     OR (if content changed):

     1.  Server -> Client: HTTP/1.1 200 OK ETag: "sha256-xyz789..."
         Content-Length: 4567

     2.  Client -> Server: GET /article/llm.json HTTP/1.1 If-None-Match:
         "sha256-abc123..."




  Jurkovikj                  Expires 18 May 2026                 [Page 31]


  Internet-Draft                     TCT                     November 2025


     3.  Server -> Client: HTTP/1.1 200 OK ETag: "sha256-xyz789..."

                      [Full M-URL JSON...] ```

     *Note:* HEAD support is optional; conditional GET is the primary
     mechanism.

  A.2.7.  B.7.  Discovery via C-URL

     *Scenario:* Client discovers M-URL directly from HTML page.

     ``` 1.  Client -> Server: GET /article/ HTTP/1.1

     1.  Server -> Client: HTTP/1.1 200 OK Link: </article/llm.json>;
         rel="alternate"; type="application/json" Content-Type: text/html

                      <!DOCTYPE html>
                      <html>
                      <head>
                        <link rel="alternate" type="application/json"
                              href="https://example.com/article/llm.json">
                      </head>
                      ...

     2.  Client -> Server: GET /article/llm.json HTTP/1.1

     3.  Server -> Client: HTTP/1.1 200 OK ETag: "sha256-abc123..." Link:
         https://example.com/article/ (https://example.com/article/);
         rel="canonical"

                      [M-URL JSON...]

     4.  Client verifies:

         *  Canonical link points back to /article/ -> Consistent OK ```

     *Result:* M-URL discovered and validated without sitemap.

  A.3.  Appendix C.  Implementation Notes (Informative)

     This appendix provides guidance for implementers.

  A.3.1.  C.1.  Reference Implementations

     *Note:* The following implementations are provided as informative
     examples.  Repository URLs, package names, and deployment details may
     change over time and are not normative.




  Jurkovikj                  Expires 18 May 2026                 [Page 32]


  Internet-Draft                     TCT                     November 2025


     The following implementations demonstrate TCT in production
     environments:

     *WordPress Plugin (PHP):* - Repository: https://github.com/
     antunjurkovic-collab/tct-wp-plugin - Version: 1.0.0 - Deployment: 3
     production sites (970 URLs total) - Features: - Automatic M-URL
     generation for posts/pages - M-Sitemap generation and caching -
     Strong ETag computation using canonical JSON - Normalization
     algorithm implementation - Dependencies: WordPress 6.0+, PHP 7.4+ -
     JSON serialization: json_encode() with JSON_UNESCAPED_SLASHES |
     JSON_UNESCAPED_UNICODE

     *Python Validator:* - PyPI package: collab-tunnel
     (https://pypi.org/project/collab-tunnel/1.0.2/) - Version: 1.0.2 -
     Purpose: Protocol compliance testing - Features: - Validates M-URL
     and M-Sitemap structure - Tests ETag parity - Verifies canonical link
     bidirectionality - Runs normalization test vectors - Usage: python
     from collab_tunnel import validate_origin results =
     validate_origin("https://example.com")

     *Cloudflare Worker (Edge Proxy):* - Repository: https://github.com/
     antunjurkovic-collab/tct-worker - Purpose: Demonstrates CDN
     integration - Features: - Proxies M-URLs with proper ETag handling -
     Implements 304 Not Modified caching - Handles conditional requests
     correctly - Deployment: Cloudflare Workers platform

  A.3.2.  C.2.  Deterministic JSON Libraries

     For RFC 8785 (JSON Canonicalization Scheme) compliance:

     *Python:* python import canonicaljson canonical_bytes =
     canonicaljson.encode_canonical_json(obj) - Library: pip install
     canonicaljson - Docs: https://github.com/matrix-org/python-
     canonicaljson

     *JavaScript:* javascript const canonicalize =
     require('canonicalize'); const canonical_string = canonicalize(obj);
     - Library: npm install canonicalize - Docs:
     https://github.com/cyberphone/json-canonicalization

     *Go:* go import "github.com/cyberphone/json-canonicalization/go/json"
     canonical, _ := json.CanonicalizeJSON(input)

     *Alternative (Stable Ordering):* If not using RFC 8785, ensure: -
     Object keys sorted lexicographically (at ALL nesting levels) - No
     insignificant whitespace - Consistent number formatting - UTF-8
     encoding without BOM




  Jurkovikj                  Expires 18 May 2026                 [Page 33]


  Internet-Draft                     TCT                     November 2025


     *Important:* Simple key-sorting helpers (e.g.,
     Object.keys(obj).sort() in JavaScript) are *insufficient* for nested
     objects.  For production implementations claiming TCT conformance,
     use RFC 8785 libraries or implement the full specification.  The code
     examples in C.3 are *illustrative only* and may not handle all edge
     cases correctly.

  A.3.3.  C.3.  SHA-256 Computation

     The examples in this section are illustrative only.  By themselves
     they do not guarantee the deterministic JSON requirements of
     Section 6.1 unless combined with a complete canonicalization
     algorithm such as RFC8785.

     *Note:* The examples below are simplified for illustration.  For
     production use, ensure proper RFC 8785 canonicalization (see C.2)
     before hashing.

     *Python:* ```python import hashlib import json

  Appendix B.  Canonical JSON

     canonical_json = json.dumps(obj, ensure_ascii=False, sort_keys=True,
     separators=(',', ':')) canonical_bytes = canonical_json.encode('utf-
     8')

  Appendix C.  Hash

     sha256_hash = hashlib.sha256(canonical_bytes).hexdigest() etag_value
     = f'"sha256-{sha256_hash}"' ```

     *JavaScript:* ```javascript const crypto = require('crypto');

     // Canonical JSON // NOTE: This is illustrative only; for full
     conformance, use RFC 8785 or a complete canonicalization
     implementation. const canonical_json = JSON.stringify(obj,
     Object.keys(obj).sort()); const canonical_bytes =
     Buffer.from(canonical_json, 'utf-8');

     // Hash const sha256_hash =
     crypto.createHash('sha256').update(canonical_bytes).digest('hex');
     const etag_value = "sha256-${sha256_hash}"; ```

     *PHP:* ```php // Canonical JSON $canonical_json = json_encode($obj,
     JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);

     // Hash $sha256_hash = hash('sha256', $canonical_json); $etag_value =
     '"sha256-' . $sha256_hash . '"'; ```



  Jurkovikj                  Expires 18 May 2026                 [Page 34]


  Internet-Draft                     TCT                     November 2025


  C.1.  C.4.  Unicode Normalization

     *Python:* ```python import unicodedata

  Appendix D.  NFKC normalization

     normalized = unicodedata.normalize('NFKC', text)

  Appendix E.  Case folding

     casefolded = normalized.casefold() ```

     *JavaScript:* ```javascript // NFKC normalization const normalized =
     text.normalize('NFKC');

     // Case folding (approximation: toLowerCase with locale-independent
     behavior) const casefolded = normalized.toLocaleLowerCase('en-US');
     ```

     *PHP:* ```php // NFKC normalization (requires intl extension)
     $normalized = Normalizer::normalize($text, Normalizer::NFKC);

     // Case folding (mb_strtolower with UTF-8) $casefolded =
     mb_strtolower($normalized, 'UTF-8'); ```

  E.1.  C.5.  HTTP Response Headers

     *Typical headers for M-URLs:*

     A conformant M-URL response will include at least: Content-Type:
     application/json, ETag (strong, quoted), and Link: rel="canonical"
     (see Sections 5-6).  Example:

     HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 ETag:
     "sha256-abc123..." Link: <https://example.com/article/>;
     rel="canonical" Cache-Control: public, max-age=3600, must-revalidate
     Vary: Accept-Encoding

     *Typical headers for M-Sitemap:* HTTP/1.1 200 OK Content-Type:
     application/json; charset=utf-8 Cache-Control: max-age=0, must-
     revalidate # Example; a short max-age consistent with Section 7.2 MAY
     also be used Vary: Accept-Encoding

     *Conditional request handling:* ``` # Request with If-None-Match GET
     /article/llm.json HTTP/1.1 If-None-Match: "sha256-abc123..."






  Jurkovikj                  Expires 18 May 2026                 [Page 35]


  Internet-Draft                     TCT                     November 2025


  Appendix F.  Response if unchanged

     HTTP/1.1 304 Not Modified ETag: "sha256-abc123..." Cache-Control:
     public, max-age=3600, must-revalidate

  Appendix G.  Response if changed

     HTTP/1.1 200 OK ETag: "sha256-xyz789..." Content-Type: application/
     json; charset=utf-8 [full body...] ```

  G.1.  C.6.  Production Deployment Data

     *Note:* The following deployment data represents a snapshot as of
     November 2025.  Specific sites, URLs, and metrics are provided as
     informative examples and may change.

     As of November 2025, TCT is deployed on:

     *bestdemotivationalposters.com:* - 500 URLs - 100K+ pageviews/month -
     WordPress 6.4 + TCT plugin v1.0.0 - Average HTML size: 103 KB
     (gzipped) - Average M-URL size: 17.7 KB (gzipped) - Bandwidth
     reduction: 83%

     *wellbeing-support.com:* - 400 URLs - Health/wellness content -
     Average zero-fetch rate: 85%

     *omacedonii.com:* - 70 URLs - Multilingual (Polish) - Demonstrates
     Unicode normalization in production

     *Aggregate Results:* - Total URLs: 970 - Bandwidth reduction: 83%
     median - Zero-fetch rate: 70-90% (depends on update frequency) -
     Combined bandwidth elimination: ~98% in steady-state

  G.1.1.  C.7.  Common Implementation Pitfalls

     *Pitfall 1: Non-deterministic JSON* - Problem: Random key ordering,
     floating-point precision issues, timestamps - Solution: Use RFC 8785
     or strict ordering; exclude per-request randomness

     *Pitfall 2: Weak ETags* - Problem: Using W/"sha256-..." instead of
     "sha256-..." - Solution: Always use strong ETags for M-URLs (no W/
     prefix)

     *Pitfall 3: Sitemap Staleness* - Problem: Sitemap regenerated
     asynchronously; race conditions cause mismatches - Solution: Accept
     transient inconsistency; clients fall back to conditional GET





  Jurkovikj                  Expires 18 May 2026                 [Page 36]


  Internet-Draft                     TCT                     November 2025


     *Pitfall 4: Incorrect Canonical Links* - Problem: rel="canonical"
     points to wrong URL or is missing - Solution: Validate bidirectional
     linkage (C-URL <-> M-URL)

     *Pitfall 5: HTML in Content Field* - Problem: Including raw HTML tags
     in content field - Solution: Extract plain text or use deterministic
     markup (e.g., Markdown)

     *Pitfall 6: Missing Vary: Accept-Encoding* - Problem: CDN caches
     gzipped and uncompressed versions with same key - Solution: Always
     include Vary: Accept-Encoding header

     *Pitfall 7: Locale-Dependent Case Folding* - Problem: Turkish İ -> i
     vs. I -> ı (locale-specific) - Solution: Use Unicode default case
     folding (locale-independent)

  G.1.2.  C.8.  Testing and Validation

     *Automated Testing:* 1.  Protocol compliance: Use collab-tunnel-
     validator PyPI package 2.  Normalization: Run Appendix A test vectors
     3.  ETag parity: Compare sitemap etag vs. actual M-URL ETag 4.
     Conditional requests: Test If-None-Match with matching/non-matching
     ETags

     *Manual Testing:* 1.  Check discovery: curl -I https://example.com/
     (look for Link header) 2.  Fetch sitemap: curl https://example.com/
     llm-pages.json 3.  Validate M-URL: curl -H "Accept: application/json"
     https://example.com/article/llm.json 4.  Test 304: curl -H 'If-None-
     Match: "sha256-..."' https://example.com/article/llm.json

     *Integration Testing:* - Deploy to staging environment - Monitor 304
     response rates (should be >70% after initial crawl) - Check CDN cache
     hit rates - Verify canonical link bidirectionality

  G.1.3.  C.9.  Performance Considerations

     *Server-Side:* - Cache normalized content and ETags (don't recompute
     on every request) - Generate M-Sitemap asynchronously during content
     updates - Use HTTP/2 for parallel M-URL fetches - Implement early
     ETag validation (before full response generation)

     *Client-Side:* - Use zero-fetch optimization when possible (sitemap
     comparison) - Batch M-Sitemap fetches (don't fetch per-URL) -
     Implement exponential backoff for 429/503 responses - Cache M-URLs
     and ETags persistently






  Jurkovikj                  Expires 18 May 2026                 [Page 37]


  Internet-Draft                     TCT                     November 2025


     *CDN/Proxy:* - Configure strong ETag preservation - Enable
     compression (gzip/brotli) with Vary: Accept-Encoding - Cache 304
     responses appropriately - Don't strip ETag headers

  G.1.4.  C.10.  Security Best Practices

     *HTTPS:* - It is RECOMMENDED to serve M-URLs and M-Sitemap over HTTPS
     (see Section 10) - Validate TLS certificates properly - Use HSTS
     where appropriate

     *Access Control:* - If C-URL requires authentication, protect M-URL
     similarly - Don't leak sensitive URLs in public sitemaps - Implement
     rate limiting to prevent abuse

     *Content Validation:* - Treat M-URL JSON as untrusted input -
     Validate/sanitize before use - Don't execute code from content field

     *ETag Integrity:* - Use Content-Digest (RFC 9530) for additional
     integrity - Consider HTTP Message Signatures (RFC 9421) for
     authentication - Monitor for ETag collision attempts (though SHA-256
     makes this infeasible)

  Appendix H.  Acknowledgments

     Thanks to reviewers and implementers who provided feedback on earlier
     revisions, including those who highlighted:

     *  the need for a single strong ETag method;

     *  the importance of deterministic JSON;

     *  the separation of protocol from policy; and

     *  simplification of discovery and parity semantics.

  Author's Address

     Antun Jurkovikj
     North Macedonia
     Email: antunjurkovic@gmail.com











  Jurkovikj                  Expires 18 May 2026                 [Page 38]


name: draft-meyerzuselha-oauth-web-message-response-mode
rev: 01
title: OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows
time: 2025-11-05T16:36:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-09T16:36:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:06.864803+00:00
abstract:
  This specification defines the web message response mode that
     authorization servers use for transmitting authorization response
     parameters via the user-agent's postMessage API to the client.  This
     mode is intended for authorization flows that use secondary windows,
     which are well-suited for browser-based applications.

full_text:
  Web Authorization Protocol                         K. Meyer zu Selhausen
  Internet-Draft                                                 Hackmanit
  Intended status: Standards Track                              L. Jannett
  Expires: 9 May 2026                               Ruhr University Bochum
                                                                 C. Mainka
                                                                 Hackmanit
                                                           5 November 2025


      OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based
                            Authorization Flows
           draft-meyerzuselha-oauth-web-message-response-mode-01

  Abstract

     This specification defines the web message response mode that
     authorization servers use for transmitting authorization response
     parameters via the user-agent's postMessage API to the client.  This
     mode is intended for authorization flows that use secondary windows,
     which are well-suited for browser-based applications.

  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 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
     and restrictions with respect to this document.  Code Components



  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 1]


  Internet-Draft       oauth-web-message-response-mode       November 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
     2.  Web Message Response Mode . . . . . . . . . . . . . . . . . .   4
       2.1.  Dynamic Discovery of Primary Window Reference . . . . . .   5
     3.  Popup-Based Authorization Flow Using the Web Message Response
             Mode  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Iframe-Based Authorization Flow Using the Web Message Response
             Mode  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Clickjacking Mitigations in Iframes . . . . . . . . . . .   8
       4.2.  User-Session in Iframes . . . . . . . . . . . . . . . . .   9
     5.  Authorization Server Metadata . . . . . . . . . . . . . . . .   9
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
       6.1.  Receiver Origin Validation  . . . . . . . . . . . . . . .   9
       6.2.  Initiator Origin Validation and Cross-Site Request Forgery
             Protection  . . . . . . . . . . . . . . . . . . . . . . .   9
       6.3.  Data Validation . . . . . . . . . . . . . . . . . . . . .  10
       6.4.  Cross-Site Leak Protections on the Authorization
             Server  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       6.5.  Redirection URI vs. Receiver Origin . . . . . . . . . . .  11
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
     9.  Informative References  . . . . . . . . . . . . . . . . . . .  12
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
     Appendix B.  Document History . . . . . . . . . . . . . . . . . .  13
     Appendix C.  Example Implementations  . . . . . . . . . . . . . .  13
     Appendix D.  Differences to I-D.sakimura-oauth-wmrm . . . . . . .  15
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Introduction

     OAuth [RFC6749] uses HTTP redirects to transfer authorization
     response parameters from the authorization server via the user-agent
     to the client's redirection endpoint.  In this case, the
     authorization response parameters are encoded in the query string
     (response_mode=query) or in the fragment (response_mode=fragment) of
     the redirect_uri [oauth.encoding] (Section 2.1).  [RFC6749]
     (Section 1.7) allows other mechanisms available via the user-agent to
     accomplish this redirection, such as response_mode=form_post
     [oauth.post].






  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 2]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     The standardized query, fragment, and form post response modes are
     designed for single-window authorization but not for multi-window
     authorization flows.  A common example is a popup-based authorization
     flow, where the client's primary window opens the authorization
     server in a secondary window.  The secondary window cannot use HTTP
     redirects to transfer response parameters back to the client in the
     primary window.

     This specification defines the web message response mode that uses
     the user-agent's postMessage API [whatwg.postmessage] to exchange
     messages between two different browser windows.  Clients inform the
     authorization server to use this response mode for returning the
     authorization response by setting the response_mode parameter in the
     authorization request to web_message.  This response mode facilitates
     popup-based and iframe-based authorization flows, in which the
     authorization server is called in a secondary window or embedded in a
     frame on the client.

     These flows that span the authorization process across two windows
     are especially useful for browser-based applications, where the main
     application window should remain uninterrupted to preserve the user
     experience.  Executing authorization flows in invisible iframes can
     also enable seamless session resumption and renewal without
     disrupting the user.

  1.1.  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 specification uses the terms "client", "user-agent",
     "authorization server", "authorization endpoint", "redirection
     endpoint", "redirection URI", "authorization request", and
     "authorization response" defined by the OAuth 2.0 Authorization
     Framework [RFC6749].  It further uses the term "response mode"
     defined by the OAuth 2.0 Multiple Response Type Encoding Practices
     [oauth.encoding].

     This specification defines the following additional terminology.

     primary window  This is the top-level browsing window that initially
        holds the client's website.  This window has no parent windows and
        it was not opened by any other window.
     secondary window  This is the window in which the client in the
        primary window opens the authorization server.



  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 3]


  Internet-Draft       oauth-web-message-response-mode       November 2025


  2.  Web Message Response Mode

     This specification defines the web message response mode, which is
     described with the following response_mode parameter value in the
     authorization request [oauth.encoding].

     web_message  In the web message response mode, the authorization
        server in the secondary window encodes the authorization response
        parameters in a JSON dictionary and transmits it via the user-
        agent's postMessage API to the client in the primary window.

     If the authorization request includes the value web_message for the
     response_mode parameter, the authorization server:

     *  MUST dynamically discover the client's primary window reference as
        described in Section 2.1.
     *  MUST use the user-agent's postMessage API to return the
        authorization response to the client's primary window.
     *  MUST encode the response paramters as key-value string pairs in a
        JSON dictionary.
     *  MUST follow [RFC6749] and [RFC9700] when validating the
        redirection URI.
     *  MUST use the full redirection URI (the exact same URI also used in
        other response modes such as query, fragment, or form post) as the
        postMessage's receiver origin.  The user-agent's postMessage API
        inherently parses the redirection URI and extracts its origin.
     *  MUST NOT parse the URI itself to reduce the attack surface
        concerning parsing issues.

     The client's redirection URI MUST serve as the postMessage's receiver
     origin to protect the authorization response from being leaked to
     malicious origins.

     This example illustrates how an authorization server (identified by
     the issuer https://as.example) in a secondary window returns the
     authorization response to the client (whose registered redirection
     URI is https://client.example/cb) in the primary window using the
     postMessage API:

     const primaryWindowRef = window.opener // for popup-based flow
     const primaryWindowRef = window.parent // for iframe-based flow
     const params = {
       "code": "XXXXXXXX",
       "state":"XXXXXXXX",
       "iss": "https://as.example"
     }
     primaryWindowRef.postMessage(params, "https://client.example/cb")




  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 4]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     The client MAY signal its preferred primary window reference by using
     the response_mode parameter.  For popup-based authorization flows, it
     MAY set the value to web_message.opener, and for iframe-based
     authorization flows, it MAY set the value to web_message.parent.
     When either web_message.opener or web_message.parent is specified,
     the authorization server MUST use the corresponding window reference
     window.opener or window.parent and MUST NOT attempt to dynamically
     determine the primary window reference as specified in Section 2.1.

  2.1.  Dynamic Discovery of Primary Window Reference

     If the authorization request specifies web_message as the
     response_mode, the authorization server running in the secondary
     window MUST dynamically determine the client's primary window
     reference.  This is done by checking whether the window.opener or
     window.parent references point to a valid primary window.  If both
     references are available, the window.opener reference MUST take
     precedence to ensure that popup-based authorization flows are
     prioritized over iframe-based flows.

     The following example illustrates how an authorization server may
     perform this discovery process:

     let primaryWindowRef = undefined
     if (window.opener !== null) // this is a popup-based flow
       primaryWindowRef = window.opener
     else if (window.parent !== self) // this is an iframe-based flow
       primaryWindowRef = window.parent
     else // abort flow: could not discover primary window reference

  3.  Popup-Based Authorization Flow Using the Web Message Response Mode

     In a popup-based authorization flow, the client opens the
     authorization endpoint in a secondary window.  The authorization
     server uses the user-agent's postMessage API to return the
     authorization response parameters from the secondary window back to
     the client running in the primary window.  The flow is depicted in
     Figure 1 and described in the following.













  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 5]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     +------------------------------+
     |        Primary Window        |
     |    (client.example/login)    |    +-----------------------+
     |                              |    |   Secondary Window    |
     |1) Register message event     |    |  (as.example/authz)   |
     |   handler                    |    |                       |
     |                              |    |3) Authenticate user   |
     |2) Open authz request with    |    |   and authorize       |
     |   web message response mode  |    |   access              |
     |   parameter in popup window  +--->|                       |
     |                              |    |4) Send postMessage    |
     |5) Validate and process authz |<---+   with authz response |
     |   response in event handler  |    |   to opener window    |
     |                              |    |                       |
     +------------------------------+    +-----------------------+

        Figure 1: Overview of a popup-based authorization flow using the
                           web message response mode.

     1.  The client registers a message event handler that receives the
         authorization response from the authorization server.  The client
         MUST validate the message's origin with an exact string matching
         the authorization server's origin.  As the authorization response
         is meant for one-time use, the client MUST remove the message
         event handler after receiving the authorization response to
         prevent any further authorization attempts.

     Example of the registration of a message event handler:

     const callback = (e) => {
       if (e.origin === "https://as.example") {
         // further validation and processing of the authorization response
         process(e.data)
         window.removeEventListener("message", callback)
       }
     }
     window.addEventListener("message", callback)

     2.  The client MUST open the authorization request in a secondary
         window.  Therefore, the client MAY use JavaScript and the user-
         agent's window.open API, MAY use an anchor HTML element with a
         target attribute, or MAY use any other mechanism suitable for
         opening secondary windows.  The authorization request MUST
         include the response_mode parameter value web_message or
         web_message.opener.  Additional authorization request parameters
         and techniques, such as PAR [RFC9126] and RAR [RFC9396], are
         unaffected by this specification and MAY be used with the web
         message response mode.



  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 6]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     Example of using the window.open API to open the authorization
     request in a secondary window:

     window.open(
       "https://as.example/auth?...&response_mode=web_message",
       "secondaryWindowRef",
       "left=100,top=100,width=320,height=320"
     )

     Example of using an anchor tag with a target attribute to open the
     authorization request in a secondary window:

     <a
       href="https://as.example/auth?...&response_mode=web_message"
       target="secondaryWindowRef"
     >

     3.  The authorization server receives the authorization request,
         validates its parameters, and proceeds with the end-user
         authentication and authorization, which is outside of the scope
         of this specification.

     4.  If the authorization request includes the response_mode parameter
         value web_message or web_message.opener, the authorization server
         MUST follow the web message response mode as described in
         Section 2 and use the user-agent's postMessage API to return the
         authorization response parameters from the secondary window to
         the secondary window's opener window.  The receiver window MUST
         be referenced by the secondary window's opener property.

     Example of an authorization server using the postMessage API in a
     secondary window to return the authorization response to the client
     in the primary window:

     const params = {
       "code": "XXXXXXXX",
       "state": "XXXXXXXX",
       "iss": "https://as.example"
     }
     window.opener.postMessage(params, "https://client.example/cb")

     5.  The client's message event handler receives the postMessage that
         contains the authorization response parameters.  The further
         processing and validation of all parameters is out of the scope
         of this specification and MUST be compliant to [RFC6749] and
         [RFC9700].





  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 7]


  Internet-Draft       oauth-web-message-response-mode       November 2025


  4.  Iframe-Based Authorization Flow Using the Web Message Response Mode

     In addition to secondary windows being popups, iframes can be used as
     well.  Iframes enable a seamless authorization flow where the end-
     user only sees a single browser tab, without ever leaving the actual
     client.  The client MAY explicitly request the iframe-based
     authorization flow by setting the response_mode parameter to
     web_message.parent.  The authorization flow proceeds in a manner
     technically similar to the popup-based flow described in Section 3,
     with the following modifications:

     *  In step 2, the client MUST embed the authorization request in an
        iframe instead of opening a popup window.
     *  In step 4, the secondary window MUST reference its parent window
        rather than its opener window.

     If user consent has already been granted, iframe-based authorization
     flows can enable seamless session resumption or renewal by embedding
     invisible iframes with the prompt parameter set to none [openid.core]
     (Section 3.1.2.1).  In this case, the client receives the
     authorization response directly, allowing the user session to resume
     without further interaction.  If the prompt parameter is set to none
     but no prior user authentication or consent exists, the authorization
     server MUST return an error as specified in [openid.core]
     (Section 3.1.2.1).  In this case, the client can fall back to a
     popup-based flow or to an iframe-based flow that displays a
     Clickjacking-protected user interface, as discussed in Section 4.1.

  4.1.  Clickjacking Mitigations in Iframes

     The authorization server MUST implement Clickjacking countermeasures
     according to [RFC9700] (Section 4.16) and protect its authorization
     endpoint and consent-page from being embedded in an iframe by origins
     not deemed trustworthy.

     If the user's browser supports the Intersection Observer v2 API
     [w3c.observerv2], the authorization server MAY use it to allow the
     client to embed the authorization endpoint and consent-page.  For
     example, the authorization server's script running in the embedded
     consent-page could pre-emptively load itself in a popup window if it
     detects the Intersection Observer v2 API's isVisible attribute being
     set to false, thus avoiding any occlusion of its content.









  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 8]


  Internet-Draft       oauth-web-message-response-mode       November 2025


  4.2.  User-Session in Iframes

     Modern browsers have started to disable the support for third-party
     cookies.  Thereby, iframes do not send authentication cookies along
     with requests in sub resource requests, such as iframes.  Using
     iframes as secondary windows therefore requires special exceptions to
     bypass this restriction, such as the Storage Access API
     [mozilla.storageaccessapi].

     This mechanism is unnecessary in first-party scenarios where the
     authorization server and client share the same origin.  In such
     cases, cookies are treated as first-party and remain included in
     requests made from iframes.

  5.  Authorization Server Metadata

     Authorization servers MUST announce their support for the web message
     response mode defined in Section 2 by adding web_message,
     web_message.opener, web_message.parent, or any combinations of these
     values to the response_modes_supported list in their authorization
     server metadata as specified in [RFC8414] (Section 2).  Authorization
     servers MAY declare exclusive support for a specific authorization
     flow by including either web_message.opener or web_message.parent in
     the response_modes_supported list.  If the response_modes_supported
     list contains the generic value web_message, the authorization server
     MUST support both the popup-based and the iframe-based authorization
     flows.

  6.  Security Considerations

  6.1.  Receiver Origin Validation

     Authorization servers MUST follow Section 2 and [RFC9700]
     (Section 4.17.2) when validating the postMessage receiver origin.
     Otherwise, the authorization response may leak to an attacker, as
     described in [RFC9700] (Section 4.17.1.1) and [RFC9700]
     (Section 4.17.1.2).

  6.2.  Initiator Origin Validation and Cross-Site Request Forgery
        Protection

     In redirect-based authorization flows, there is no inherent mechanism
     available that enables a client to verify that the trusted
     authorization server initiates a redirection.  Instead, [RFC6749]
     introduces the state parameter to counter so-called Cross-Site
     Request Forgery (CSRF) attacks [RFC9700] (Section 4.7) against the
     client's redirection endpoint by maintaining a state between the
     authorization request and response.



  Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 9]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     The postMessage API provides an inherent mechanism to verify the
     initiator of a postMessage.  The client MUST use this mechanism as
     described in Section 2 and [RFC9700] (Section 4.17.2) to verify that
     the trusted authorization server is the initiator of the postMessage.
     Otherwise, an attacker can inject a maliciously crafted authorization
     response to the client [RFC9700] (Section 4.17.1.3).  This
     verification prevents some variants of CSRF attacks, where the
     attacker wants to log in a victim to the attacker's account.

     However, attackers can also use CSRF attacks to log in a victim to
     the victim's own account.  This attack variant cannot be mitigated
     with the checks mentioned above.  Instead, a proper CSRF
     countermeasure, as described in [RFC9700] (Section 4.7.1) MUST be
     used.

  6.3.  Data Validation

     Even after the initiator origin of the postMessage is validated, the
     client MUST check that the postMessage has the expected format
     [whatwg.postmessage] (Section 9.3.2.1).  In particular, the
     postMessage MUST NOT be processed in unsafe JavaScript sinks like
     eval or innerHTML to prevent cross-site scripting (XSS) flaws and
     other potentially malicious injections.  Otherwise, if the
     authorization server has been attacked using an XSS flaw, further
     unchecked processing of the postMessage could result in the attack
     being propagated into the client.

  6.4.  Cross-Site Leak Protections on the Authorization Server

     The authorization server is opened in a secondary window that needs
     access to its opener window via its opener property to send
     postMessages to that referenced window.  Thus, the authorization
     server cannot use cross-site leak protections like the cross-origin
     opener policy [whatwg.coop] to force the creation of a new top-level
     browsing context and cross-origin isolate their sites.

     However, browsers are working on preventing cross-site leaks without
     breaking the popup-based authorization flows with the restrict-
     properties directive being added to the cross-origin opener policy
     [google.restrictprops].  With this directive, properties that can be
     used for cross-site leaks are not available but postMessage
     communication between cross-origin windows is still allowed.
     Authorization servers MAY set the Cross-Origin-Opener-Policy:
     restrict-properties header to protect against cross-site leaks.







  Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 10]


  Internet-Draft       oauth-web-message-response-mode       November 2025


  6.5.  Redirection URI vs. Receiver Origin

     In redirect-based authorization flows, the confidentiality of the
     authorization response is scoped to the redirection URI that contains
     a path.  The path separates the authorization response from other,
     potentially vulnerable paths within the same web application.  In
     flows using the web message response mode, the confidentiality of the
     authorization response is scoped to the postMessage's receiver origin
     that does not contain a path.  Thus, cross-site scripting (XSS)
     vulnerabilities on _any_ path within the web application's origin
     will leak the authorization response to the attacker.

  7.  IANA Considerations

     This draft makes no requests to IANA.

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

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

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

     [RFC9700]  Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
                "Best Current Practice for OAuth 2.0 Security", BCP 240,
                RFC 9700, DOI 10.17487/RFC9700, January 2025,
                <https://www.rfc-editor.org/info/rfc9700>.

     [oauth.encoding]
                de Medeiros, B., Scurtescu, M., Tarjan, P., and M. Jones,
                "OAuth 2.0 Multiple Response Type Encoding Practices",
                February 2014, <https://openid.net/specs/oauth-v2-
                multiple-response-types-1_0.html>.





  Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 11]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     [whatwg.postmessage]
                "HTML Living Standard: Cross-document messaging",
                <https://html.spec.whatwg.org/multipage/web-
                messaging.html#web-messaging>.

  9.  Informative References

     [I-D.sakimura-oauth-wmrm]
                Yamaguchi, T., Sakimura, N., and N. Matake, "OAuth 2.0 Web
                Message Response Mode", Work in Progress, Internet-Draft,
                draft-sakimura-oauth-wmrm-01, 8 November 2023,
                <https://datatracker.ietf.org/doc/html/draft-sakimura-
                oauth-wmrm-01>.

     [RFC9126]  Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
                and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
                RFC 9126, DOI 10.17487/RFC9126, September 2021,
                <https://www.rfc-editor.org/info/rfc9126>.

     [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
                Rich Authorization Requests", RFC 9396,
                DOI 10.17487/RFC9396, May 2023,
                <https://www.rfc-editor.org/info/rfc9396>.

     [google.restrictprops]
                and , "Secure popup interactions with restrict-
                properties", 9 August 2023,
                <https://developer.chrome.com/blog/coop-restrict-
                properties/>.

     [mozilla.storageaccessapi]
                "Storage Access API", 18 October 2023,
                <https://developer.mozilla.org/en-US/docs/Web/API/
                Storage_Access_API>.

     [oauth.post]
                Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
                Mode", 27 April 2015, <http://openid.net/specs/oauth-v2-
                form-post-response-mode-1_0.html>.

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






  Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 12]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     [w3c.observerv2]
                and , "Intersection Observer", 4 November 2019,
                <https://w3c.github.io/IntersectionObserver/>.

     [whatwg.coop]
                "HTML Living Standard: Cross-origin opener policies",
                <https://html.spec.whatwg.org/multipage/
                browsers.html#cross-origin-opener-policies>.

  Appendix A.  Acknowledgements

     We would like to acknowledge the prior work of Toru Yamaguchi, Nat
     Sakimura, and Nov Matake in [I-D.sakimura-oauth-wmrm] which tried to
     define a response mode with similarities to this specification.  In
     contrast, this specification is not focused on iframes and does not
     include the use of the OAuth Implicit Grant.

     We would like to thank Vladislav Mladenov, ...

     for their valuable feedback on this document.

  Appendix B.  Document History

     [[ To be removed from the final specification ]]

     -01 * Add use cases of popup and iframe flows * Enhance and clarify
     descriptions and mitigations for iframe flow * Clarify iframe use for
     first-party context and invisible iframes for reauthentication flows
     with prompt none * Add dynamic discovery of primary window reference
     and new values for response_mode: web_message.opener and
     web_message.parent * Add notes about how this draft differs from
     Sakimura et al. * Add several example implementations of the web
     message response mode and popup- or iframe-based flows * Minor
     improvements of style and language * Update references to newer
     versions

     -00 * Initial draft

  Appendix C.  Example Implementations

     [[ To be removed from the final specification ]]

     Although neither the web_message response mode nor the popup- and
     iframe-based authorization flows have been officially standardized,
     they are already widely supported in practice.  A study
     (https://dl.acm.org/doi/10.1145/3548606.3560692) from late 2022 found
     that 153 of the Tranco Top 1k websites opened the authorization
     server in a secondary window, compared to only 134 websites that



  Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 13]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     navigated the primary window to the authorization server.  More
     recently, a scan of all domains in the CrUX dataset (July 2025)
     revealed 22 authorization servers (https://github.com/Hackmanit/
     draft-meyerzuselha-oauth-web-message-response-mode/issues/27) that
     publish the still-undefined web_message value in the
     response_modes_supported list of their OpenID Provider Metadata
     (https://openid.net/specs/openid-connect-discovery-1_0.html) at
     /.well-known/openid-configuration.  In addition, several
     authorization servers support popup- or iframe-based flows without
     explicitly announcing them in their metadata:

     *  Apple supports the popup-based flow with response_mode=web_message
        through its custom JS SDK.  The flow is activated if the client
        enables the SDK's popup mode via a meta tag
        (https://developer.apple.com/documentation/signinwithapple/
        configuring-your-webpage-for-sign-in-with-apple).  Apple's REST
        API documentation
        (https://developer.apple.com/documentation/signinwithapplerestapi/
        request-an-authorization-to-the-sign-in-with-apple-server) does
        not mention web_message as a valid response_mode, although the SDK
        uses it when configured.

     *  Google supports both the popup-based
        (https://developers.google.com/identity/gsi/web/guides/
        integrate#pop-up_versus_redirect) (default) and iframe-based
        (https://developers.google.com/identity/gsi/web/amp/intermediate-
        iframe) flows within its Google Identity Services SDKs
        (https://developers.google.com/identity/gsi/web/guides/overview).
        However, these flows are not available in its interoperable OAuth
        and OpenID Connect endpoints
        (https://developers.google.com/identity/protocols/oauth2/web-
        server).

     *  Facebook supports the popup-based flow through its JS SDK
        (https://developers.facebook.com/docs/facebook-login/web).  It
        always includes the xd_arbiter endpoint as a parameter to the
        authorization endpoint, e.g.,
        channel_url=https://staticxx.facebook.com/x/connect/xd_arbiter.

     *  Auth0 officially documents support for the web_message response
        mode in its API documentation
        (https://auth0.com/docs/authenticate/protocols/oauth).  It
        references the expired draft [I-D.sakimura-oauth-wmrm] from 2015
        and uses it for silent authentication with HTML5 web messaging.

     *  Nintendo uses the web_message response mode internally, following
        the expired draft [I-D.sakimura-oauth-wmrm].  It also relies on
        the additional web_message_uri and web_message_target parameters.



  Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 14]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     Beyond these providers, other authorization servers also employ
     web_message or proprietary variants of popup- and iframe-based flows.
     Apple, Google, and Facebook even make multi-window flows the default
     within their SDKs, highlighting their practical importance.  Yet, the
     absence of an interoperable, standards-based mechanism for clients to
     use these flows underscores the need for formal standardization.

  Appendix D.  Differences to [I-D.sakimura-oauth-wmrm]

     [[ To be removed from the final specification ]]

     This draft builds on the earlier work of Toru Yamaguchi, Nat
     Sakimura, and Nov Matake in [I-D.sakimura-oauth-wmrm], which
     introduced a web message response mode.  While sharing several
     conceptual similarities, this draft differs in the following ways:

     *  *Flow illustrations:* [I-D.sakimura-oauth-wmrm] illustrates only
        the deprecated implicit flow (response_type=token).  This draft is
        flow-agnostic and uses the authorization code flow
        (response_type=code) in its examples.

     *  *Primary window reference:* [I-D.sakimura-oauth-wmrm] does not
        specify how the authorization server should obtain a reference to
        the client's primary window.  This draft allows the authorization
        server to either dynamically discover the reference or rely on
        client-provided hints via the web_message.opener and
        web_message.parent response modes.

     *  *Relay mode:* [I-D.sakimura-oauth-wmrm] defines a relay mode in
        which the authorization response is forwarded through the client
        to a third window (the "message target window").  This draft does
        not support tertiary windows and instead limits the exchange to
        the client's primary window and the authorization server's
        secondary window.  This draft omits relay mode due to lack of
        practical demand.

     *  *Browser compatibility:* [I-D.sakimura-oauth-wmrm] uses JavaScript
        constructs that no longer work in modern browsers (e.g.,
        window.opener != window and cross-origin DOM access via
        evt.source.document.getElementById).  These break relay mode
        entirely, as the secondary window cannot obtain a reference to the
        message target window.

     *  *Parameters:* [I-D.sakimura-oauth-wmrm] introduces the
        web_message_uri (target URI) and web_message_target (DOM id)
        parameters, both tied to relay mode.  This draft omits these
        parameters and instead relies solely on the established
        redirect_uri.



  Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 15]


  Internet-Draft       oauth-web-message-response-mode       November 2025


     *  *Message format:* [I-D.sakimura-oauth-wmrm] defines postMessage
        data as an object with fields type (string) and response (object).
        This draft simplifies the structure to a single object containing
        all authorization response parameters, since only one postMessage
        is used.

     *  *Iframe restrictions:* [I-D.sakimura-oauth-wmrm] restricts iframe-
        based flows to already-authenticated sessions with prior consent
        ("authenticated windows").  This draft permits iframe-based flows
        in unauthenticated states as well, relying on Clickjacking
        mitigations (e.g., the Intersection Observer v2 API).

     *  *Security considerations:* This draft provides extended guidance
        on secure use of postMessage, Clickjacking mitigations, and
        implications of browsers phasing out third-party cookies.

  Authors' Addresses

     Karsten Meyer zu Selhausen
     Hackmanit
     Email: karsten.meyerzuselhausen@hackmanit.de


     Louis Jannett
     Ruhr University Bochum
     Email: louis.jannett@rub.de


     Christian Mainka
     Hackmanit
     Email: christian.mainka@hackmanit.de




















  Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 16]


