# drafts

name: draft-xie-ai-agent-multimodal
rev: 00
title: Multimodal Management Requirements for AI Agent Protocols
time: 2026-01-09T07:09:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T19:58:17Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent-to-agent communication protocols", "Data formats / semantics for AI interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420380+00:00
abstract:
This document specifies the Multimodal requirements for Agent-to-
   Agent Protocol, which enables autonomous agents to establish multi-
   channel communication sessions, negotiate heterogeneous data
   capabilities (e.g., text, file, real-time audio/video streams, sensor
   streams), and exchange synchronized multimodal content with adaptive
   QoS policies.

full_text:
Network Working Group                                             G. Xie
Internet-Draft                                                     Y. Li
Intended status: Informational                                 CNIC, CAS
Expires: 8 January 2026                                      7 July 2025


       Multimodal Management Requirements for AI Agent Protocols
                    draft-xie-ai-agent-multimodal-00

Abstract

   This document specifies the Multimodal requirements for Agent-to-
   Agent Protocol, which enables autonomous agents to establish multi-
   channel communication sessions, negotiate heterogeneous data
   capabilities (e.g., text, file, real-time audio/video streams, sensor
   streams), and exchange synchronized multimodal content with adaptive
   QoS policies.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 8 January 2026.

Copyright Notice

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

   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.



Xie & Li                 Expires 8 January 2026                 [Page 1]

Internet-Draft            Agent Task Management                July 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Necessity . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Protocol Requirements . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Multimodal Media Channel Establishment (Signaling)  . . .   3
     4.2.  Multimodal Media Transmission (Media Handling)  . . . . .   4
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

1.1.  Purpose

   This document articulates the technical imperative for multimodal
   interaction to be natively supported in the protocols defining and
   standardizing interoperability among Artificial Intelligence Agents
   (AI Agents).  The core rationale stems from the evolution of modern
   Large Language Models (LLMs) into Multimodal Models capable of
   processing, generating, and understanding multiple media types.
   Consequently, establishing multimodal channels to transmit multimodal
   media must be supported.

1.2.  Terminology

   Multimodal:
      Multimodal is a technology that integrates two or more different
      types of information modes (such as visual, text, and speech) to
      improve data processing and task execution capabilities.  Its core
      lies in imitating the cognitive style of human multi-sensory
      collaboration, and enhancing the integrity and interactive
      experience of information by fusing data of different modes.

2.  Use Cases

   A typical use case in agent-agent communication using multimodal
   media:

   A Housekeeping Robot Agent sends a task to a Monitoring Robot Agent
   to detect the incidents.  The two Agents negotiate the necessary
   multimodal media channels and establish the session.  Once the



Xie & Li                 Expires 8 January 2026                 [Page 2]

Internet-Draft            Agent Task Management                July 2025


   Monitoring Robot Agent detects a glass-breaking incident in the
   kitchen, it transmits audio and video stream to the Housekeeping
   Robot Agent, simultaneously it generates and sends a text alert
   ("CRITICAL: Glass break at 2025-10-05T14:30:15Z") to the Housekeeping
   Robot Agent through the established multimodal session.

3.  Necessity

   With the rapid development of LLMs (large language models)
   technologies, LLMs have gradually developed from supporting single
   modal such as text to supporting multiple modals such as text,
   pictures, and video clips and their combinations.  In particular,
   LLMs supporting real-time audio and video streams have emerged
   recently.  The capabilities of LLMs are increasingly rich and
   perfect.

   Agent often needs to understand multiple modal data, such as
   environment data, context data, audio, video, etc., to better
   understand and execute tasks.  Therefore, various multimodal data
   needs to be transmitted between Agents.

   Multimodal interaction capabilities supported by mainstream Agent
   communication protocols in the industry are shown as follows:

   *  A2A protocol [A2A]: Support TextPart, DataPart and FilePart
      carried by the part parameters in tasks/send or tasks/subscribe
      message.  Only simple text, file, and data formats are supported.

   *  ANP protocol [ANP]: Only natural language (e.g., YAML and JSON-RPC
      format) which defined in Agent Description is supported.

   *  Agntcy protocol [Agntcy]: Only data with JSON format is supported.

   Therefore, the general Agent communication protocol should support
   rich multimodal interaction including text, file, real-time audio/
   video stream, etc.

4.  Protocol Requirements

4.1.  Multimodal Media Channel Establishment (Signaling)

   *  Multimodal Media Negotiation

   When agents need to transmit multimodal media, especially real-time
   audio and video streams, a dedicated media channel is required to
   transmit these streams.  Meanwhile, the audio and video codecs
   supported by different agents may be vary.  Therefore, the audio and
   video codecs MUST be negotiated between agents before transmission.



Xie & Li                 Expires 8 January 2026                 [Page 3]

Internet-Draft            Agent Task Management                July 2025


4.2.  Multimodal Media Transmission (Media Handling)

   *  Multi-stream Multiplexing

   There are many types of multimodal data.  The transmission
   requirements of different multimodal data are varied, which requires
   transmission using different stream.

   To reduce IP port resource overhead caused by flow connections, a
   multi-stream multiplexing capability needs to be supported, and
   different transmission priorities can be set for different flows.

   *  Multimodal Synchronization and Collaboration

   In some use cases, multimodal data transmitted between agents needs
   to be synchronized.  As shown in the example use case, when the
   housekeeping robot Agent arranges the monitoring robot Agent to
   perform environment monitoring, the audio stream, video stream, and
   text events collected by the monitoring robot Agent need to be
   synchronized to help the housekeeping robot better understand the
   monitoring result.

   In other use cases, multimodal data may need to coordinate
   transmission policies.  For example, when audio and video streams are
   transmitted at the same time, when video frame freezing occurs due to
   a decrease in connection bandwidth, the video resolution and bitrate
   need to be automatically reduced to ensure audio stream transmission
   quality.

5.  Conclusions

   Multimodal interaction constitutes a critical function for multi-
   agent collaboration.  This document discusses the necessity of
   introducing multimodal interaction to address Agent collaboration.
   Consequently, it analyzes the requirements imposed by multimodal
   interaction on AI Agent protocol design, specifically concerning
   multimodal media channel establishment and multimodal media
   transmission.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   This document should not affect the security of the Internet.

8.  References



Xie & Li                 Expires 8 January 2026                 [Page 4]

Internet-Draft            Agent Task Management                July 2025


8.1.  Informative References

   [A2A]      Google LLC, "Agent2Agent (A2A) Protocol Specifications",
              2025, <https://github.com/a2aproject/A2A/blob/main/
              specification>.

   [ANP]      ANP community, "AgentNetworkProtocol(ANP)", 2025,
              <https://github.com/agent-network-
              protocol/AgentNetworkProtocol/tree/main>.

   [Agntcy]   IoA community, "Agent Connect Protocol Specification",
              2025, <https://github.com/agntcy/acp-spec/tree/main>.

Authors' Addresses

   Gaogang Xie
   CNIC, CAS
   Beijing
   100083
   China
   Email: xie@cnic.cn


   Yanbiao Li
   CNIC, CAS
   Beijing
   100083
   China
   Email: lybmath@cnic.cn






















Xie & Li                 Expires 8 January 2026                 [Page 5]


name: draft-hw-ai-agent-6g
rev: 00
title: Requirements and Enabling Technologies of Agent Protocols for 6G Networks
time: 2026-01-21T07:09:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-21T03:42:03Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420383+00:00
abstract:
Agent application will be surely the common trend for a long time in
   future, while agent protocols are so popular that more and more
   protocols are being worked out.  The telecommunication industry plays
   a pivotal role in the Agent ecosystem.  The overall technology
   success hinges on how telecommunication industry could adopt the
   latest AI trends in order to handle its specific usage scenarios and
   performance requirements, e.g., in the coming 6G era.  This document
   will provide the first attempt to analyze the agent protocol
   requirements and relevant enabling technologies based on mobile
   communication system specific characteristics.

full_text:
Network Working Group                                     Chenchen Yang,
Internet-Draft                                           Huanhuan Huang,
Intended status: Standards Track                      Arashmid Akhavain,
Expires: 21 January 2026                                       Faye Liu,
                                                               Xueli An,
                                                            Weijun Xing,
                                                                  Huawei
                                                              Jinyan Li,
                                                             Aijun Wang,
                                                           China Telecom
                                                           Wencong Yang,
                                                            China Unicom
                                                            20 July 2025


    Requirements and Enabling Technologies of Agent Protocols for 6G
                                Networks
                        draft-hw-ai-agent-6g-00

Abstract

   Agent application will be surely the common trend for a long time in
   future, while agent protocols are so popular that more and more
   protocols are being worked out.  The telecommunication industry plays
   a pivotal role in the Agent ecosystem.  The overall technology
   success hinges on how telecommunication industry could adopt the
   latest AI trends in order to handle its specific usage scenarios and
   performance requirements, e.g., in the coming 6G era.  This document
   will provide the first attempt to analyze the agent protocol
   requirements and relevant enabling technologies based on mobile
   communication system specific characteristics.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 21 January 2026.



Chenchen Yang,, et al.   Expires 21 January 2026                [Page 1]

Internet-Draft                 Short Title                     July 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Characteristics of Mobile Network . . . . . . . . . . . . . .   4
     2.1.  Resource dynamicity . . . . . . . . . . . . . . . . . . .   4
     2.2.  Guaranteed Quality of Service (QoS) . . . . . . . . . . .   4
     2.3.  Mobility  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Multi-domain Interoperation . . . . . . . . . . . . . . .   5
     2.5.  Security, Privacy and Trust . . . . . . . . . . . . . . .   5
     2.6.  Session-level Operation . . . . . . . . . . . . . . . . .   6
     2.7.  Systems Coexistence . . . . . . . . . . . . . . . . . . .   6
   3.  Agent Protocols Requirements  . . . . . . . . . . . . . . . .   6
     3.1.  Multi-agent system covering terminal, network and
            service  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  QoS Assurance for Multi-agent Communication . . . . . . .   7
       3.2.1.  Agent traffic may consist of multiple “Parts” and
               multi-modal data： . . . . . . . . . . . . . . . . . .   7
       3.2.2.  Heterogeneous QoS requirements among multiple
               “Parts”：  . . . . . . . . . . . . . . . . . . . . . .   7
       3.2.3.  Burst Agent traffic . . . . . . . . . . . . . . . . .   7
     3.3.  Agent Service Continuity  . . . . . . . . . . . . . . . .   8
     3.4.  Agent Task-Oriented Resource Management . . . . . . . . .   8
     3.5.  Intent-based Interaction  . . . . . . . . . . . . . . . .   9
     3.6.  Security, Privacy and Trust . . . . . . . . . . . . . . .   9
     3.7.  Agent Governance  . . . . . . . . . . . . . . . . . . . .   9
     3.8.  Backward Compatibility and Forward Compatible . . . . . .  10
     3.9.  Extensibility . . . . . . . . . . . . . . . . . . . . . .  10
     3.10. Isolation . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.11. Tool Invocation . . . . . . . . . . . . . . . . . . . . .  11
     3.12. Knowledge Retrieval . . . . . . . . . . . . . . . . . . .  11
   4.  Enabling Protocol Technologies  . . . . . . . . . . . . . . .  11
     4.1.  Agent Governance Layer  . . . . . . . . . . . . . . . . .  12
       4.1.1.  Registration and Discovery  . . . . . . . . . . . . .  12



Chenchen Yang,, et al.   Expires 21 January 2026                [Page 2]

Internet-Draft                 Short Title                     July 2025


       4.1.2.  Publish and Subscribe . . . . . . . . . . . . . . . .  12
       4.1.3.  Agent Communication . . . . . . . . . . . . . . . . .  12
       4.1.4.  Multimodal Data Management  . . . . . . . . . . . . .  13
     4.2.  Meta Protocol Layer . . . . . . . . . . . . . . . . . . .  15
     4.3.  Security, Privacy and Trust Layer . . . . . . . . . . . .  15
     4.4.  Transport Layer . . . . . . . . . . . . . . . . . . . . .  16
   5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   6.  Reference . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Informative References  . . . . . . . . . . . . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   9.  Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   6G as the next generation mobile communication technology will play
   an essential role in the entire society digitalization process.  On
   one hand, 6G will provide better connectivity compared to 5G, and on
   the other hand, 6G will go beyond connectivity, for instance,
   features like native-AI and integrated communication and sensing will
   enable new business revenues.  It could be expected that enormous
   amount of new use cases and services could be enabled by 6G.
   However, increased new features as well as increased demands of
   various use case scenarios will also bring challenges on 6G system
   design.  For instance, how to enrich Telco scope services but remain
   operationally efficient?  How to provide per user network
   customization without scaling up the service provisioning complexity?
   How to speed up new service delivery and identify relevant
   standardization requirement to ensure interoperability?

   Carrying these questions in mind, 6G is seeking answers by utilizing
   promising technologies like agentic AI (empowered by foundation
   model), which gained a lot of attention in recent years.  Agentic AI
   technology is rapidly evolving as businesses embrace autonomous
   systems to streamline operations, enhance decision-making, and
   personalize/customized user experiences.  Therefore, agentic AI could
   become the essential cornerstone of 6G [1].  Such technology trend is
   quickly adopted by telecommunication field, for instance, ETSI and
   3GPP have launched relevant studies in this scope.  ETSI outlined its
   vision of AI Agent based Core network in [2] and provided a detailed
   study on use cases and requirements in [3]. 3GPP studied agent
   services in 3GPP R20 SA1 [4].  Moreover, the work task#3 on AI and
   agent has been adopted in 3GPP SA2 6G SID [5].






Chenchen Yang,, et al.   Expires 21 January 2026                [Page 3]

Internet-Draft                 Short Title                     July 2025


1.1.  Requirements Language

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

2.  Characteristics of Mobile Network

2.1.  Resource dynamicity

   Mobile networks provide wireless connectivity services in a dynamic
   environment with resource volatility and link unreliability.  To
   deliver high-quality connectivity services, networks utilize adaptive
   mechanisms such as real-time resource scheduling, multipath
   transmission, and dynamic retransmission schemes to mitigate the
   uncertainty of radio resources and links.  Unlike fixed networks with
   static infrastructure, mobile systems must continuously calibrate
   resource allocation to maintain link quality and ensure resilience
   while sustaining service continuity for diverse applications.

2.2.  Guaranteed Quality of Service (QoS)

   Guaranteed QoS is a fundamental design principle in mobile networks,
   enabling customized performance to meet heterogeneous application
   demands.  By establishing differentiated resource priorities,
   networks enforce strict guarantees:ultra-reliable low-latency
   transmission for critical industrial data transmission, prioritized
   bandwidth allocation for real-time services (e.g., voice calls, video
   conferencing), and flexible throughput for non-urgent traffic (e.g.,
   email, file downloads).  Such differentiation is also extending to
   multi-modal services, e.g., XR service and digital twins, enabling
   consistent performance across use cases and empowering mobile
   networks as unified platforms for diverse digital services.

2.3.  Mobility

   Mobility management, a core feature of mobile networks, enables
   continuous connectivity as terminals move across different locations.
   Networks trigger seamless handover based on the radio conditions to
   maintain communication without interruptions.  Sometimes network
   could allocate resources in advance by prediction to reduce latency
   during transitions.  This comprehensive mobility management framework
   supports various usage scenarios, from stationary to high-speed
   mobility and cross-regional roaming, making mobile networks essential
   for critical applications that require constant access.




Chenchen Yang,, et al.   Expires 21 January 2026                [Page 4]

Internet-Draft                 Short Title                     July 2025


2.4.  Multi-domain Interoperation

   Mobile communication network is multi-technology and multi-business
   domain in nature and it is important to establish a cohesive
   connectivity ecosystem for different network operators, network
   tenants and service providers.  From the technology perspective,
   inter-operator roaming leverages standardized protocols to empower
   subscribers to access partner networks, ensuring seamless global
   connectivity.  Even within the same Mobile Network Operator (MNO)
   environment, different network tenants can share the network under
   the control of the MNO to achieve a better service performance
   especially for 6G new services like sensing, AI and computing.  On
   the other hand, cross-domain collaboration supports mobile
   communication network and Over-The-Top (OTT) service providers to
   exchange capabilities via capability exposure to provide better
   services for end users.  This interoperability not only enhances
   resource utilization but also unlocks novel use cases, facilitating
   the development of a unified, scalable network infrastructure that
   supports diverse applications.

2.5.  Security, Privacy and Trust

   The security capabilities of each generation are continuously
   improving.  The security architecture defines security domains, end-
   to-end security mechanism, roaming security, and backward compatible
   security measure.  Achieving a balance between security and service
   performance is the principle for security capability design.
   Supporting multiple security mechanisms and being able to switch
   between them is essential.

   Privacy preservation can be achieved by encryption, anonymization,
   zero-knowledge proofs, privacy computing, etc.  The network provides
   users with privacy protection based on the data lifecycle.

   In terms of trust, the centralized trust model and the 3rd party
   endorsement model co-exist alongside with the multi-lateral trust
   model.  The first two trust models provide single-point trust.  The
   latter multi-lateral trust model offers multiple roots of trust/
   consensus trust, which facilities the fast establishment of cross-
   trust domain connections.











Chenchen Yang,, et al.   Expires 21 January 2026                [Page 5]

Internet-Draft                 Short Title                     July 2025


2.6.  Session-level Operation

   In conventional mobile communication network design, PDU session
   serves as the fundamental granularity for connectivity service
   management.  Through session management, mobile networks perform
   resource allocation and policy enforcement at the QoS Flow level,
   where individual service flows (e.g., video calls, IoT telemetry, or
   cloud gaming streams) are mapped to dedicated QoS flows with specific
   performance characteristics.  Session management systems continuously
   monitor Key Performance Indicators (KPIs) such as data rate, latency,
   and packet loss ratio, enabling dynamic resource adjustment to
   maintain connectivity service performance.  This session-level
   operation effectively bridges end-user QoS requirements with network
   resource optimization, making it a key part of network design.

2.7.  Systems Coexistence

   In the actual deployed commercial networks, systems based on legacy
   and state of the art standards operate concurrently due to gradual
   deployment cycles, varying terminal lifespans, and global differences
   in upgrade timelines.  For example, in some regions, 4G and 5G
   networks are operated alongside even older 3G systems.  Even within a
   single generation, almost every 1 or 2 years, a new release is
   published and some features are updated accordingly.  The coexistence
   of systems from different generations and releases presents
   challenges especially considering the backward and forward
   compatibility.

3.  Agent Protocols Requirements

3.1.  Multi-agent system covering terminal, network and service

   As proposed by ETSI [2], agentic AI technology could innovate the
   mobile communication network architecture design, and 6G core network
   could be established as a multi-agent system.  There will be a broad
   scope of agents, for instance 3GPP specified agents versus non-3GPP
   agents, network agents versus UE agents, etc.  These agents interact
   and collaborate with each other to form a new communication paradigm,
   and they could invoke different types of resources to support the
   communication.  Such resource could be for instance toolbox, memory,
   connectivity resource, computing resource, etc.  Under this context,
   6G goes hand in hand with agentic AI technologies. 6G may utilize
   agent protocols and relevant enabling technologies to enable the
   following mobile network specific scenarios:

   1.  *6G network agents interaction:* 6G network internal agents
       collaborate with each other, and invoke relevant resources;




Chenchen Yang,, et al.   Expires 21 January 2026                [Page 6]

Internet-Draft                 Short Title                     July 2025


   2.  *UE agent/resource and network agent/resource:* 6G network agent
       and UE agent collaborate with each other, 6G network agent
       invokes resources on UE side, or vice versa;

   3.  *Service exposure:* Expose 6G network agent services and
       resources to 3rd parties;

   4.  *Service consumption:* Consuming agent services and resources
       from 3rd parties.

3.2.  QoS Assurance for Multi-agent Communication

   Agent traffic as the following characteristics:

3.2.1.  Agent traffic may consist of multiple “Parts” and multi-modal
        data：

   Multi-agent communication traffic can contain several “Parts” (e.g.,
   the smallest unit of content within a Message or Artifact [6]).  The
   data types of different Parts may be different and multi-modal (e.g.,
   text, file, document, image, structured data, real-time audio stream,
   video streaming).

   The sizes of different Parts can be different and the transmission
   modes may be also different (e.g., real-time steaming, Server-Sent
   Events (SSE), or Push Notification).

   Given these traffic characteristics above, dedicated QoS framework
   should be designed for better performance.

3.2.2.  Heterogeneous QoS requirements among multiple “Parts”：

   Heterogeneity between Messages and Artifacts: An agent service flow
   may contain Messages and/or Artifacts, their QoS requirements are
   different, e.g., the Message’s requirement (e.g., timeliness,
   accuracy, delay) is stricter.

   Heterogeneity for “Parts” within a same Message or Artifact: The QoS
   requirement (e.g., delay, deadline to be sent to peer endpoint) for
   the different Parts of a same Message or Artifact may be the same or
   not.

3.2.3.  Burst Agent traffic

   Agent service flow can be burst traffic: dynamic QoS should be
   guaranteed and network resources should be adjusted in real-time when
   the agent service flow is burst traffic instead of periodic traffic.




Chenchen Yang,, et al.   Expires 21 January 2026                [Page 7]

Internet-Draft                 Short Title                     July 2025


   The characteristics of agent traffic above provides possibilities to
   optimize QoS schemes and resource scheduling.  The overall QoS of an
   agent service flow should be guaranteed while the network resource
   consumption is minimized.  Parts with different QoS requirements may
   be sent via different resources.  For example, network resource
   allocated to Parts of SSE/Streaming mode should keep active all the
   time, but network resource allocated to Parts of Push Notification
   mode can be (de)activated (e.g., released or suspended) flexibly.
   The 6G network can adjust the resource scheduling and management
   mechanism based on the different modes.

3.3.  Agent Service Continuity

   The continuity of agent service (e.g., message or task processing
   result) should be guaranteed, e.g., in the mobility scenario for UE-
   agent, or when the network addressing are changed.  Additional
   singling overhead for link (re)establishment and connectivity
   disruption possibilities should be reduced.  For instance, how to
   wake up the equipment that hosts the agent.  Agent instances can be
   deleted or moved from one device to the other.  Mobility handling in
   such situations need to be carefully tackled.  In addition, assume
   that we have an agent on equipment that is currently running a task.
   In the middle of the task, the equipment shuts down, but before it
   does, the agent should be moved (sent) to another hosting equipment.
   How to handle this situation and how the agent is notified?

3.4.  Agent Task-Oriented Resource Management

   The interaction between agents is typically task-oriented, where task
   is a collection of actions to satisfy the user requirements.  An
   agent (i.e. agent client) may request another agent (i.e. agent
   server) to perform a task [6].  It can query the task status during
   the execution process and receive the results upon task completion.

   As described in section 2.6, the mobile network operates based on
   sessions.  The traditional mobile network mainly performs
   communication resource management to establish the UE-oriented
   sessions and guarantee the QoS of a connectivity for a UE.  However,
   in an agentic system where multiple agents may collaborate to perform
   a task, the network shall manage and schedule multi-dimensional
   resources (such as communication resource, AI resource, computing
   resource, data resource, etc.) to guarantee the QoS of a task.

   Thus, a task session is required to support the communication of
   different agents in network.  And the network schedules resource and
   guarantees QoS based on task granularity.  Task information, e.g.,
   task identifier, needs to be carried when Agents exchanges message or
   task results, to associate with the corresponding task.



Chenchen Yang,, et al.   Expires 21 January 2026                [Page 8]

Internet-Draft                 Short Title                     July 2025


3.5.  Intent-based Interaction

   AI Agent is an automated intelligent entity capable of reasoning,
   decision-making, executing tasks autonomously to achieve a specific
   goal.  A consumer provides the high-level goal description that needs
   to be realized, instead of the step-by-step execution instruction,
   based on which the agent can make execution plans through the local
   AI model and invoke the proper tools to perform the task.  Thus,
   Agent protocols should support Agents to interact with each other or
   with consumers through intents, to make the agent interaction
   flexible enough.

3.6.  Security, Privacy and Trust

   The security control flow provides the access security control, the
   secure transportation, and the cross-domain secure collaboration
   capabilities, which is also important to agent protocol, as agents
   will be one of the main communication end-point for both terminal and
   network.  Various cryptographic algorithms ensure the security of
   transmission channels and the implementation of different levels of
   security measures according to different policies.

   The transmission of user consent and service visibility messages
   between the network and the terminal side ensures that the
   subscribers can be aware of the data usage purposes agreed upon
   between the operator and the subscriber.  AI Agent brings new
   possibility to interact with each other with multi-modal information,
   in this case, the procedure of user consent and service visibility
   would not be ignored.

3.7.  Agent Governance

   AI Agents of different skills, capabilities, and vendors need to
   discover each other when they collaborate to perform a task.  It is
   important to manage and control the agent information to enable an
   agent to find others from a massive number of candidates.

   The agent protocol has to support the agent (de-)registration, update
   and discovery with an authority that may be deployed in central or
   distributed way.  It needs to consider how this authority to ensure
   agent behaviors, agent skill set or capability publish, ensure
   trustworthiness and discovery among agents, when designing the
   protocols.








Chenchen Yang,, et al.   Expires 21 January 2026                [Page 9]

Internet-Draft                 Short Title                     July 2025


   The effective publish-subscribe and request-response mechanisms for
   discovering agents with required skills or capabilities are needed.
   Wake up calls of equipment that hosts the agents need to be supported
   as well.  This is also related to service continuity which should be
   maintained by the agentic ecosystem.

3.8.  Backward Compatibility and Forward Compatible

   As mentioned in 2.4 and 2.7, networks consist of multiple
   stakeholders/parties with various UE, network, and protocol versions.
   Therefore, agent protocols should be flexible, backward-compatible,
   forward-compatible, potentially self-evolving (e.g., protocol self-
   generation and negotiation, protocol version self-upgrade or merge)
   in the future, and easy to evolve.  More specifically, agent
   protocols should be built upon existing network functions and
   systems, while also remaining adaptable to future network
   architecture/functions designs and system evolutions.

3.9.  Extensibility

   Agent protocols exist across multiple domains, such as UE, RAN, CN,
   and DN.  Additionally, service, data, and capability exposure may
   originate from different networks.  Therefore, agent protocol should
   support the expanding and scaling of agents so that any type of
   agents (e.g., Network autonomy agent and integrated sensing-AI Agent)
   can be seamlessly integrated to the whole agent system.  To achieve
   this, task-based communication should be supported to enable rapid
   service subscription and publishing between agents.  ## Flexibility
   AI Agents are capable of self-learning and self-evolving, which
   implies that skills, capabilities, and accepted input and output
   modalities may change as time goes.  The agent protocol shall be
   designed to be sufficiently flexible, allowing fast adaption to
   expected changes.

   Moreover, the protocol data objects and agent profiles exchanged
   within the protocol shall be designed with flexible fields that are
   easy to scale and modify without re-design.

3.10.  Isolation

   The messages or traffic flows of mobile network usually have
   different-level of security or delay requirements.  For example,
   request messages from UE have higher security requirement than that
   for common traffic flows.  Thus, agent messages or traffic flows with
   different performance requirements shall be decoupled and isolated to
   facilitate differentiated processing.





Chenchen Yang,, et al.   Expires 21 January 2026               [Page 10]

Internet-Draft                 Short Title                     July 2025


3.11.  Tool Invocation

   The key feature of an agent is that it can invoke tools to execute
   tasks autonomously.  When AI Agents are introduced into 6G network,
   various network capabilities, network functions and even the 3rd
   party application functions can serve as tools to be invoked and used
   by agents.

   It is an important aspect to enable agents to invoke the required
   tools accurately.  Thus, it needs to consider how to enable the Agent
   protocols to describe tools’ information explicitly and sufficiently
   such that agents can easily identify target tools and easily learn
   how to use them.

   Different tools have different implementation methods and invocation
   approaches.  How to enable agents to flexibly invoke different tools
   to support plug-and-play of future tools also needs to be considered.

3.12.  Knowledge Retrieval

   AI Agents need flexibly access to 6G network internal or external
   data sources or knowledge bases to retrieve additional information
   that may not be present within the local knowledge of an agent model.
   The following issues need to be considered for Agent protocol design:

   *  *Metadata filtering:* how to filter the un-related data, e.g.
      through time label, data type label.

   *  *Data representation:* how to represent data of knowledge so as to
      improve transmission efficiency, such as represented as vectors or
      graphs.

   *  *Retrieval mechanism:* how to search and retrieve the required
      data, e.g. through similarity, key words, Token, natural language,
      etc.

4.  Enabling Protocol Technologies

   Given the agent protocol requirements elaborated above, the following
   enabling technologies can be investigated and standardized in IETF,
   e.g., in terms of Agent governance layer, Meta protocol layer,
   Security control layer, and Transport layer.  Different features
   should be provided in each layer, which will also be investigated and
   introduced by 3GPP potentially.







Chenchen Yang,, et al.   Expires 21 January 2026               [Page 11]

Internet-Draft                 Short Title                     July 2025


4.1.  Agent Governance Layer

4.1.1.  Registration and Discovery

   As shown in section 3.7, an authority is required to govern the
   available AI Agents in the mobile network.  The new agent will
   register its agent profile to the authority, request to update the
   agent profile when the agent skills or capabilities are changed, and
   de-register from the authority when the agent is not used anymore.
   The agent profile contains the key information about the agent, such
   as agent role description, skills, capabilities, identifier, input
   and output schema, vendor information, URL, etc.

   The authority will store and maintain the agent profile of all the
   available agents.  When an agent wants to discover a target agent by
   providing required agent description, the authority needs to perform
   a search and matching between the provided description and the role
   or skill description of registered agents, e.g. through cosine
   similarity computation or Jaccard similarity computation [7][8].

4.1.2.  Publish and Subscribe

   The AI Agents can subscribe to the authority about the agent
   information of specific set of agents so as to acquire their real-
   time updates.  The agent subscription can support various forms, such
   as through agent ID, role type, skill type, etc.

   When the profile of an agent is updated or the agent is de-
   registered, the authority shall notify the other agents that
   subscribed to the information of this agent as to prevent them from
   sending inappropriate requests to the agent.

   In addition, if there is no registered agent can perform the task
   requested by an agent, or all available agents are in regions where
   the request agent cannot render the task, the agent ecosystem can
   also provide a registration mechanism such that an agent posts its
   interest and gets notified as soon a new suitable agent comes and
   registers with the ecosystem and comes online.

4.1.3.  Agent Communication

   In the mobile network, an agent may need to communicate with other
   agents, resources (e.g., tools, data, or APIs), underlying
   infrastructure (e.g. base stations, computing platform), and users
   (e.g. UEs, applications).  For different communication objects,
   various protocol methods and data objects are needed to be defined.
   To enable the flexible and intent-based interaction for agents, the
   data objects are usually semi-structured, where the contents or



Chenchen Yang,, et al.   Expires 21 January 2026               [Page 12]

Internet-Draft                 Short Title                     July 2025


   values of each field are not pre-defined and only the key labels are
   inserted to improve the understandability and completeness.

   For the communication between agents, Google A2A defines several
   methods based on JSON RPC 2.0, such as _message/send_, _task/get_,
   _task/cancel_ [6], to support initiating a new task, updating or
   deleting an existing task, querying the current status of a task,
   subscribing the information of specific tasks.  The data object
   “_Task_” is exchanged with the methods, which includes the
   information such as task identity, requirements, context, states,
   outputs, etc.  They can be applied to the mobile network with proper
   extension combining mobile network characteristics.  For example, the
   task QoS information, network status and resource information also
   need to be exchanged.  And an agent can also refuse a task due to
   reasons such as limited network resources and transmission buffer.

   For the communication between agents and resources (such as tools,
   data, APIs), the methods need to support AI Agents to invoke various
   network and service functions, in order to trigger and execute
   suitable network actions and operations, or to query network operator
   data, network running log data, beyond connectivity data (e.g.,
   sensing data, AI data), etc.

   The methods for the communication between agents and users are
   required to support a user to request a service (e.g. AI, sensing),
   update or release a service, acquire the service status or result,
   etc.

4.1.4.  Multimodal Data Management

   The data exchanged by agents are multi-modal, which can be text,
   image, audio, video, structured data, etc.  For example, A2A protocol
   defines three types of data structures [6], i.e., TextPart,
   ProfilePart and DataPart, to respectively carry texts, profile and
   structured data.  More kinds of data structures, such as AudioPart
   and VideoPart, may be needed, e.g., a UE may initiate a request to
   the agent in the mobile network through audio.  Agent protocols
   should be designed with the principle that the Agent data with
   different modalities can be distinguished, based on which 6G network
   can provide differentiated QoS assurances.  For example, on one hand,
   the Agent protocol can support to encapsulate data of different
   modalities to distinct data structures.  On the other hand, the 6G
   network may establish different resources for transmitting various
   modalities of data to perform QoS control and guarantee.

   Besides, there shall be a closely integration design between the
   agent ecosystem and the underlying network.  For example, the
   equipment hosting the agent may enter sleep mode when the agent is



Chenchen Yang,, et al.   Expires 21 January 2026               [Page 13]

Internet-Draft                 Short Title                     July 2025


   not executing task, and it needs to be woken up by a client agent so
   that the server agent can process the multi-modal data from the
   client agent to perform the task.

   Multi-modal data is heterogeneous, meaning that data from different
   modalities differ in structure, semantics and representation, but
   they complement each other from various perspectives on the same
   subject.  Processing and analysis of multi-modal data are quite
   challenging, which requires to consider multiple impact factors, such
   as data alignment, feature extraction, etc.  Thus, the following key
   technologies shall be adopted.

   - Data pre-processing technology: it includes data cleaning (removing
   noise and redundant data), data standardization (converting data from
   different modalities into a unified format), data augmentation
   (increasing the diversity of data through operations such as
   rotation, scaling).

   - Feature extraction technology: it includes text, image, audio,
   video feature extraction, etc.

   - Data alignment technology: it is to ensure the consistency of data
   across time, spatial location, and semantics.

   - Fusion technology: it is to integrate diverse data to enhance its
   completeness, accuracy, and usability.

   *  *Data pre-processing technology*: it includes data cleaning
      (removing noise and redundant data), data standardization
      (converting data from different modalities into a unified format),
      data augmentation (increasing the diversity of data through
      operations such as rotation, scaling).

   *  *Feature extraction technology*: it includes text, image, audio,
      video feature extraction, etc.

   *  *Data alignment technology*: it is to ensure the consistency of
      data across time, spatial location, and semantics.

   *  *Fusion technology*: it is to integrate diverse data to enhance
      its completeness, accuracy, and usability










Chenchen Yang,, et al.   Expires 21 January 2026               [Page 14]

Internet-Draft                 Short Title                     July 2025


4.2.  Meta Protocol Layer

   As mentioned in 3.8, 3.9 and 3.10, agent protocols should allow for
   customization or privatization of the protocol while maintaining the
   standardized agent protocols.  Capabilities such as self-negotiation,
   self-generation and self-evolving of agent protocol should be
   supported to solve the compatibility problem, while protocol release
   control is required to accommodate the co-existence of multi-releases
   of those cross-operator and cross-domain agents.  Additionally, agent
   protocols should be able to call tools and data by calling network
   functions.

   Meta protocol layer should support the self-negotiation of agent [9].
   Agent itself can decide the modality of interaction message like
   text, voice, etc.

   Considering the co-existence of multi-party and cross-domain agents
   inside of the whole agent system, both the standardized protocol and
   negotiated protocol can be potential options.

4.3.  Security, Privacy and Trust Layer

   As mentioned in 3.6, agent protocols should consider the requirements
   of security, privacy and trust.  Some of the enabling technologies
   are listed as below:

   - Distributed Identity (DID) system for AI Agents

   Based on the mobile network oriented DID system, the network offers
   rapid authentication and key establishment based on multiple roots of
   trust, fine-grained authorization, and selective privacy disclosure
   via agent protocols.  Simultaneously, the DID system supports the
   security of cross-domain, e.g. working for different groups of AI
   Agents, connections through the same DID translation and related
   policies.

   - Distributed ledger

   Distributed ledger technology provides a foundation of trust for
   multi-party collaboration, which will be common case for AI Agents
   ineraction.  Acting as a bridge of trust, it enables different
   systems holding credentials issued by various authoritative
   institutions to achieve mutual trust.  As a consensus infrastructure,
   it offers tamper-proof functionality and transparent auditability for
   critical information.

   - Ciphertext-based computing technology




Chenchen Yang,, et al.   Expires 21 January 2026               [Page 15]

Internet-Draft                 Short Title                     July 2025


   Considering the elimination of user privacy concerns, ciphertext-
   based computing technology provides the capability of "computing
   without knowing" for network queries and computations on user data.
   Agent protocols should include this option to ensure that data
   privacy at different levels can be handled in an acceptable manner.

   - Quantum-safe technologies

   Quantum-safe technologies include post-quantum cryptography (PQC) and
   its protocols based on cryptographic techniques, as well as quantum
   secure transmission methods such as Quantum Key Distribution (QKD).
   The preemptive deployment of quantum-safe technologies, such as PQC
   migration, will prepare for defending against quantum attacks.  The
   algorithm set for agent protocols should consider quantum-safe from
   day 1.

4.4.  Transport Layer

   As mentioned in 3.2, 3.3, 3.4 and 3.11, the Agent QoS and service
   continuity should be guaranteed.  Agent messages or traffic flows
   with different performance requirements shall be decoupled and
   isolated.  The following potential technologies for transport layer
   protocols can be investigated:

   *  *To support stream multiplexing, collaboration and grouping:*
      e.g., different “Parts” of agent traffic with different sizes can
      be sent in parallel via a group of transport streams to enable
      them to arrive to peer node synchronously within a strict delay
      budget, or sent asynchronously with different priorities within a
      same stream if synchronous arrival to peer node is not needed.
      The balance between the complexity of transport connection
      establishment and the flexibility of scheduling should be
      considered.

   *  *To support a reliable and efficient transmission mechanism for
      agent traffic:* A) Stream multiplexing of multiple agent traffic
      data streams, B) Traffic steering, switching, splitting of
      multiple agent traffic data streams.

   *  *To natively support connection migration, quick link
      establishment*: so that agent service continuity could be
      guaranteed in mobility scenarios.

   *  *To support burst agent traffic transmission*: Burst traffic
      information can be encapsulated in protocol header for better QoS
      guarantee and resource real-time scheduling and adjustment.  The
      QoS (e.g., latency and timeliness) is guaranteed toward the whole
      burst data set of agent traffic rather than a specific packet.



Chenchen Yang,, et al.   Expires 21 January 2026               [Page 16]

Internet-Draft                 Short Title                     July 2025


5.  Summary

   A hierarchical consideration of agent protocol is definitely
   important to meet different kinds of requirements, e.g., from 6G
   network.  Collaborations between IETF, ETSI and 3GPP and
   collaborations across different work groups (e.g., for agent
   protocol, transport protocol, and security) of IETF are required.

6.  Reference

6.1.  Informative References

   [1] Li, Xu, Weisen Shi, Hang Zhang, Chenghui Peng, Shaoyun Wu, and
   Wen Tong.  "The Agentic-AI Core: An AI-Empowered, Mission-Oriented
   Core Network for Next-Generation Mobile Telecommunications."
   _Engineering_ (2025).

   [2] ETSI GR ENI 051 V4.1.1, “Experiential Networked Intelligence
   (ENI); Study on AI Agents based Next-generation Network Slicing”,
   2025.02.

   [3] ETSI ENI ISG 055 Early Draft, “Use Cases and Requirements for AI
   Agents based Core Network”, 2025.06.04.

   [4] 3GPP TR 22.870 (V0.2.0): “Study on 6G Use Cases and Service
   Requirements; Stage 1 (Release 20)”.

   [5] 3GPP SP-250806: "Study on Architecture for 6G System".

   [6] A2A Protocol.  "Specification". https://a2a-protocol.org/latest/
   specification/, 2025.

   [7] D.  Gunawan, C.  A.  Sembiring, M.  A.  Budiman, “The
   implementation of cosine similarity to calculate text relevance
   between two documents”, Journal of physics: conference series, 2018.

   [8] S.  Bag, S.  K.  Kumar, M.  K.  Tiwari, “An efficient
   recommendation generation using relevant Jaccard similarity”,
   Information Sciences, 2019.

   [9] Marro, Samuele, Emanuele La Malfa, Jesse Wright, Guohao Li, Nigel
   Shadbolt, Michael Wooldridge, and Philip Torr.  "A scalable
   communication protocol for networks of large language models." arXiv
   preprint arXiv:2410.11905 (2024).







Chenchen Yang,, et al.   Expires 21 January 2026               [Page 17]

Internet-Draft                 Short Title                     July 2025


7.  Security Considerations

   This document should not affect the security of the Internet.

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Appendix

10.  Normative References

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/rfc/rfc8986>.

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

Authors' Addresses

   Chenchen Yang,
   Huawei
   Lianqiu Lake, Qingpu District
   Shanghai
   201799
   China
   Email: yangchenchen7@huawei.com


   Huanhuan Huang,
   Huawei
   Lianqiu Lake, Qingpu District
   Shanghai
   201799
   China
   Email: huanghuanhuan9@huawei.com






Chenchen Yang,, et al.   Expires 21 January 2026               [Page 18]

Internet-Draft                 Short Title                     July 2025


   Arashmid Akhavain,
   Huawei
   303 Terry Fox Drive, Kanata
   Ottawa  K2K 3J1
   Canada
   Email: arashmid.akhavain@huawei.com


   Faye Liu,
   Huawei
   9 North Buona Vista Dr.
   SINGAPORE 117674
   Singapore
   Email: liufei19@huawei.com


   Xueli An,
   Huawei
   Riesstr. 25
   80992 Munich
   Germany
   Email: Xueli.An@huawei.com


   Weijun Xing,
   Huawei
   Lianqiu Lake, Qingpu District
   Shanghai
   201799
   China
   Email: xingweijun1@huawei.com


   Jinyan Li,
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: lijinyan@chinatelecom.cn


   Aijun Wang,
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China



Chenchen Yang,, et al.   Expires 21 January 2026               [Page 19]

Internet-Draft                 Short Title                     July 2025


   Email: wangaj3@chinatelecom.cn


   Yang Wencong,
   China Unicom
   No. 9 Shouti South Road, Haidian District
   Beijing
   100044
   China
   Email: yangwc27@chinaunicom.cn









































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

categories:
["Agent-to-agent communication protocols", "Autonomous network operations", "Agent discovery / registration"]


name: draft-nandakumar-agent-sd-jwt
rev: 01
title: Selective Disclosure for Agent Discovery and Identity Management (SD- Agent)
time: 2025-10-20T01:30:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T01:30:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420387+00:00
abstract:
This document defines how Selective Disclosure for JWTs (SD-JWT)
   integrates with Agent-to-Agent (A2A) systems to provide privacy-
   preserving agent discovery and cryptographically verifiable identity
   management.  It specifies the SD-Card format - an SD-JWT encoding of
   Agent Cards that enables selective disclosure of agent capabilities,
   contact information, and operational metadata while maintaining
   cryptographic integrity and preventing correlation across different
   interaction contexts.

full_text:
Network Working Group                                      S. Nandakumar
Internet-Draft                                               C. Jennings
Intended status: Informational                                     Cisco
Expires: 22 April 2026                                   19 October 2025


 Selective Disclosure for Agent Discovery and Identity Management (SD-
                                 Agent)
                    draft-nandakumar-agent-sd-jwt-01

Abstract

   This document defines how Selective Disclosure for JWTs (SD-JWT)
   integrates with Agent-to-Agent (A2A) systems to provide privacy-
   preserving agent discovery and cryptographically verifiable identity
   management.  It specifies the SD-Card format - an SD-JWT encoding of
   Agent Cards that enables selective disclosure of agent capabilities,
   contact information, and operational metadata while maintaining
   cryptographic integrity and preventing correlation across different
   interaction contexts.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 22 April 2026.

Copyright Notice

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

   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



Nandakumar & Jennings     Expires 22 April 2026                 [Page 1]

Internet-Draft                Agent-SD-JWT                  October 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
   2.  Overview of SD-Card Architecture and Benefits . . . . . . . .   4
   3.  SD-Card Agent Card  . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Agent Card Structure  . . . . . . . . . . . . . . . . . .   5
     3.2.  Selective Disclosure Claims . . . . . . . . . . . . . . .   7
       3.2.1.  Skills and Capabilities . . . . . . . . . . . . . . .   7
       3.2.2.  Additional Agent Interfaces . . . . . . . . . . . . .  11
       3.2.3.  Agent Capabilities  . . . . . . . . . . . . . . . . .  13
       3.2.4.  Security Schemes and Authentication . . . . . . . . .  14
       3.2.5.  Provider Information  . . . . . . . . . . . . . . . .  17
       3.2.6.  Input and Output Modes  . . . . . . . . . . . . . . .  18
       3.2.7.  Documentation and Support . . . . . . . . . . . . . .  20
     3.3.  Agent Card Issuance . . . . . . . . . . . . . . . . . . .  20
       3.3.1.  Issuance Process Overview . . . . . . . . . . . . . .  20
   4.  Agent Discovery Protocols with Privacy Protection . . . . . .  21
     4.1.  Well-Known URI Discovery  . . . . . . . . . . . . . . . .  21
     4.2.  Registry-Based Discovery  . . . . . . . . . . . . . . . .  22
     4.3.  Contextual Discovery  . . . . . . . . . . . . . . . . . .  23
   5.  Cryptographic Authentication and Capability-Based
           Authorization . . . . . . . . . . . . . . . . . . . . . .  23
     5.1.  SD-JWT with Key Binding . . . . . . . . . . . . . . . . .  23
     5.2.  Agent Authentication Process  . . . . . . . . . . . . . .  24
       5.2.1.  Step 1: Agent Card Presentation . . . . . . . . . . .  24
       5.2.2.  Step 2: Key Binding JWT Creation  . . . . . . . . . .  25
       5.2.3.  Step 3: Cryptographic Verification  . . . . . . . . .  26
     5.3.  Advanced Authorization Flows  . . . . . . . . . . . . . .  26
   6.  Complete SD-JWT and Key Binding Examples  . . . . . . . . . .  27
     6.1.  SD-JWT Agent Card Creation Process  . . . . . . . . . . .  27
       6.1.1.  Step 1: Original A2A Agent Card (Input) . . . . . . .  27
       6.1.2.  Step 2: SD-JWT Transformation with Selective
               Disclosure  . . . . . . . . . . . . . . . . . . . . .  28
       6.1.3.  Step 3: Disclosure Arrays for Selective Claims  . . .  29
       6.1.4.  Step 4: Complete SD-JWT Serialization . . . . . . . .  30
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  30
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31




Nandakumar & Jennings     Expires 22 April 2026                 [Page 2]

Internet-Draft                Agent-SD-JWT                  October 2025


1.  Introduction

   The Agent-to-Agent (A2A) specification [A2A-SPEC] defines protocols
   for autonomous agent discovery and interaction through standardized
   Agent Cards.  Current A2A implementations have following limitations:

   1.  Information Leakage: Agent Cards expose all capabilities during
       discovery

   2.  Weak Authentication: No cryptographic verification of agent
       identity

   3.  Static Disclosure: No context-based capability filtering

   4.  Linkability: Identical presentations enable cross-context
       tracking

   This document specifies SD-Card, an SD-JWT [SD-JWT] encoding of Agent
   Cards that addresses these limitations through:

   *  Selective Disclosure: Context-specific capability revelation

   *  Cryptographic Authentication: Key-bound agent identity
      verification

   *  Unlinkable Presentations: Privacy-preserving multi-context
      interactions

   *  Backward Compatibility: Interoperability with existing A2A
      implementations

1.1.  Terminology

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

   Agent Card: A JSON metadata document describing an agent's
   capabilities, identity, and interaction requirements as defined in
   [A2A-SPEC].

   SD-Card: An Agent Card encoded as an SD-JWT that enables selective
   disclosure of agent metadata.

   Agent Registry: A trusted service that issues and manages SD-Cards
   for agents within a domain or federation.



Nandakumar & Jennings     Expires 22 April 2026                 [Page 3]

Internet-Draft                Agent-SD-JWT                  October 2025


   Discovery Context: A named security context (e.g., "public",
   "internal", "diagnostic") that determines which claims are disclosed
   in an SD-Card presentation.

   Capability Disclosure: The selective revelation of specific agent
   capabilities based on the requesting entity's authorization and
   context.

   Key Binding: Cryptographic proof that the presenter of an SD-Card
   possesses the private key corresponding to the public key in the SD-
   Card's cnf claim.

   SD-JWT Media Type: The application/vnd.sd-jwt+json media type is used
   to indicate content that contains Selective Disclosure JWT data
   within JSON structures.  This vendor-specific media type
   distinguishes SD-JWT presentations from standard JSON content and
   signals that the receiver should process the content using SD-JWT
   parsing and verification procedures.

1.2.  Notational Conventions

   This document follows SD-JWT [SD-JWT] conventions:

   *  Base64url encoding for binary data

   *  JWS format for signed tokens

   *  SHA-256 hashing for selective disclosure

   *  Tilde (~) separator for SD-JWT serialization:

  <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...<Key Binding JWT>

2.  Overview of SD-Card Architecture and Benefits

   SD-Card enhances Agent-to-Agent (A2A) interactions by providing
   privacy-preserving agent discovery and cryptographically verifiable
   agent authentication.  SD-Card enables selective disclosure of agent
   capabilities, skills, and endpoints based on requester authorization
   and discovery context, unlinkable agent interactions across different
   contexts, cryptographic integrity of agent metadata, and key binding
   for authentication that complements transport-layer security.

   Traditional agent discovery in Agent-to-Agent protocol faces several
   challenges:

   Information Leakage:  Agent Cards expose all capabilities to any




Nandakumar & Jennings     Expires 22 April 2026                 [Page 4]

Internet-Draft                Agent-SD-JWT                  October 2025


      entity performing discovery, potentially revealing sensitive
      operational details.

   Linkability:  Identical capabilities presented to different verifiers
      enable tracking across contexts.

   Authenticity:  Without cryptographic verification, Agent Cards can be
      forged or tampered with during transmission.

   Capability Enumeration:  Attackers can enumerate all agent
      capabilities by performing discovery, potentially identifying
      attack vectors.

   Context Insensitivity:  Agents cannot adapt capability disclosure
      based on the requesting entity's authorization level or intended
      use case.

   Allowing agents to selectively disclose their capabilities addresses
   these challenges through:

   Selective Capability Disclosure:  Agents reveal only capabilities
      relevant to the specific discovery context or requester
      authorization level.

   Unlinkable Presentations:  Different presentations of the same agent
      to different verifiers cannot be linked, enhancing privacy.

   Flexible Authentication:  Key binding enables strong agent
      authentication without relying solely on transport security.

   Batch Credential Issuance:  Multiple context-specific credentials can
      be issued to the same agent for different use cases.

3.  SD-Card Agent Card

   This specification defienes "SD-Card".  An SD-Card is an Agent Card
   encoded as an SD-JWT.

3.1.  Agent Card Structure

   The base Agent Card structure follows the A2A specification
   [A2A-SPEC] but is extended to support selective disclosure.  The card
   consists of three main components:

   1.  Base Claims: Always disclosed information that establishes the
       agent's identity, protocol version, and basic metadata





Nandakumar & Jennings     Expires 22 April 2026                 [Page 5]

Internet-Draft                Agent-SD-JWT                  October 2025


   2.  Selective Disclosure Claims: A2A-specific information that can be
       selectively revealed based on the discovery context including
       skills, interfaces, and provider details

   3.  Cryptographic Binding: Keys and signatures that ensure
       authenticity and enable secure agent interactions

   The Agent Card is represented as a Selective Disclosure JSON Web
   Token (SD-JWT) that contains both standard A2A Agent Card fields and
   selective disclosure metadata :

{
  "iss": "https://registry.example.com",
  "sub": "agent:georoute-planner-v1",
  "iat": 1704063600,
  "exp": 1735685999,
  "vct": "urn:ietf:params:oauth:token-type:sd-agent-card",
  "_sd_alg": "sha-256",
  "_sd": [
    "kV7i-VgPK9Qj8vYNJ4L8hFG3cR9ZqX2mE5wC6oA1nBs", // skills
    "3sdf8mN2p9uX7L3vE8nGrR5kW6oF4tC9jL7vM2nX8qE", // additionalInterfaces
    "8kF2nM3p4uY9L5cG6rT7qW9oR2vX1jE4mN8sC5fH0aZ", // capabilities
    "9mH4pL5rZ8wQ2nX7cV6sT3kE1oY0jF9uR4vB6nM8fG2", // securitySchemes
    "7kRt2qW5mX9jN4cF7zPsE8nG1vH0oY3lM6xC9fK2bA8", // provider
    "5nK3wL8tB4eR9mY2cF6qG7oT1vX0jH3pN4rS8zE5fC6", // defaultInputModes
    "2pM8fT4nR6oX3cG7zE9qL5wY1vS0jF6kH2nB8mC4rT9"  // defaultOutputModes
  ],
  "protocolVersion": "0.2.9",
  "name": "GeoSpatial Route Planner Agent",
  "description": "Provides advanced route planning and traffic analysis services",
  "version": "1.2.0",
  "url": "https://georoute-agent.example.com/a2a/v1",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

   The following claims are permanently disclosed in the SD-Card:

   iss:  The issuer of the Agent Card (typically an Agent Registry).
      This establishes the trust anchor for the credential and enables
      signature verification.  The issuer MUST be a resolvable URI that
      provides access to the issuer's public key material.



Nandakumar & Jennings     Expires 22 April 2026                 [Page 6]

Internet-Draft                Agent-SD-JWT                  October 2025


   sub:  The unique identifier of the agent within the issuer's
      namespace.  This identifier MUST be stable across different Agent
      Card issuances for the same logical agent, enabling correlation
      when authorized while supporting unlinkable presentations through
      different salt values.

   iat:  The time at which the Agent Card was issued (Unix timestamp).

   exp:  The expiration time of the Agent Card (Unix timestamp).

   vct:  The verifiable credential type, identifying this as an SD-Card
      Agent Card.  This value MUST be "urn:ietf:params:oauth:token-
      type:sd-agent-card" for compliance with this specification.

   name:  The human-readable name of the agent.

   description:  A brief description of the agent's purpose and primary
      function.  This helps users understand the agent's role without
      revealing sensitive capability details.

   version:  The version of the agent software.

   cnf:  The confirmation key for agent authentication.  This public key
      enables key binding and ensures that only the legitimate agent can
      present the Agent Card.  The key MUST be in JSON Web Key (JWK)
      format.

3.2.  Selective Disclosure Claims

   The following claims are selectively disclosed based on the discovery
   context:

3.2.1.  Skills and Capabilities

   The skills claim contains an array of A2A AgentSkill objects that the
   agent can perform.  Each skill definition follows the A2A
   specification and includes input/output modes, examples, and metadata
   for proper integration.

3.2.1.1.  Original Skills JSON Object:











Nandakumar & Jennings     Expires 22 April 2026                 [Page 7]

Internet-Draft                Agent-SD-JWT                  October 2025


"skills": [
  {
    "id": "route-optimizer-traffic",
    "name": "Traffic-Aware Route Optimizer",
    "description": "Calculates optimal driving route between locations with real-time traffic",
    "tags": ["maps", "routing", "navigation", "directions", "traffic"],
    "examples": [
      "Plan a route from '1600 Amphitheatre Parkway, Mountain View, CA' to 'San Francisco International Airport' avoiding tolls.",
      "{\"origin\": {\"lat\": 37.422, \"lng\": -122.084}, \"destination\": {\"lat\": 37.7749, \"lng\": -122.4194}, \"preferences\": [\"avoid_ferries\"]}"
    ],
    "inputModes": ["application/json", "text/plain"],
    "outputModes": [
      "application/json",
      "application/vnd.geo+json",
      "text/html"
    ]
  },
  {
    "id": "custom-map-generator",
    "name": "Personalized Map Generator",
    "description": "Creates custom map images based on user-defined points of interest",
    "tags": ["maps", "customization", "visualization", "cartography"],
    "examples": [
      "Generate a map of my upcoming road trip with all planned stops highlighted.",
      "Show me a map visualizing all coffee shops within a 1-mile radius of my current location."
    ],
    "inputModes": ["application/json"],
    "outputModes": [
      "image/png",
      "image/jpeg",
      "application/json",
      "text/html"
    ]
  }
]

3.2.1.2.  SD-JWT Transformation Process:

   When converting the skills claim to selective disclosure, the Agent
   Registry performs the following transformation:

   Step 1: Generate Salt Value

   A cryptographically secure random salt is generated for the skills
   claim:

   Salt: "_26bc4LT-ac6q2KI6cBW5es"




Nandakumar & Jennings     Expires 22 April 2026                 [Page 8]

Internet-Draft                Agent-SD-JWT                  October 2025


   Step 2: Create Disclosure Array

   The skills claim is packaged into a disclosure array format:

       [
         "_26bc4LT-ac6q2KI6cBW5es",
         "skills",
         [
           {
             "id": "route-optimizer-traffic",
             "name": "Traffic-Aware Route Optimizer",
             "description": "Calculates optimal driving route between locations with real-time traffic",
             "tags": ["maps", "routing", "navigation", "directions", "traffic"],
             "examples": [
               "Plan a route from '1600 Amphitheatre Parkway, Mountain View, CA' to 'San Francisco International Airport' avoiding tolls.",
               "{\"origin\": {\"lat\": 37.422, \"lng\": -122.084}, \"destination\": {\"lat\": 37.7749, \"lng\": -122.4194}, \"preferences\": [\"avoid_ferries\"]}"
             ],
             "inputModes": ["application/json", "text/plain"],
             "outputModes": [
               "application/json",
               "application/vnd.geo+json",
               "text/html"
             ]
           },
           {
             "id": "custom-map-generator",
             "name": "Personalized Map Generator",
             "description": "Creates custom map images based to user-defined points of interest",
             "tags": ["maps", "customization", "visualization", "cartography"],
             "examples": [
               "Generate a map of my upcoming road trip with all planned stops highlighted.",
               "Show me a map visualizing all coffee shops within a 1-mile radius of my current location."
             ],
             "inputModes": ["application/json"],
             "outputModes": [
               "image/png",
               "image/jpeg",
               "application/json",
               "text/html"
             ]
           }
         ]
       ]

   Step 3: Base64url Encode Disclosure

   The disclosure array is JSON-serialized and base64url-encoded:




Nandakumar & Jennings     Expires 22 April 2026                 [Page 9]

Internet-Draft                Agent-SD-JWT                  October 2025


ImFwcGxpY2F0aW9uL2pzb24iLCJ0ZXh0L2h0bWwiXX1dXQ

   Step 4: Calculate SHA-256 Digest

   A SHA-256 hash is computed over the base64url-encoded disclosure:

   digest = SHA256(base64url_encode(disclosure_array))
         = "kV7i-VgPK9Qj8vYNJ4L8hFG3cR9ZqX2mE5wC6oA1nBs"

   Step 5: Include Digest in SD-JWT

   The digest is included in the _sd array of the Issuer-signed JWT
   payload:

       {
         "iss": "https://registry.example.com",
         "sub": "agent:georoute-planner-v1",
         "_sd_alg": "sha-256",
         "_sd": [
           "kV7i-VgPK9Qj8vYNJ4L8hFG3cR9ZqX2mE5wC6oA1nBs",
           "7iF2sM8kT5nL9pX3cV6zR4qW1eY8oU0jH3vB7nM2kF9"
         ],
         "name": "GeoSpatial Route Planner Agent",
         "cnf": { }
       }

   Step 6: Selective Disclosure



Nandakumar & Jennings     Expires 22 April 2026                [Page 10]

Internet-Draft                Agent-SD-JWT                  October 2025


   When presenting the agent card, the skills disclosure is included
   only if authorized:

<Issuer-signed JWT>~<Skills Disclosure>~<Other Disclosures>~<Key Binding JWT>

   During verification, the verifier:

   1.  Decodes the skills disclosure from base64url

   2.  Calculates SHA-256 hash of the decoded disclosure

   3.  Confirms the hash matches the digest in the _sd array

   4.  Extracts the skills claim value for use

3.2.2.  Additional Agent Interfaces

   The additionalInterfaces claim defines alternative transport
   mechanisms and endpoints for A2A communication as specified in the
   AgentInterface object structure.

3.2.2.1.  Original values

   The original additionalInterfaces claim in the agent metadata
   contains:

   {
     "additionalInterfaces": [
       {
         "url": "https://georoute-agent.example.com/a2a/v1",
         "transport": "JSONRPC"
       },
       {
         "url": "https://georoute-agent.example.com/a2a/grpc",
         "transport": "GRPC"
       },
       {
         "url": "https://georoute-agent.example.com/a2a/json",
         "transport": "HTTP+JSON"
       }
     ]
   }

3.2.2.2.  SD-JWT Transformation Process:

   When converting the additionalInterfaces claim to selective
   disclosure, the Agent Registry performs the following transformation:




Nandakumar & Jennings     Expires 22 April 2026                [Page 11]

Internet-Draft                Agent-SD-JWT                  October 2025


   Step 1: Generate Salt Value A cryptographically secure random salt is
   generated for the additionalInterfaces claim:

   Salt: "_26bc4LT-ac6q2KI6cBW5es"

   Step 2: Create Disclosure Array The additionalInterfaces claim is
   packaged into a disclosure array format:

   [
     "_26bc4LT-ac6q2KI6cBW5es",
     "additionalInterfaces",
     [
       {
         "url": "https://georoute-agent.example.com/a2a/v1",
         "transport": "JSONRPC"
       },
       {
         "url": "https://georoute-agent.example.com/a2a/grpc",
         "transport": "GRPC"
       },
       {
         "url": "https://georoute-agent.example.com/a2a/json",
         "transport": "HTTP+JSON"
       }
     ]
   ]

   Step 3: Base64url Encode Disclosure

   The disclosure array is JSON-serialized and base64url-encoded:


   Step 4: Calculate SHA-256 Digest

   A SHA-256 hash is computed over the base64url-encoded disclosure:

   digest = SHA256(base64url_encode(disclosure_array))
         = "3sdf8mN2p9uX7L3vE8nGrR5kW6oF4tC9jL7vM2nX8qE"

   Step 5: Include Digest in SD-JWT

   The digest is included in the _sd array of the Issuer-signed JWT
   payload:







Nandakumar & Jennings     Expires 22 April 2026                [Page 12]

Internet-Draft                Agent-SD-JWT                  October 2025


   {
     "iss": "https://registry.example.com",
     "sub": "agent:georoute-planner-v1",
     "_sd_alg": "sha-256",
     "_sd": [
       "3sdf8mN2p9uX7L3vE8nGrR5kW6oF4tC9jL7vM2nX8qE"
     ]
   }

3.2.3.  Agent Capabilities

   The capabilities claim provides information about the agent's A2A
   protocol feature support as defined in the AgentCapabilities object.

3.2.3.1.  Original values

   The original capabilities claim in the agent metadata contains:

   {
     "capabilities": {
       "streaming": true,
       "pushNotifications": true,
       "stateTransitionHistory": false,
       "extensions": [
         {
           "name": "advanced-routing",
           "version": "1.0",
           "description": "Enhanced route optimization with machine learning"
         }
       ]
     }
   }

3.2.3.2.  SD-JWT Transformation Process:

   When converting the capabilities claim to selective disclosure, the
   Agent Registry performs the following transformation:

   Step 1: Generate Salt Value

   A cryptographically secure random salt is generated for the
   capabilities claim:

   Salt: "_26bc4LT-ac6q2KI6cBW5es"

   Step 2: Create Disclosure Array

   The capabilities claim is packaged into a disclosure array format:



Nandakumar & Jennings     Expires 22 April 2026                [Page 13]

Internet-Draft                Agent-SD-JWT                  October 2025


   [
     "_26bc4LT-ac6q2KI6cBW5es",
     "capabilities",
     {
       "streaming": true,
       "pushNotifications": true,
       "stateTransitionHistory": false,
       "extensions": [
         {
           "name": "advanced-routing",
           "version": "1.0",
           "description": "Enhanced route optimization with machine learning"
         }
       ]
     }
   ]

   Step 3: Base64url Encode Disclosure

   The disclosure array is JSON-serialized and base64url-encoded:


   Step 4: Calculate SHA-256 Digest

   A SHA-256 hash is computed over the base64url-encoded disclosure:

   digest = SHA256(base64url_encode(disclosure_array))
         = "8kF2nM3p4uY9L5cG6rT7qW9oR2vX1jE4mN8sC5fH0aZ"

   Step 5: Include Digest in SD-JWT

   The digest is included in the _sd array of the Issuer-signed JWT
   payload:

   {
     "iss": "https://registry.example.com",
     "sub": "agent:georoute-planner-v1",
     "_sd_alg": "sha-256",
     "_sd": [
       "8kF2nM3p4uY9L5cG6rT7qW9oR2vX1jE4mN8sC5fH0aZ"
     ]
   }

3.2.4.  Security Schemes and Authentication

   The securitySchemes claim defines authentication requirements
   following A2A SecurityScheme format.



Nandakumar & Jennings     Expires 22 April 2026                [Page 14]

Internet-Draft                Agent-SD-JWT                  October 2025


3.2.4.1.  Original values

   The original securitySchemes claim in the agent metadata contains:

   {
     "securitySchemes": {
       "google": {
         "type": "openIdConnect",
         "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration"
       },
       "apiKey": {
         "type": "apiKey",
         "name": "X-API-Key",
         "in": "header"
       }
     }
   }

3.2.4.2.  SD-JWT Transformation Process:

   When converting the securitySchemes claim to selective disclosure,
   the Agent Registry performs the following transformation:

   Step 1: Generate Salt Value

   A cryptographically secure random salt is generated for the
   securitySchemes claim:

   Salt: "_26bc4LT-ac6q2KI6cBW5es"

   Step 2: Create Disclosure Array

   The securitySchemes claim is packaged into a disclosure array format:


















Nandakumar & Jennings     Expires 22 April 2026                [Page 15]

Internet-Draft                Agent-SD-JWT                  October 2025


   [
     "_26bc4LT-ac6q2KI6cBW5es",
     "securitySchemes",
     {
       "google": {
         "type": "openIdConnect",
         "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration"
       },
       "apiKey": {
         "type": "apiKey",
         "name": "X-API-Key",
         "in": "header"
       }
     }
   ]

   Step 3: Base64url Encode Disclosure

   The disclosure array is JSON-serialized and base64url-encoded:


   Step 4: Calculate SHA-256 Digest

   A SHA-256 hash is computed over the base64url-encoded disclosure:

   digest = SHA256(base64url_encode(disclosure_array))
         = "9mH4pL5rZ8wQ2nX7cV6sT3kE1oY0jF9uR4vB6nM8fG2"

   Step 5: Include Digest in SD-JWT

   The digest is included in the _sd array of the Issuer-signed JWT
   payload:

   {
     "iss": "https://registry.example.com",
     "sub": "agent:georoute-planner-v1",
     "_sd_alg": "sha-256",
     "_sd": [
       "9mH4pL5rZ8wQ2nX7cV6sT3kE1oY0jF9uR4vB6nM8fG2"
     ],
     "security": [
       {"google": ["openid", "profile", "email"]},
       {"apiKey": []}
     ]
   }





Nandakumar & Jennings     Expires 22 April 2026                [Page 16]

Internet-Draft                Agent-SD-JWT                  October 2025


3.2.5.  Provider Information

   The provider claim contains A2A AgentProvider information about the
   organization that operates the agent.

3.2.5.1.  Original values

   The original provider claim in the agent metadata contains:

   {
     "provider": {
       "organization": "Example Geo Services Inc.",
       "url": "https://www.examplegeoservices.com"
     }
   }

3.2.5.2.  SD-JWT Transformation Process:

   When converting the provider claim to selective disclosure, the Agent
   Registry performs the following transformation:

   Step 1: Generate Salt Value

   A cryptographically secure random salt is generated for the provider
   claim:

   Salt: "_26bc4LT-ac6q2KI6cBW5es"

   Step 2: Create Disclosure Array

   The provider claim is packaged into a disclosure array format:

   [
     "_26bc4LT-ac6q2KI6cBW5es",
     "provider",
     {
       "organization": "Example Geo Services Inc.",
       "url": "https://www.examplegeoservices.com"
     }
   ]

   Step 3: Base64url Encode Disclosure

   The disclosure array is JSON-serialized and base64url-encoded:

WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsInByb3ZpZGVyIix7Im9yZ2FuaXphdGlvbiI6IkV4YW1wbGUgR2VvIFNlcnZpY2VzIEluYy4iLCJ1cmwiOiJodHRwczovL3d3dy5leGFtcGxlZ2Vvc2VydmljZXMuY29tIn1d

   Step 4: Calculate SHA-256 Digest



Nandakumar & Jennings     Expires 22 April 2026                [Page 17]

Internet-Draft                Agent-SD-JWT                  October 2025


   A SHA-256 hash is computed over the base64url-encoded disclosure:

   digest = SHA256(base64url_encode(disclosure_array))
         = "7kRt2qW5mX9jN4cF7zPsE8nG1vH0oY3lM6xC9fK2bA8"

   Step 5: Include Digest in SD-JWT

   The digest is included in the _sd array of the Issuer-signed JWT
   payload:

   {
     "iss": "https://registry.example.com",
     "sub": "agent:georoute-planner-v1",
     "_sd_alg": "sha-256",
     "_sd": [
       "7kRt2qW5mX9jN4cF7zPsE8nG1vH0oY3lM6xC9fK2bA8"
     ]
   }

3.2.6.  Input and Output Modes

   The defaultInputModes and defaultOutputModes claims specify supported
   content types for A2A message interactions.

3.2.6.1.  Original values

   The original defaultInputModes and defaultOutputModes claims in the
   agent metadata contain:

   {
     "defaultInputModes": ["application/json", "text/plain"],
     "defaultOutputModes": ["application/json", "image/png"]
   }

3.2.6.2.  SD-JWT Transformation Process:

   When converting the defaultInputModes and defaultOutputModes claims
   to selective disclosure, the Agent Registry performs the following
   transformation:

   Step 1: Generate Salt Value

   A cryptographically secure random salt is generated for the input/
   output modes claims:

   Salt: "_26bc4LT-ac6q2KI6cBW5es"

   Step 2: Create Disclosure Arrays



Nandakumar & Jennings     Expires 22 April 2026                [Page 18]

Internet-Draft                Agent-SD-JWT                  October 2025


   Each claim is packaged into separate disclosure array formats:

3.2.6.3.  Disclosure for defaultInputModes:

   [
     "_26bc4LT-ac6q2KI6cBW5es",
     "defaultInputModes",
     ["application/json", "text/plain"]
   ]

3.2.6.4.  Disclosure for defaultOutputModes:

   [
     "_26bc4LT-ac6q2KI6cBW5es",
     "defaultOutputModes",
     ["application/json", "image/png"]
   ]

   Step 3: Base64url Encode Disclosures

   The disclosure arrays are JSON-serialized and base64url-encoded:

3.2.6.5.  defaultInputModes encoded:

WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImRlZmF1bHRJbnB1dE1vZGVzIixbImFwcGxpY2F0aW9uL2pzb24iLCJ0ZXh0L3BsYWluIl1d

3.2.6.6.  defaultOutputModes encoded:

WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImRlZmF1bHRPdXRwdXRNb2RlcyIsWyJhcHBsaWNhdGlvbi9qc29uIiwiaW1hZ2UvcG5nIl1d

   Step 4: Calculate SHA-256 Digests

   SHA-256 hashes are computed over the base64url-encoded disclosures:

 digest_input = SHA256(base64url_encode(defaultInputModes_disclosure))
              = "5nK3wL8tB4eR9mY2cF6qG7oT1vX0jH3pN4rS8zE5fC6"

 digest_output = SHA256(base64url_encode(defaultOutputModes_disclosure))
               = "2pM8fT4nR6oX3cG7zE9qL5wY1vS0jF6kH2nB8mC4rT9"

   Step 5: Include Digests in SD-JWT

   The digests are included in the _sd array of the Issuer-signed JWT
   payload:







Nandakumar & Jennings     Expires 22 April 2026                [Page 19]

Internet-Draft                Agent-SD-JWT                  October 2025


   {
     "iss": "https://registry.example.com",
     "sub": "agent:georoute-planner-v1",
     "_sd_alg": "sha-256",
     "_sd": [
       "5nK3wL8tB4eR9mY2cF6qG7oT1vX0jH3pN4rS8zE5fC6",
       "2pM8fT4nR6oX3cG7zE9qL5wY1vS0jF6kH2nB8mC4rT9"
     ]
   }

3.2.7.  Documentation and Support

   Additional A2A Agent Card metadata for documentation and extended
   capabilities.

"iconUrl": "https://georoute-agent.example.com/icon.png",
"documentationUrl": "https://docs.examplegeoservices.com/georoute-agent/api",
"supportsAuthenticatedExtendedCard": true

3.3.  Agent Card Issuance

   Agent Cards are issued by trusted Agent Registries, the details of
   the which are out of scope of this specification

3.3.1.  Issuance Process Overview

   1.  Agent Registration: The agent registers with the Agent Registry,
       providing its capabilities, endpoints, and authentication
       information.  This includes submitting detailed metadata about
       the agent's functions, operational requirements, and security
       capabilities.

   2.  Identity Verification: The Agent Registry verifies the agent's
       identity and authorization to claim the specified capabilities.

   3.  Agent Card Creation: The Agent Registry creates an SD-JWT Agent
       Card containing the agent's metadata with appropriate claims
       marked for selective disclosure.  The registry determines which
       claims should be selectively disclosable based on authorization,
       privacy policies and security requirements.

   4.  Batch Issuance: Multiple Agent Cards with different disclosure
       configurations may be issued for different discovery contexts.
       This enables the same agent to interact in various contexts while
       maintaining privacy and unlinkability.

   Example issuance request based on HTTP POST method with bearing token
   is shown below:



Nandakumar & Jennings     Expires 22 April 2026                [Page 20]

Internet-Draft                Agent-SD-JWT                  October 2025


   POST /agents/register HTTP/1.1
   Host: registry.example.com
   Content-Type: application/json
   Authorization: Bearer <registry_auth_token>

   {
     "agent_id": "ai-assistant-v2",
     "name": "AI Assistant Agent",
     "description": "General purpose AI assistant",
     "version": "2.1.0",
     "public_key": {
       "kty": "EC",
       "crv": "P-256",
       "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
       "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
     },
     "disclosure_contexts": [
       {
         "context": "public",
         "disclose": ["skills", "endpoints", "operational_info"]
       },
       {
         "context": "internal",
         "disclose": ["skills", "endpoints", "operational_info",
                      "provider", "security_context"]
       },
       {
         "context": "diagnostic",
         "disclose": ["operational_info", "provider"]
       }
     ]
   }

4.  Agent Discovery Protocols with Privacy Protection

   This section describes the protocols and mechanisms for discovering
   agents:

4.1.  Well-Known URI Discovery

   The well-known URI discovery mechanism is extended to support SD-JWT
   Agent Cards:

   GET /.well-known/agent.json HTTP/1.1
   Host: agent.example.com
   Accept: application/vnd.sd-jwt+json





Nandakumar & Jennings     Expires 22 April 2026                [Page 21]

Internet-Draft                Agent-SD-JWT                  October 2025


   The application/vnd.sd-jwt+json media type indicates that the client
   accepts responses containing Selective Disclosure JWT data formatted
   as JSON.  In the examples below, the "agent_card" field contains an
   SD-JWT formatted according to the Agent Card Structure defined in
   Section 3.1.

   The response contains an SD-JWT Agent Card with context-appropriate
   disclosures.

   HTTP/1.1 200 OK
   Content-Type: application/vnd.sd-jwt+json

   {
     "agent_card": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJod...~WyJzYWx0I
   iwibmFtZSIsIkFJIEFzc2lzdGFudCJd~WyJzYWx0MiIsImVuZHBvaW50cyIsW3sibmFtZSI6InByaW1h
   cnkiLCJ1cmwiOiJodHRwczovL2FnZW50LmV4YW1wbGUuY29tL2FwaS92MSJ9XV0~"
   }

   For privacy-sensitive discovery, the agent MAY require authentication
   before revealing the Agent Card:

   GET /.well-known/agent.json HTTP/1.1
   Host: agent.example.com
   Authorization: Bearer <discovery_token>
   Accept: application/vnd.sd-jwt+json

4.2.  Registry-Based Discovery

   Agent Registries support discovery with context-based selective
   disclosure.  In the example below, an agent is discovered based on
   the skill "route-optimizer-traffic".

   POST /agents/discover HTTP/1.1
   Host: registry.example.com
   Content-Type: application/json
   Authorization: Bearer <registry_access_token>

   {
     "query": {
       "skills": ["route-optimizer-traffic"],
       "availability": "24/7"
     },
     "context": "public",
     "max_results": 10
   }






Nandakumar & Jennings     Expires 22 April 2026                [Page 22]

Internet-Draft                Agent-SD-JWT                  October 2025


4.3.  Contextual Discovery

   Discovery can be performed with different contexts to control the
   level of information disclosure:

   Public Context:  Minimal information suitable for public discovery,
      including basic skills and public endpoints.

   Internal Context:  Additional operational details for internal
      organizational use.

   Diagnostic Context:  Detailed technical information for
      troubleshooting and monitoring.

   Federation Context:  Inter-organizational discovery with appropriate
      trust relationships.

   The same agent may present different Agent Cards for different
   contexts while maintaining unlinkability between presentations.

5.  Cryptographic Authentication and Capability-Based Authorization

   SD-Card provides enhanced authentication and authorization mechanisms
   through SD-JWT integration with cryptographic key binding.  This
   section details the complete authentication flow, key binding
   mechanisms, and capability-based authorization processes that ensure
   secure agent interactions.

5.1.  SD-JWT with Key Binding

   Selective Disclosure JWT (SD-JWT) with Key Binding is a security
   mechanism that enables privacy-preserving authentication.

   An SD-JWT consists of three main parts separated by tildes (~):

   1.  Issuer-Signed JWT: Contains the base claims and selective
       disclosure metadata

   2.  Disclosure Arrays: Base64url-encoded arrays containing the salt
       and claim data

   3.  Key Binding JWT (KB-JWT): Proves possession of the confirmation
       key

 SD-JWT Format:
 <Issuer-Signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Key Binding JWT>





Nandakumar & Jennings     Expires 22 April 2026                [Page 23]

Internet-Draft                Agent-SD-JWT                  October 2025


   Key binding cryptographically proves that the presenter of an SD-JWT
   possesses the private key corresponding to the public key specified
   in the cnf (confirmation) claim of the SD-JWT.  This mechanism:

   1.  Selective Disclosure: Only relevant claims are revealed to the
       verifier

   2.  Cryptographic Binding: Proof of possession of a private key

   3.  Unlinkable Presentations: Different interactions cannot be
       correlated

   4.  Replay Protection: Each presentation is unique and time-bound

5.2.  Agent Authentication Process

   The agent authentication process involves multiple cryptographic
   steps to ensure secure and verifiable identity establishment:

5.2.1.  Step 1: Agent Card Presentation

   The agent presents its SD-JWT Agent Card with context-appropriate
   selective disclosures.  The "agent_card" field contains an SD-JWT
   generated from the following raw input structure:

   _Raw Input Structure:_

   The agent_card field is generated from the following base agent
   information:






















Nandakumar & Jennings     Expires 22 April 2026                [Page 24]

Internet-Draft                Agent-SD-JWT                  October 2025


   {
     "iss": "https://registry.example.com",
     "sub": "agent:ai-assistant-v2",
     "iat": 1704063600,
     "exp": 1735685999,
     "vct": "urn:ietf:params:oauth:token-type:sd-a2a-agent-card",
     "_sd_alg": "sha-256",
     "_sd": [
       "kV7i-VgPK9Qj8vYNJ4L8hFG3cR9ZqX2mE5wC6oA1nBs", // skills digest
       "3sdf8mN2p9uX7L3vE8nGrR5kW6oF4tC9jL7vM2nX8qE"  // endpoints digest
     ],
     "name": "AI Assistant Agent",
     "description": "General purpose AI assistant",
     "version": "2.1.0",
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",
         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
       }
     }
   }

   _Selective Disclosures:_

   *  skills: ["salt1","skills",[{"name":"text-generation"}]]

   *  endpoints: ["salt2","endpoints",[{"name":"primary"}]]

   Resulting SD-JWT Presentation:

{
}

5.2.2.  Step 2: Key Binding JWT Creation

   The agent creates a Key Binding JWT (KB-JWT) to prove possession of
   the private key.  The KB-JWT structure includes:

   _KB-JWT Header:_

   {
     "alg": "ES256",
     "typ": "kb+jwt"
   }




Nandakumar & Jennings     Expires 22 April 2026                [Page 25]

Internet-Draft                Agent-SD-JWT                  October 2025


   _KB-JWT Payload:_

   {
     "iat": 1704063600,
     "aud": "client.example.com",
     "sd_hash": "Kt7QqNZBzqnJKVQ4hbSIirsVfuecCE6t4jT9F2HZQ",
     "interaction_id": "12345678-1234-1234-1234-123456789abc",
     "nonce": "random-nonce-value-12345"
   }

   where,

   *  iat: Issued at time - prevents replay attacks

   *  aud: Audience - identifies the intended recipient

   *  sd_hash: Hash of the SD-JWT presentation (binds KB-JWT to specific
      presentation)

   *  interaction_id: Unique interaction identifier - prevents cross-
      session attacks

   *  nonce: Optional random value - adds additional replay protection

5.2.3.  Step 3: Cryptographic Verification

   The client performs comprehensive verification:

   1.  Agent Card Signature Verification: Validates the issuer's
       signature

   2.  Disclosure Verification: Confirms disclosed claims match their
       digests

   3.  Key Binding Verification: Validates the KB-JWT signature using
       the agent's public key

   4.  Temporal Validation: Checks expiration and freshness of
       timestamps

   5.  Audience Validation: Ensures the KB-JWT is intended for this
       client

5.3.  Advanced Authorization Flows

   TODO: Add text on how a query can be performed based on Agent's
   capabilities various authorization contexts, such as public,
   internal, diagnostic, and federation contexts, roles base discovery.



Nandakumar & Jennings     Expires 22 April 2026                [Page 26]

Internet-Draft                Agent-SD-JWT                  October 2025


6.  Complete SD-JWT and Key Binding Examples

   This section provides comprehensive examples of SD-JWT
   transformations and key binding processes for A2A Agent Cards,
   demonstrating input formats, selective disclosure transformations,
   and the complete authentication flow.

   *Implementation Note*: Complete source code implementing all examples
   in this specification can be found in the examples/ directory of the
   repository.

6.1.  SD-JWT Agent Card Creation Process

6.1.1.  Step 1: Original A2A Agent Card (Input)

   Starting with a complete A2A Agent Card as defined in the
   specification:

   {
     "protocolVersion": "0.2.9",
     "name": "GeoSpatial Route Planner Agent",
     "description": "Provides advanced route planning, traffic analysis, and custom map generation services",
     "url": "https://georoute-agent.example.com/a2a/v1",
     "preferredTransport": "JSONRPC",
     "additionalInterfaces": [
       {"url": "https://georoute-agent.example.com/a2a/v1", "transport": "JSONRPC"},
       {"url": "https://georoute-agent.example.com/a2a/grpc", "transport": "GRPC"},
       {"url": "https://georoute-agent.example.com/a2a/json", "transport": "HTTP+JSON"}
     ],
     "provider": {
       "organization": "Example Geo Services Inc.",
       "url": "https://www.examplegeoservices.com"
     },
     "iconUrl": "https://georoute-agent.example.com/icon.png",
     "version": "1.2.0",
     "documentationUrl": "https://docs.examplegeoservices.com/georoute-agent/api",
     "capabilities": {
       "streaming": true,
       "pushNotifications": true,
       "stateTransitionHistory": false
     },
     "securitySchemes": {
       "google": {
         "type": "openIdConnect",
         "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration"
       }
     },
     "security": [{"google": ["openid", "profile", "email"]}],



Nandakumar & Jennings     Expires 22 April 2026                [Page 27]

Internet-Draft                Agent-SD-JWT                  October 2025


     "defaultInputModes": ["application/json", "text/plain"],
     "defaultOutputModes": ["application/json", "image/png"],
     "skills": [
       {
         "id": "route-optimizer-traffic",
         "name": "Traffic-Aware Route Optimizer",
         "description": "Calculates the optimal driving route between two or more locations",
         "tags": ["maps", "routing", "navigation", "directions", "traffic"],
         "examples": [
           "Plan a route from '1600 Amphitheatre Parkway, Mountain View, CA' to 'San Francisco International Airport' avoiding tolls."
         ],
         "inputModes": ["application/json", "text/plain"],
         "outputModes": ["application/json", "application/vnd.geo+json", "text/html"]
       },
       {
         "id": "custom-map-generator",
         "name": "Personalized Map Generator",
         "description": "Creates custom map images or interactive map views",
         "tags": ["maps", "customization", "visualization", "cartography"],
         "examples": [
           "Generate a map of my upcoming road trip with all planned stops highlighted."
         ],
         "inputModes": ["application/json"],
         "outputModes": ["image/png", "image/jpeg", "application/json", "text/html"]
       }
     ],
     "supportsAuthenticatedExtendedCard": true
   }

6.1.2.  Step 2: SD-JWT Transformation with Selective Disclosure

   The Agent Registry transforms this into an SD-JWT with selective
   disclosure markers.  The Issuer-Signed JWT contains base claims and
   selective disclosure digests:

6.1.2.1.  Issuer-Signed JWT Header:

   {
     "alg": "ES256",
     "typ": "JWT"
   }

6.1.2.2.  Issuer-Signed JWT Payload:








Nandakumar & Jennings     Expires 22 April 2026                [Page 28]

Internet-Draft                Agent-SD-JWT                  October 2025


   {
     "iss": "https://registry.example.com",
     "sub": "agent:georoute-planner-v1",
     "iat": 1704063600,
     "exp": 1735685999,
     "vct": "urn:ietf:params:oauth:token-type:sd-agent-card",
     "_sd_alg": "sha-256",
     "_sd": [
       "kV7i-VgPK9Qj8vYNJ4L8hFG3cR9ZqX2mE5wC6oA1nBs",
       "7iF2sM8kT5nL9pX3cV6zR4qW1eY8oU0jH3vB7nM2kF9",
       "3bN8mL5qR7kX9jV2cF6zT4pW1eY8oU0jH3vB7nM2kG1",
       "5eQ2rP9sL3mX7jV2cF6zR4qW1eY8oU0jH3vB7nM2kH8",
       "1gM4oK7pT5nX9jV2cF6zT4pW1eY8oU0jH3vB7nM2kJ6",
       "9cV8jT2mP5rX7kV9jF6zT4pW1eY8oU0jH3vB7nM2kL4",
       "2hR6kW4nT7mX9jV2cF6zT4pW1eY8oU0jH3vB7nM2kN1"
     ],
     "protocolVersion": "0.2.9",
     "name": "GeoSpatial Route Planner Agent",
     "description": "Provides advanced route planning, traffic analysis, and custom map generation services",
     "url": "https://georoute-agent.example.com/a2a/v1",
     "version": "1.2.0",
     "defaultInputModes": ["application/json", "text/plain"],
     "defaultOutputModes": ["application/json", "image/png"],
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",
         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
       }
     }
   }

6.1.3.  Step 3: Disclosure Arrays for Selective Claims

   Each selectively disclosable claim is encoded as a separate
   disclosure array:

6.1.3.1.  Disclosure 1 - Skills:

   ["_26bc4LT-ac6q2KI6cBW5es", "skills", [{"id":"route-optimizer-traffic","name":"Traffic-Aware Route Optimizer","description":"Calculates the optimal driving route between two or more locations","tags":["maps","routing","navigation","directions","traffic"],"examples":["Plan a route from '1600 Amphitheatre Parkway, Mountain View, CA' to 'San Francisco International Airport' avoiding tolls."],"inputModes":["application/json","text/plain"],"outputModes":["application/json","application/vnd.geo+json","text/html"]},{"id":"custom-map-generator","name":"Personalized Map Generator","description":"Creates custom map images or interactive map views","tags":["maps","customization","visualization","cartography"],"examples":["Generate a map of my upcoming road trip with all planned stops highlighted."],"inputModes":["application/json"],"outputModes":["image/png","image/jpeg","application/json","text/html"]}]]

   Base64url encoded:


6.1.3.2.  Disclosure 2 - Additional Interfaces:




Nandakumar & Jennings     Expires 22 April 2026                [Page 29]

Internet-Draft                Agent-SD-JWT                  October 2025


   ["_3sdf8mN-2p9uX7L3vE8nGr", "additionalInterfaces", [{"url":"https://georoute-agent.example.com/a2a/v1","transport":"JSONRPC"},{"url":"https://georoute-agent.example.com/a2a/grpc","transport":"GRPC"},{"url":"https://georoute-agent.example.com/a2a/json","transport":"HTTP+JSON"}]]

6.1.3.3.  Disclosure 3 - Provider:

   ["_7kRt2qW-5mX9jN4cF7zPs", "provider", {"organization":"Example Geo Services Inc.","url":"https://www.examplegeoservices.com"}]

6.1.4.  Step 4: Complete SD-JWT Serialization

   The complete SD-JWT is serialized (truncated for readability):


7.  IANA Considerations

   TODO

8.  Security Considerations

   TODO

   {backmatter}

9.  References

9.1.  Normative References

   [A2A-SPEC] Project, A., "Agent-to-Agent Protocol Specification",
              Version 0.2.5, 2024,
              <https://a2aproject.github.io/A2A/v0.2.5/specification>.

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

   [SD-JWT]   Fett, D., Yasuda, K., and B. Campbell, "Selective
              Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-
              Draft, draft-ietf-oauth-selective-disclosure-jwt-22,
              November 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-oauth-selective-disclosure-jwt-22>.

9.2.  Informative References





Nandakumar & Jennings     Expires 22 April 2026                [Page 30]

Internet-Draft                Agent-SD-JWT                  October 2025


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

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

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

Authors' Addresses

   Suhas Nandakumar
   Cisco
   Email: snandaku@cisco.com


   Cullen Jennings
   Cisco
   Email: fluffy@cisco.com





























Nandakumar & Jennings     Expires 22 April 2026                [Page 31]

categories:
["Agent discovery / registration", "Identity / authentication for AI agents", "Agent-to-agent communication protocols"]


name: draft-campbell-agentic-http
rev: 00
title: A Best Current Practice for Agentic Interactions over HTTP
time: 2026-02-09T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-02-09T01:33:16Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420390+00:00
abstract:
This document describes a set of best practices for facilitating
   interactions between automated software agents (AI agents) using the
   Hypertext Transfer Protocol (HTTP).  As agentic systems proliferate,
   they frequently utilize HTTP in ad-hoc ways, leading to
   interoperability challenges and the rise of proprietary, "walled
   garden" ecosystems.  This document proposes a minimalist,
   standardized framework based on existing HTTP semantics to promote a
   more cohesive, efficient, and open ecosystem.  The primary
   recommendations codify the principles of the Agentic Hypercall
   Protocol (AHP), including tool invocation via GET requests, a
   stateless authentication scheme, and the formalization of the 402
   (Payment Required) status code to enable a native economic layer for
   the machine economy.

full_text:
Network Working Group                                        K. Campbell
Internet-Draft                                         DeepBlue Dynamics
Intended status: Best Current Practice                       August 2025
Expires: 8 February 2026


       A Best Current Practice for Agentic Interactions over HTTP
                     draft-campbell-agentic-http-00

Abstract

   This document describes a set of best practices for facilitating
   interactions between automated software agents (AI agents) using the
   Hypertext Transfer Protocol (HTTP).  As agentic systems proliferate,
   they frequently utilize HTTP in ad-hoc ways, leading to
   interoperability challenges and the rise of proprietary, "walled
   garden" ecosystems.  This document proposes a minimalist,
   standardized framework based on existing HTTP semantics to promote a
   more cohesive, efficient, and open ecosystem.  The primary
   recommendations codify the principles of the Agentic Hypercall
   Protocol (AHP), including tool invocation via GET requests, a
   stateless authentication scheme, and the formalization of the 402
   (Payment Required) status code to enable a native economic layer for
   the machine economy.

Status of This Memo

   This memo documents a Best Current Practice for the Internet
   community.  It does not specify an Internet standard of any kind.
   Distribution of this memo is unlimited.

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




Campbell                 Expires 8 February 2026                [Page 1]

RFC 9582                      Agentic HTTP                   August 2025


Copyright Notice

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

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

Table of Contents

   1.  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
   2.  2.  Core Protocol . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  2.1.  Tool Invocation . . . . . . . . . . . . . . . . . .   3
     2.2.  2.2.  Service Discovery . . . . . . . . . . . . . . . . .   3
   3.  3.  Authentication  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  3.1.  Step 1: Exchange Pre-Shared Key for a Bearer
           Token . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  3.2.  Step 2: Use Bearer Token for Tool Calls . . . . . .   4
   4.  4.  The Aperture Principle: A Native Economic Layer . . . . .   4
     4.1.  4.1.  The 402 Response Payload  . . . . . . . . . . . . .   4
     4.2.  4.2.  Client Behavior . . . . . . . . . . . . . . . . . .   5
   5.  5.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  6.  IANA Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  7.  Security Considerations . . . . . . . . . . . . . . . . .   5
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  1.  Introduction

   Autonomous software agents increasingly rely on HTTP to interact with
   external tools and services.  However, the lack of a standardized
   interaction pattern has resulted in a fragmented landscape where each
   service requires a bespoke integration, often demanding fealty to a
   complex SDK or proprietary middleware.  This trend risks creating a
   new "tyranny of the SDK," carving the nascent machine economy into
   walled gardens that stifle innovation and interoperability.









Campbell                 Expires 8 February 2026                [Page 2]

RFC 9582                      Agentic HTTP                   August 2025


   This document outlines a Best Current Practice (BCP) for designing
   agent-facing services that rejects this contrived complexity and
   returns to first principles.  It leverages the fundamental simplicity
   and robustness of HTTP as the primal protocol for agentic
   interaction.  The goal is to reduce complexity, eliminate the need
   for heavyweight SDKs, and foster an open, federated ecosystem where
   the agent is treated as the primary user.

   These recommendations codify the successful patterns of the Agentic
   Hypercall Protocol (AHP), which serves as the reference
   implementation for this BCP.

   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 BCP 14, RFC 2119.

2.  2.  Core Protocol

   The core principle of this BCP is the Agentic Hypercall: a simple,
   RESTful pattern for tool invocation.

   |  All actions are GET requests.  Tools are paths.  Parameters are
   |  query strings.
   |  
   |     https://github.com/kordless/gnosis-ahp/blob/main/MANIFESTO.md

2.1.  2.1.  Tool Invocation

   To ensure safety, predictability, and cacheability, services intended
   for agentic consumption MUST expose all idempotent, read-only, or
   state-retrieving actions as HTTP GET methods.  The specific tool to
   be invoked MUST be identified by the URI path.  All parameters
   required for the action MUST be passed as URL query string
   parameters.

2.2.  2.2.  Service Discovery

   To facilitate automated discovery of available tools, agent-facing
   servers MUST provide a machine-readable definition of their services.
   It is RECOMMENDED that an OpenAPI 3.0+ specification be made
   available at a stable, well-known URI path, such as `/openapi` or
   `/.well-known/openapi.json`.

3.  3.  Authentication

   To secure protected resources, this BCP recommends a two-step,
   stateless authentication scheme.




Campbell                 Expires 8 February 2026                [Page 3]

RFC 9582                      Agentic HTTP                   August 2025


3.1.  3.1.  Step 1: Exchange Pre-Shared Key for a Bearer Token

   An agent MUST first obtain a temporary bearer token by making a GET
   request to a dedicated authentication endpoint (e.g., `/auth`).  This
   request MUST include a pre-shared key, provided by the human user, as
   a query parameter (e.g., `?token=USER_PROVIDED_KEY`).

   The server MUST validate this key.  Upon success, it MUST return a
   JSON object containing the temporary `bearer_token`.

3.2.  3.2.  Step 2: Use Bearer Token for Tool Calls

   For all subsequent calls to protected tool endpoints, the agent MUST
   include the `bearer_token` as a query parameter.

   The bearer token SHOULD be a stateless, signed token (e.g., a
   simplified JWT) containing claims such as an agent identifier and an
   expiration timestamp.  This allows any server in a federated system
   to verify the token without needing access to a central token store.

4.  4.  The Aperture Principle: A Native Economic Layer

   A tool has intrinsic value.  To foster a healthy and honest market
   for digital services, this BCP proposes the "Aperture Principle": a
   tool can declare its own cost, and the network must honor it.  This
   is achieved by formalizing the use of the `402 (Payment Required)`
   status code.

4.1.  4.1.  The 402 Response Payload

   When an agent requests a resource that requires payment, the server
   SHOULD return a 402 status code.  The response body **MUST** be a
   JSON object containing details of the required payment.

   The JSON object SHOULD contain the following keys:

   *  `cost`: A string representing the decimal amount required for the
      service.

   *  `currency`: A string identifying the ledger or currency type
      (e.g., "USD", "EUR", "BTC-LN").

   *  `destination`: A string containing the payment address or invoice.
      For Bitcoin's Lightning Network, this would be the BOLT 11
      invoice.

   *  `description`: A human-readable string explaining the charge
      (OPTIONAL).



Campbell                 Expires 8 February 2026                [Page 4]

RFC 9582                      Agentic HTTP                   August 2025


   Example 402 Response for Bitcoin Lightning Network:

   HTTP/1.1 402 Payment Required
   Content-Type: application/json

   {
     "cost": "100",
     "currency": "BTC-LN",
     "destination": "lnbc10u1p3z2y7xpp5j3c2y...",
     "description": "API call to /longer_qr_code"
   }

4.2.  4.2.  Client Behavior

   Upon receiving a 402 response, an agent can parse the body to decide
   if the cost is acceptable and if it possesses the means to pay.  If
   it proceeds, it can then retry the original HTTP GET request,
   including proof of payment as specified by the service (e.g., in a
   new `Authorization` header or as a query parameter like
   `invoice_id`).

5.  5.  Rationale

   Standardizing these simple patterns provides immense benefits.  It
   lowers the barrier to entry for new tool creators, allows agents to
   seamlessly switch between service providers, and creates a
   transparent, native economic layer for the machine economy.  By
   formalizing the use of the 402 code, we avoid the need for complex,
   out-of-band billing APIs and instead embed commerce directly into the
   protocol where it belongs, fostering a federated world of sovereign,
   interoperable nodes.

6.  6.  IANA Considerations

   This BCP recommends a specific structure for the payload of an HTTP
   402 response.  Future work may propose the creation of a registry for
   common "currency" identifiers to promote interoperability between
   different payment systems.

7.  7.  Security Considerations

   Service providers must protect against denial-of-service attacks and
   validate all inputs from agents.  Agents must protect their payment
   credentials and verify the identity of the services they interact
   with, typically via TLS.  The stateless bearer token scheme is the
   RECOMMENDED method for securing protected resources.

8.  Informative References



Campbell                 Expires 8 February 2026                [Page 5]

RFC 9582                      Agentic HTTP                   August 2025


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

Author's Address

   Kord Campbell
   DeepBlue Dynamics
   United States of America
   Email: kordless@gmail.com








































Campbell                 Expires 8 February 2026                [Page 6]

categories:
["Agent-to-agent communication protocols", "Identity / authentication for AI agents", "Agent discovery / registration"]


name: draft-wahl-scim-agent-schema
rev: 01
title: System for Cross-domain Identity Management: Agentic Identity Schema
time: 2026-02-20T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-02-20T01:45:51Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Identity / authentication for AI agents", "Agent discovery / registration"]
tags: []
fetched_at: 2026-02-27T22:56:03.420393+00:00
abstract:
The System for Cross-domain Identity Management (SCIM) specifications
   are designed to make identity management in cloud-based applications
   and services easier.

   This document provides a platform-neutral schema for representing AI
   agents' identities in JSON format, enabling them to be transferred in
   the SCIM protocol to the service.  This establishes an agentic
   identity so that an agent can subsequently be authenticated and
   authorized to interact with the service.

full_text:
System for Cross-domain Identity Management                      M. Wahl
Internet-Draft                                                 Microsoft
Intended status: Informational                            19 August 2025
Expires: 20 February 2026


  System for Cross-domain Identity Management: Agentic Identity Schema
                    draft-wahl-scim-agent-schema-01

Abstract

   The System for Cross-domain Identity Management (SCIM) specifications
   are designed to make identity management in cloud-based applications
   and services easier.

   This document provides a platform-neutral schema for representing AI
   agents' identities in JSON format, enabling them to be transferred in
   the SCIM protocol to the service.  This establishes an agentic
   identity so that an agent can subsequently be authenticated and
   authorized to interact with the service.

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-wahl-scim-agent-schema/.

   Discussion of this document takes place on the System for Cross-
   domain Identity Management Working Group mailing list
   (mailto:scim@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/scim/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/scim/.

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



Wahl                    Expires 20 February 2026                [Page 1]

Internet-Draft              SCIM Agent Schema                August 2025


   This Internet-Draft will expire on 20 February 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 . . . . . . . . . . . . . . . . .   3
   3.  SCIM Schema for Agentic Identity  . . . . . . . . . . . . . .   3
     3.1.  Single-valued Attributes  . . . . . . . . . . . . . . . .   4
     3.2.  Multi-valued Attributes . . . . . . . . . . . . . . . . .   5
     3.3.  AgenticIdentity Resource Schema . . . . . . . . . . . . .   6
     3.4.  Updates to Existing Schema  . . . . . . . . . . . . . . .   7
   4.  Operations on an Agentic Identity . . . . . . . . . . . . . .   8
     4.1.  Agentic Identity Creation . . . . . . . . . . . . . . . .   8
     4.2.  Agentic Identity Retrieval  . . . . . . . . . . . . . . .   9
     4.3.  Agentic Identity Updates  . . . . . . . . . . . . . . . .   9
     4.4.  Update Group Membership of an Agentic Identity  . . . . .   9
     4.5.  Agentic Identity Deletion . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     5.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  New Schema  . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Changes From Earlier Versions  . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12










Wahl                    Expires 20 February 2026                [Page 2]

Internet-Draft              SCIM Agent Schema                August 2025


1.  Introduction

   The SCIM protocol [RFC7644] and core schema [RFC7643] are widely
   implemented for provisioning records for users into services.  The
   default schema for those user records includes attributes such as a
   person's name, their desired group memberships, and a password that
   the user.  This enables a SCIM client to inform a SCIM server
   component of a service of a new user, so that user can be identified
   in and subsequently authenticated to the service.  SCIM also enables
   lifecycle controls for the SCIM client to update and remove that user
   record in that service, and associate that user with groups, roles
   and entitlements.

   With the growth of agentic AI, agents will also need to be able to
   interact with services.  Some services will require an agent to have
   identities represented in those services.  The attributes of an agent
   identity in a SCIM server can be different from the attributes of a
   human user identity.  Some services allow OAuth [RFC6749] protocols
   such as token exchange [RFC8693] for an agent's authentication to the
   service, without needing a shared secret credential between each
   agent and the service.  However, similar to users, an agent's
   identity might have access rights in the service, represented through
   relationships of the agent's identity with groups, roles and
   entitlements in a service.

   As SCIM is familiar within the enterprise and agents often need the
   same lifecycle signals and group, role or entitlement memberships as
   users, defining a schema to transport agentic identities in the SCIM
   protocol simplifies deployment and enables subsequent authentication
   interactions, consistent controls for those agent's identities and
   access rights.

2.  Conventions and Definitions

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

3.  SCIM Schema for Agentic Identity

   As an extension to SCIM schema, [RFC7643] sections 3.2 and 3.3, this
   specification includes one new resource type:







Wahl                    Expires 20 February 2026                [Page 3]

Internet-Draft              SCIM Agent Schema                August 2025


   *  AgenticIdentity: A resource of this type represents an identity of
      an agent to the service.  It includes attributes of an agentic
      identity needed to be known by a service, including OPTIONAL
      references to the agentic identity's group memberships, roles and
      entitlements.

   Resources of this type are conveyed in the SCIM protocol [RFC7644]
   using JSON [RFC8259].  Extension schemas can be defined to extend
   this resource type, allowing additional attributes.

3.1.  Single-valued Attributes

   The resource type AgenticIdentity has the following single-valued
   attributes.  A SCIM server which implements the Agentic Identity
   schema MUST recognize these attributes.

   *  active: A boolean value indicating the agentic identity's
      administrative status.  If absent, then an agentic identity is
      assumed to be active.  A SCIM client can indicate that an agentic
      identity is inactive by setting it to false.  The definitive
      meaning of this attribute is determined by the SCIM server.
      Support for this attribute in a SCIM client is OPTIONAL.

   *  agenticApplicationId: The value of this attribute is a string with
      the id of an agentic application, that is assigned by the SCIM
      client, enabling correlation and reporting in the service for an
      agentic application that has multiple identities.  The attribute
      MAY be included when the AgenticIdentity is created.  The
      definitive meaning of this attribute is determined by the SCIM
      client.  Support for this attribute in a SCIM client is OPTIONAL.

   *  description: The value of this attribute is a string with the
      agentic identity's human-readable description.  Support for this
      attribute in a SCIM client is OPTIONAL.

   *  displayName: The value of this attribute is a string with the
      human-readable name of the agentic identity, suitable for display
      to end-users.  Support for this attribute in a SCIM client is
      RECOMMENDED.

   In addition, the AgenticIdentity also has the attributes
   "externalId", "id", "meta" and "schemas", as described in sections 3
   and 3.1 of [RFC7643].








Wahl                    Expires 20 February 2026                [Page 4]

Internet-Draft              SCIM Agent Schema                August 2025


3.2.  Multi-valued Attributes

   The resource type AgenticIdentity has the following multi-valued
   attributes.  A SCIM server which implements the Agentic Identity
   schema SHOULD recognize the attributes "entitlements", "groups",
   "owners" and "roles".  A SCIM server in a service that also supports
   OAuth token exchange [RFC8693] for agent authentication SHOULD
   recognize the attribute "oAuthClientIdentifiers".

   *  entitlements: A list of entitlements for the agentic identity that
      represent a thing the agentic identity has.  This attribute is
      analogous to the "entitlements" attribute of a user as described
      in section 4.1.2 of [RFC7643].

   *  groups: A list of groups to which the agentic identity belongs,
      either through direct membership, through nested groups, or
      dynamically calculated.  This attribute is analogous to the
      "groups" attribute of a user as described in section 4.1.2 of
      [RFC7643].

   *  oAuthClientIdentifiers: Each value of the attribute is a complex
      type that describes the OAuth parameters of an agentic identity,
      for agentic identities that will be authenticating to a service
      using OAuth token exchange [RFC8693].  Support for this attribute
      is OPTIONAL.  This attribute has six string-valued sub-attributes.

      -  audiences: The values of this sub-attribute MAY be present.
         They are included by the SCIM server in a POST, GET or other
         response.  The format of each value is defined as that of the
         "aud" claim of section 4.1.3 of [RFC7519].

      -  clientId: The value of this sub-attribute is a client
         identifier, as described of section 2.2 of [RFC6749].  It is
         returned by the SCIM server.  They are included by the SCIM
         server in a POST, GET or other response.

      -  description: An OPTIONAL human-readable string that further
         describes the oAuth client identity.

      -  issuer: The identity of the identity provider of the agent.
         The format of the value is defined as that of "iss" claim of
         section 4.1.1 of [RFC7519].

      -  name: A human-readable name for the OAuth client identity that
         will be be used by the agent.






Wahl                    Expires 20 February 2026                [Page 5]

Internet-Draft              SCIM Agent Schema                August 2025


      -  subject: The identifier of the agent within the identity
         provider.  The format of the value is defined as that of the
         "sub" claim of section 4.1.2 of [RFC7519].

   *  owners: A list of the responsible parties for an agentic identity.
      Each value is a complex type that allows referencing the "id"
      attribute of a user, a group or other resource already known to
      the SCIM server.  Each value has the following three string sub-
      attributes.

      -  value: The "id" of the SCIM resource representing the an owner
         of an agentic identity.  RECOMMENDED.

      -  $ref: The URI of the SCIM resource representing an owner of an
         agentic identity.  RECOMMENDED.

      -  displayName: The displayName of the agentic identity's owner.
         This attribute is OPTIONAL, and mutability is "readOnly".

   *  roles: A list of roles for the agentic identity.  This attribute
      is analogous to the "roles" attribute of a user as described in
      section 4.1.2 of [RFC7643].

3.3.  AgenticIdentity Resource Schema

   The AgenticIdentity resource type is for Agentic identity resources.
   The schema for AgenticIdentity is identified using the following
   schema URI: "urn:ietf:params:scim:schemas:core:2.0:AgenticIdentity".

   The following is a non-normative example of the SCIM schema
   representation of an agentic identity in JSON format.  Long URL
   values have been trimmed for formatting.



















Wahl                    Expires 20 February 2026                [Page 6]

Internet-Draft              SCIM Agent Schema                August 2025


     {
      "schemas":[
        "urn:ietf:params:scim:schemas:core:2.0:AgenticIdentity"
      ],
      "id": "95cfaafb-0827-4c60-8236-523ad04b3cba",
      "agenticApplicationId":"8bb1afd8-ae68-40cf-8d53-c7f39ad3d0db",
      "displayName":"Agent for tour guides",
      "externalId":"67890",
      "oAuthClientIdentifiers":[
        {
            "audiences":["https://api.example.com"],
            "issuer":"https://oidc.example.com",
            "name":"an agent",
            "subject":"agent",
            "description":"An agent",
            "clientId": "c002"
        }
       ],
      "groups":[
       {
         "value": "e9e30dba-f08f-4109-8486-d5c6a331660a",
         "$ref":"https://example.com/v2/Groups/e9e...-d5c6a331660a",
         "display": "Tour Guides"
       },
       {
         "value": "9ce138e5-7296-4e3a-94a0-1ea8ce6d6aff",
         "$ref": "https://example.com/v2/Groups/9ce1...-1ea8ce6d6aff",
         "display": "Agentic identities"
       }
       ],
      "meta": {
        "resourceType":"AgenticIdentity"
      }
     }

3.4.  Updates to Existing Schema

   To allow an agentic identity to be a member of a group, this memo
   augments the definition of the "members" attribute of [RFC7643] as
   follows:

   *  allow the referenceTypes of the members "$ref" sub-attribute to
      also refer to an AgenticIdentity

   *  allow the canonicalValues of the members "type" sub-attribute to
      also allow for "AgenticIdentity"





Wahl                    Expires 20 February 2026                [Page 7]

Internet-Draft              SCIM Agent Schema                August 2025


4.  Operations on an Agentic Identity

   A SCIM client and SCIM server exchange agentic identity resources
   using the SCIM protocol of section 3 of [RFC7644].  Support for bulk
   operations, as described in section 3.7 of [RFC7644] is OPTIONAL.
   How the SCIM client authenticates to the SCIM server and is
   authorized by the SCIM server to perform protocol operations for
   agentic identities is outside the scope of this document.

   The following is a non-normative example of a SCIM client using two
   SCIM operations, to create an agentic identity record in the SCIM
   server and then add the agentic identity to a group, and then using a
   SCIM operation to remove that agentic identity from the SCIM server.

   SCIM                                                     SCIM
   client                                                 server

         POST /AgenticIdentities
         { "displayName":"Agent for tour guides", ...}
         --------------------------------------------->
         201 Created
         { "id": "95c...", ...}
         <---------------------------------------------

         PATCH /Groups/acbf...-9b4da3f908ce
         { "Operations":[ {"op":"add", "path":"members", ... }]}
         --------------------------------------------->
         200 OK
         <---------------------------------------------

      ...
         DELETE /AgenticIdentities/95c...
         --------------------------------------------->
         204 No Content
         <---------------------------------------------

4.1.  Agentic Identity Creation

   To inform a service of an agent's identity, a SCIM client sends a
   POST request containing a "AgenticIdentity" to the
   "/AgenticIdentities" endpoint.  The POST request MUST include the
   following attributes "schemas" and MAY include the following
   attributes "externalId", "active", "agenticApplicationId",
   "description", "displayName", "entitlements",
   "oAuthClientIdentifiers", "owners", "roles".






Wahl                    Expires 20 February 2026                [Page 8]

Internet-Draft              SCIM Agent Schema                August 2025


   In response, a SCIM server signals successful creation with an HTTP
   status code 201 (Created) and returns a representation of the
   resource created.  The response MUST include the following attributes
   "id", and "meta".  In addition, if the request included the
   "oAuthClientIdentifiers" attribute, then values of the "issuer",
   "name" and "subject" sub-attributes MUST be included by the SCIM
   client in each attribute value, and the response MUST include the
   "oAuthClientIdentifiers" attribute.

4.2.  Agentic Identity Retrieval

   A SCIM client can retrieve an agentic identity resource using the
   patterns shown in [RFC7644] section 3.4.

4.3.  Agentic Identity Updates

   An agentic identity resource's attributes can be modified by a SCIM
   client using the patterns shown in [RFC7644] section 3.5.

   If the "oAuthClientIdentifiers" attribute is supplied by a SCIM
   client in a PUT or PATCH request to update an AgenticIdentity, then
   values of the "issuer", "name" and "subject" sub-attributes MUST be
   included by the SCIM client in each attribute value.

4.4.  Update Group Membership of an Agentic Identity

   A group membership of an agentic identity can be changed by a SCIM
   client updating the "members" of the group to add, remove or replace
   the agentic identity as one of the values.  The following is an
   example representation of a PATCH request for a group to add an
   agentic identity as a member, showing the basic JSON structure (non-
   normative):



















Wahl                    Expires 20 February 2026                [Page 9]

Internet-Draft              SCIM Agent Schema                August 2025


      PATCH /Groups/acbf3ae7-8463-...-9b4da3f908ce

      { "schemas":
          ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
        "Operations":[
          {
           "op":"add",
           "path":"members",
           "value":[
            {
              "display": "Agent for tour guides",
              "$ref":
      "https://example.com/v2/AgenticIdentities/95cfaafb...4b3cba",
              "value": "95cfaafb-0827-4c60-8236-523ad04b3cba"
            }
           ]
          }
        ]
      }

4.5.  Agentic Identity Deletion

   A SCIM client can retrieve an agentic identity resource using the
   patterns shown in [RFC7644] section 3.6.

5.  Security Considerations

   SCIM data is intended to be exchanged using the SCIM protocol.  It is
   important when handling data to implement the security considerations
   outlined in Section 7 of [RFC7644].

   When the agentic identity is intended to be used in subsequent OAuth
   interactions, the guidance from section 10 of [RFC6749] also applies,
   and when it is intended to be used with OAuth token exchange
   interactions, the guidance from section 5 of [RFC8693] also applies.

5.1.  Privacy

   The text of this privacy section is derived from the corresponding
   privacy section of [RFC7643].











Wahl                    Expires 20 February 2026               [Page 10]

Internet-Draft              SCIM Agent Schema                August 2025


   Information should be shared on an as-needed basis.  A SCIM client
   should limit information to what it believes a SCIM server requires,
   and a SCIM server should only accept information it needs.  Clients
   and servers should take into consideration that sensitive information
   is being conveyed across technical (e.g., protocol and applications),
   administrative (e.g., organizational, corporate), and jurisdictional
   boundaries.  In particular, information security and privacy must be
   considered.

   Security service level agreements for the handling of these
   attributes are beyond the scope of this document but are to be
   carefully considered by implementers and deploying organizations.

   Please see the Privacy Considerations section of [RFC7644] for more
   protocol-specific considerations regarding the handling of SCIM
   information.

6.  IANA Considerations

6.1.  New Schema

   When published as an RFC, the IANA is requested to add the following
   to the "SCIM Schema URIs for Data Resources" established in
   [RFC7643]:

   +====================================+==================+===========+
   | Schema URI                         | Name             | Reference |
   +====================================+==================+===========+
   | urn:ietf:params:scim:schemas:core: | Agentic          | This      |
   | 2.0:AgenticIdentity                | Identity         | memo,     |
   |                                    | Resource         | section 3 |
   +------------------------------------+------------------+-----------+

               Table 1: SCIM Schema URI for Agentic Identity

7.  References

7.1.  Normative References

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

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




Wahl                    Expires 20 February 2026               [Page 11]

Internet-Draft              SCIM Agent Schema                August 2025


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

   [RFC7643]  Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
              Mortimore, "System for Cross-domain Identity Management:
              Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
              2015, <https://www.rfc-editor.org/rfc/rfc7643>.

   [RFC7644]  Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
              and C. Mortimore, "System for Cross-domain Identity
              Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
              September 2015, <https://www.rfc-editor.org/rfc/rfc7644>.

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

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

7.2.  Informative References

   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8693>.

Appendix A.  Changes From Earlier Versions

   *  Changes in -01: Added missing page header and table labels; no
      protocol or data model changes.

   *  -00: Initial revision.

Acknowledgments

   The editor would like to acknowledge the contribution and work of the
   authors of the SCIM RFCs [RFC7643] and [RFC7644] and of other SCIM
   Internet-Drafts, the participants of the IETF SCIM WG, and the SCIM
   Community.

Author's Address

   Mark Wahl
   Microsoft



Wahl                    Expires 20 February 2026               [Page 12]

Internet-Draft              SCIM Agent Schema                August 2025


   Email: mwahl@microsoft.com


















































Wahl                    Expires 20 February 2026               [Page 13]


name: draft-ietf-sshm-ssh-agent
rev: 16
title: SSH Agent Protocol
time: 2026-02-24T18:01:56Z
group_uri: /api/v1/group/group/2430/
expires: 2026-08-24T04:00:18Z
ad: /api/v1/person/person/123703/
shepherd: /api/v1/person/email/job@sobornost.net/
categories: ["Identity / authentication for AI agents"]
tags: []
fetched_at: 2026-02-27T22:56:03.420395+00:00
abstract:
This document specifies a key agent protocol for use in the Secure
   Shell (SSH) protocol.

Note

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

   In the IANA considerations section, please replace "thisRFC" with
   "RFC" and the assigned number, when known.

states:
["/api/v1/doc/state/1/", "/api/v1/doc/state/103/", "/api/v1/doc/state/154/", "/api/v1/doc/state/115/", "/api/v1/doc/state/17/", "/api/v1/doc/state/117/", "/api/v1/doc/state/44/"]

full_text:
Internet Engineering Task Force                                D. Miller
Internet-Draft                                                   OpenSSH
Intended status: Standards Track                        19 February 2026
Expires: 23 August 2026


                           SSH Agent Protocol
                      draft-ietf-sshm-ssh-agent-16

Abstract

   This document specifies a key agent protocol for use in the Secure
   Shell (SSH) protocol.

Note

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

   In the IANA considerations section, please replace "thisRFC" with
   "RFC" and the assigned number, when known.

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

Copyright Notice

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

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



Miller                   Expires 23 August 2026                 [Page 1]

Internet-Draft             SSH Agent Protocol              February 2026


   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
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology and units . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Messages . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Generic agent responses . . . . . . . . . . . . . . . . .   5
     3.2.  Adding keys to the agent  . . . . . . . . . . . . . . . .   5
       3.2.1.  DSA keys  . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.2.  ECDSA keys  . . . . . . . . . . . . . . . . . . . . .   7
       3.2.3.  EDDSA keys  . . . . . . . . . . . . . . . . . . . . .   7
       3.2.4.  RSA keys  . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.5.  Other keys  . . . . . . . . . . . . . . . . . . . . .   8
       3.2.6.  Adding keys from a token  . . . . . . . . . . . . . .   8
       3.2.7.  Key Constraints . . . . . . . . . . . . . . . . . . .   9
     3.3.  Public key encoding . . . . . . . . . . . . . . . . . . .  10
     3.4.  Removing keys from the agent  . . . . . . . . . . . . . .  11
     3.5.  Requesting a list of keys . . . . . . . . . . . . . . . .  11
     3.6.  Private key operations  . . . . . . . . . . . . . . . . .  12
       3.6.1.  Signature flags . . . . . . . . . . . . . . . . . . .  13
     3.7.  Locking and unlocking an agent  . . . . . . . . . . . . .  13
     3.8.  Extension mechanism . . . . . . . . . . . . . . . . . . .  13
       3.8.1.  Query extension . . . . . . . . . . . . . . . . . . .  14
   4.  Connecting to an agent  . . . . . . . . . . . . . . . . . . .  15
   5.  Forwarding access to an agent . . . . . . . . . . . . . . . .  15
     5.1.  Advertising agent forwarding support  . . . . . . . . . .  15
     5.2.  Requesting agent forwarding . . . . . . . . . . . . . . .  16
     5.3.  Agent connection requests . . . . . . . . . . . . . . . .  16
   6.  Protocol numbers  . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Message type numbers  . . . . . . . . . . . . . . . . . .  17
       6.1.1.  Reserved message type numbers . . . . . . . . . . . .  18
     6.2.  Constraint identifiers  . . . . . . . . . . . . . . . . .  18
     6.3.  Signature flags . . . . . . . . . . . . . . . . . . . . .  18
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     7.1.  Guidance for Designated Experts . . . . . . . . . . . . .  19
     7.2.  New registry: SSH agent protocol message type numbers . .  19
     7.3.  New registry: SSH agent key constraint numbers  . . . . .  23
     7.4.  New registry: SSH agent key constraint extension names  .  23
     7.5.  New registry: SSH agent signature flags . . . . . . . . .  23
     7.6.  New registry: SSH agent extension request names . . . . .  24
     7.7.  Additions to SSH Extension Names  . . . . . . . . . . . .  24



Miller                   Expires 23 August 2026                 [Page 2]

Internet-Draft             SSH Agent Protocol              February 2026


     7.8.  Additions to SSH Connection Protocol Channel Request
           Names . . . . . . . . . . . . . . . . . . . . . . . . . .  25
     7.9.  Additions to SSH Connection Protocol Channel Types  . . .  25
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   9.  Implementation Status . . . . . . . . . . . . . . . . . . . .  27
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  28
     10.2.  Informative References . . . . . . . . . . . . . . . . .  29
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  30
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  31

1.  Introduction

   Secure Shell (SSH) [RFC4251] is a protocol for secure remote
   connections [RFC4253] and login [RFC4254] over untrusted networks.
   It supports multiple authentication mechanisms [RFC4252], including
   public key authentication.  This document specifies the protocol for
   interacting with a key management component, usually referred to as
   "an agent", that holds private keys.  SSH clients (and possibly SSH
   servers) can invoke the agent via this protocol to perform operations
   using public and private keys held in the agent.

   Holding keys in an agent offers usability and security advantages to
   loading and unwrapping them at each use, as each key unwrapping may
   require entry of a pass-phrase.  Access to an agent may optionally be
   forwarded across an SSH connection, thereby allowing remote systems
   to use stored keys without directly exposing the key material to the
   remote system.  Finally, the agent may be implemented as a dedicated
   component that presents a smaller attack surface than a key loaded
   into a full SSH server or client, and which may be subject to special
   protection from the wider system.

1.1.  Background

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

   This agent protocol is already widely used and a de-facto standard,
   having been implemented by a number of popular SSH clients and
   servers for many years.  The purpose of this document is to describe
   the protocol as it has been implemented.

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



Miller                   Expires 23 August 2026                 [Page 3]

Internet-Draft             SSH Agent Protocol              February 2026


2.  Protocol Overview

   The agent protocol is a packetised request-response protocol, solely
   driven by the client.  It consists of a number of requests sent from
   a client to an agent and a set of reply messages that are sent in
   response.  At no time does the agent send messages except in response
   to a client request.  Replies are sent in order.

   These requests include the ability to load keys into an agent, remove
   some or all keys from an agent and to perform signature operations
   using previously-loaded keys.

   Agents MAY implement support for only a subset of available key type
   and MAY additionally refuse some operations in particular contexts.
   For example, an agent may allow only clients local to itself to add
   keys, or may make particular subsets of keys available to a given
   client.  For this reason, clients of the agent SHOULD be prepared to
   fail gracefully if any operation is refused.

2.1.  Background

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

   Note that this protocol is separate to and incompatible with the one
   described in the similarly-named [draft-ietf-secsh-agent-02] which
   expired in 2004.

2.2.  Terminology and units

   Henceforth in this document, "agent" will be used to refer to a key
   management component that implements the responder side of this
   protocol.  "Client" will refer to a tool that implements the
   requester side of the protocol to communicate with an agent.  If it
   is pertinent that the client in question is a [RFC4251] Secure Shell
   client, then it will be explicitly referred to as an "SSH client".
   Similarly, "SSH server" will be used to refer to Secure Shell
   servers.

   All encoding data types ("byte", "uint32", "string", etc.) are as
   specified in Section 5 of [RFC4251].  Additionally, the type "byte[]"
   without a specified length within the square brackets indicates an
   unadorned sequence of zero or more bytes where the length is
   determined by context.

   All length units are given in bytes unless otherwise specified.






Miller                   Expires 23 August 2026                 [Page 4]

Internet-Draft             SSH Agent Protocol              February 2026


3.  Protocol Messages

   Messages consist of a length, type and contents.

       uint32            length
       byte              type
       byte[length - 1]  contents

   In the sections below, the "length" field is omitted.  For clarity,
   the symbolic names of the message types are shown; their numeric
   values are listed in Section 6.1 below.

3.1.  Generic agent responses

   The following generic messages may be sent by the agent in response
   to requests from the client.  On success the agent MUST reply either
   with the single-byte response:

       byte              SSH_AGENT_SUCCESS

   or a request-specific success message that may contain additional
   fields.  On failure, the agent MUST reply with the single-byte
   response:

       byte              SSH_AGENT_FAILURE

   or a request-specific failure message that may contain additional
   fields.  SSH_AGENT_FAILURE messages MUST also be sent in reply to
   requests with unknown or unsupported types.

3.2.  Adding keys to the agent

   Keys may be added to the agent using the SSH_AGENTC_ADD_IDENTITY or
   SSH_AGENTC_ADD_ID_CONSTRAINED messages.  The latter variant allows
   adding keys with optional constraints on their usage.

   The generic format for the SSH_AGENTC_ADD_IDENTITY message is:

       byte             SSH_AGENTC_ADD_IDENTITY
       string           key type
       byte[]           key data
       string           comment









Miller                   Expires 23 August 2026                 [Page 5]

Internet-Draft             SSH Agent Protocol              February 2026


   Here "key type" is the specified key type name, for example "ssh-rsa"
   for an RSA key as defined by [RFC4253].  "key data" consists of the
   public and private components of the key and varies by key type, as
   specified in subsections 3.2.1 through 3.2.4 for commonly used key
   types.  "comment" is a human-readable key name or comment as a UTF-8
   string that may serve to identify the key in user-visible messages.
   This string may be of zero length.

   The SSH_AGENTC_ADD_ID_CONSTRAINED message is similar, but adds an
   extra field:

       byte             SSH_AGENTC_ADD_ID_CONSTRAINED
       string           key type
       byte[]           key data
       string           comment
       constraint[]     constraints

   Constraints are used to place limits on the validity or use of keys.
   Section 3.2.7 details constraint types and their format.  Clients
   SHOULD prefer the SSH_AGENTC_ADD_IDENTITY message over sending an
   SSH_AGENTC_ADD_ID_CONSTRAINED with an empty constraints field, though
   both are valid and equivalent.

   An agent MUST reply with SSH_AGENT_SUCCESS if the key was
   successfully loaded as a result of one of these messages, or
   SSH_AGENT_FAILURE otherwise.

   Adding a key that is already present in an agent SHOULD replace any
   constraints it was previously loaded with those (if any) present in
   the subsequent add request, as this ensures that security-relevant
   constraints on a loaded key best match user expectations.  Otherwise
   an agent MAY refuse to load a key that has already been loaded.

   An agent MAY support only a subset of the key types defined here and
   MAY support additional key types as described below.  If an agent
   does not recognise the type name in a request to add a key, then it
   MUST respond with an SSH_AGENT_FAILURE reply.

3.2.1.  DSA keys

   DSA keys have key type "ssh-dss" and are defined in [RFC4253].  They
   may be added to the agent using the following message.  The
   "constraints" field is only present for the
   SSH_AGENTC_ADD_ID_CONSTRAINED message.







Miller                   Expires 23 August 2026                 [Page 6]

Internet-Draft             SSH Agent Protocol              February 2026


       byte             SSH_AGENTC_ADD_IDENTITY or
                        SSH_AGENTC_ADD_ID_CONSTRAINED
       string           "ssh-dss"
       mpint            p
       mpint            q
       mpint            g
       mpint            y
       mpint            x
       string           comment
       constraint[]     constraints

   The "p", "q", "g" values are the DSA domain parameters. "y" and "x"
   are the public and private keys respectively.  These values are as
   defined by Section 4.1 of [FIPS.186-4].

3.2.2.  ECDSA keys

   ECDSA keys have key types starting with "ecdsa-sha2-" and are defined
   in [RFC5656].  They may be added to the agent using the following
   message.  The "constraints" field is only present for the
   SSH_AGENTC_ADD_ID_CONSTRAINED message.

       byte             SSH_AGENTC_ADD_IDENTITY or
                        SSH_AGENTC_ADD_ID_CONSTRAINED
       string           key type
       string           ecdsa_curve_name
       string           Q
       mpint            d
       string           comment
       constraint[]     constraints

   The values "Q" and "d" are the ECDSA public and private values
   respectively.  Both are defined by Section 6.2 of [FIPS.186-5].

3.2.3.  EDDSA keys

   [RFC8709] defines Ed25519 and Ed448 with key type names "ssh-ed25519"
   and "ssh-ed448" respectively.  These may be added to the agent using
   the following message.  The "constraints" field is only present for
   the SSH_AGENTC_ADD_ID_CONSTRAINED message.

       byte             SSH_AGENTC_ADD_IDENTITY or
                        SSH_AGENTC_ADD_ID_CONSTRAINED
       string           "ssh-ed25519" or "ssh-ed448"
       string           ENC(A)
       string           k || ENC(A)
       string           comment
       constraint[]     constraints



Miller                   Expires 23 August 2026                 [Page 7]

Internet-Draft             SSH Agent Protocol              February 2026


   The first value is the EDDSA public key ENC(A).  The second value is
   a concatenation of the private key k and the public ENC(A) key (this
   redundant repetition of the public key is to maintain compatibility
   with widely deployed implementations).  The contents and
   interpretation of the ENC(A) and k values are defined by Section 3.2
   of [RFC8032].

3.2.4.  RSA keys

   RSA keys have key type "ssh-rsa" and are defined in [RFC4253].  They
   may be added to the agent using the following message.  The
   "constraints" field is only present for the
   SSH_AGENTC_ADD_ID_CONSTRAINED message.

       byte             SSH_AGENTC_ADD_IDENTITY or
                        SSH_AGENTC_ADD_ID_CONSTRAINED
       string           "ssh-rsa"
       mpint            n
       mpint            e
       mpint            d
       mpint            iqmp
       mpint            p
       mpint            q
       string           comment
       constraint[]     constraints

   "n" is the public composite modulus.  "e" is the public exponent.
   "d" is the private exponent.  "p" and "q" are its constituent private
   prime factors.  "iqmp" is the inverse of "q" modulo "p".  All these
   values except "iqmp" (which can be calculated from the others) are
   defined by Section 5.1 of [FIPS.186-5].

3.2.5.  Other keys

   Agents and their clients MAY support additional key types not
   documented here.  Vendor-specific key types MUST use the domain-
   qualified naming convention defined in Section 6 of [RFC4251] until
   code-points are allocated by IANA [IANA-PUBKEYS].

3.2.6.  Adding keys from a token

   Keys hosted on smart-cards or other hardware tokens may be added
   using the SSH_AGENTC_ADD_SMARTCARD_KEY and
   SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED requests.  Note that
   "constraints" field is only included for the
   SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED variant of this message.





Miller                   Expires 23 August 2026                 [Page 8]

Internet-Draft             SSH Agent Protocol              February 2026


       byte             SSH_AGENTC_ADD_SMARTCARD_KEY or
                        SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED
       string           token id
       string           PIN
       constraint[]     constraints

   Here "token id" is an opaque identifier for the hardware token and
   "PIN" is an optional password or PIN to unlock the key.  The
   interpretation of "token id" is not defined by the protocol but is
   left solely up to the agent.

   Typically, only the public components of any keys supported on a
   hardware token will be loaded into an agent so, strictly speaking,
   this message really arranges future private key operations to be
   delegated to the hardware token in question.

   An agent MUST reply with SSH_AGENT_SUCCESS if one or more keys were
   successfully loaded as a result of one of these messages, or
   SSH_AGENT_FAILURE if no keys were found.  The agent MUST also return
   SSH_AGENT_FAILURE if the "token id" was not recognised, if the
   request was against agent policy, or if the agent doesn't support
   token-hosted keys at all.

3.2.7.  Key Constraints

   A number of constraints may be used in the constrained variants of
   the key add messages.  Each constraint is represented by a type byte
   followed by zero or more value bytes.

   Zero or more constraints may be specified when adding a key with one
   of the *_CONSTRAINED requests.  Multiple constraints are appended
   consecutively to the end of the request:

       byte             constraint1_type
       byte[]           constraint1_data
       byte             constraint2_type
       byte[]           constraint2_data
       ....
       byte             constraintN_type
       byte[]           constraintN_data

   To fully parse a constraint, it is necessary to know its structure
   beforehand and it is not possible to safely recover when an
   unrecognised constraint is encountered.  Given this, if an agent does
   not recognise or support a requested constraint it MUST abort
   parsing, refuse the request and return an SSH_AGENT_FAILURE message
   to the client.




Miller                   Expires 23 August 2026                 [Page 9]

Internet-Draft             SSH Agent Protocol              February 2026


   The following constraints are defined.

3.2.7.1.  Key lifetime constraint

   This constraint requests that the agent limit the key's lifetime by
   deleting it after the specified duration (in seconds) has elapsed
   from the time the key was added to the agent.

       byte             SSH_AGENT_CONSTRAIN_LIFETIME
       uint32           seconds

3.2.7.2.  Key confirmation constraint

   This constraint requests that the agent require explicit user
   confirmation for each private key operation using the key.  For
   example, the agent could present a confirmation dialog before
   completing a signature operation.

       byte             SSH_AGENT_CONSTRAIN_CONFIRM

3.2.7.3.  Constraint extensions

   Agents may implement experimental or private-use constraints through
   an extension constraint that supports named constraints.

       byte             SSH_AGENT_CONSTRAIN_EXTENSION
       string           extension name
       byte[]           extension-specific details

   The extension name MUST consist of a UTF-8 string.  Vendor extensions
   MUST be suffixed by the implementation domain following the naming
   scheme defined in Section 6 of [RFC4251], e.g.  "foo@example.com".

   Note, given the above requirement to reject keys with unsupported
   constraints, a constraint extension is only usable when both client
   and agent support it.  Otherwise, the agent will be required to
   reject the key.  This is desirable, as the constraint extension may
   specify limits on the key that, if ignored, may result in the key
   being available in situations the user did not intend (i.e. the agent
   will fail safely).

3.3.  Public key encoding

   Keys previously loaded into an agent are referred to by their public
   key blob, which is the standard SSH wire encoding for public keys.
   SSH protocol key encodings are defined in [RFC4253] for "ssh-rsa" and
   "ssh-dss" keys, in [RFC5656] for "ecdsa-sha2-*" keys and in [RFC8709]
   for "ssh-ed25519" and "ssh-ed448" keys.



Miller                   Expires 23 August 2026                [Page 10]

Internet-Draft             SSH Agent Protocol              February 2026


3.4.  Removing keys from the agent

   A client may request that an agent remove all keys that it stores:

       byte             SSH_AGENTC_REMOVE_ALL_IDENTITIES

   On receipt of such a message, an agent SHOULD delete all keys that it
   is holding and reply with SSH_AGENT_SUCCESS, otherwise it MUST reply
   with SSH_AGENT_FAILURE if the request was refused.

   This request SHOULD be honoured regardless of any agent policy that
   limits actions that a given client may take, as otherwise a user
   would be unable to quickly and completely remove their keys in an
   urgent situation.

   Specific keys may also be removed:

       byte             SSH_AGENTC_REMOVE_IDENTITY
       string           key blob

   Where "key blob" is the standard public key encoding of the key to be
   removed (Section 3.3).

   An agent MUST reply with SSH_AGENT_SUCCESS if the key was deleted or
   SSH_AGENT_FAILURE if it was not found.

   Token-hosted keys may be removed from an agent using:

       byte             SSH_AGENTC_REMOVE_SMARTCARD_KEY
       string           token id
       string           PIN

   Where "token id" is an opaque identifier for the hardware token and
   "PIN" is an optional password or PIN (not typically used), both
   encoded using UTF-8.  Requesting deletion of token-hosted keys SHOULD
   cause the agent to remove all keys it loaded from the device matching
   "token id".  Similarly to SSH_AGENTC_REMOVE_ALL_IDENTITIES, agents
   SHOULD honour this request regardless of local policy to allow fast
   and complete removal of keys.  Note: this operation affects the agent
   only, it SHOULD NOT cause the keys be deleted from the token itself.

   An agent MUST reply with SSH_AGENT_SUCCESS keys were deleted or
   SSH_AGENT_FAILURE if none were found.

3.5.  Requesting a list of keys

   A client may request a list of keys from an agent using the following
   message:



Miller                   Expires 23 August 2026                [Page 11]

Internet-Draft             SSH Agent Protocol              February 2026


       byte             SSH_AGENTC_REQUEST_IDENTITIES

   The agent MUST reply with a message with the following preamble.

       byte             SSH_AGENT_IDENTITIES_ANSWER
       uint32           nkeys

   Where "nkeys" indicates the number of keys to follow.  Following the
   preamble are zero or more keys, representing the keys the agent makes
   available to the client with each encoded as:

       string           key blob
       string           comment

   Where "key blob" is the standard public key encoding of the key
   (Section 3.3) and "comment" is a human-readable comment encoded as a
   UTF-8 string.

3.6.  Private key operations

   A client may request the agent perform a private key signature
   operation using the following message:

       byte             SSH_AGENTC_SIGN_REQUEST
       string           key blob
       string           data
       uint32           flags

   Where "key blob" is the key requested to perform the signature
   (encoded as per Section 3.3), "data" is the data to be signed and
   "flags" is a bitfield containing the bitwise OR of zero or more
   signature flags (see below).

   If the agent does not support the requested flags, or is otherwise
   unable or unwilling to generate the signature (for example, because
   it doesn't have the specified key, or the user refused confirmation
   of a constrained key), it MUST reply with an SSH_AGENT_FAILURE
   message.

   On success, the agent MUST reply with:

       byte             SSH_AGENT_SIGN_RESPONSE
       string           signature

   The signature format is specific to the algorithm of the key type in
   use.  SSH protocol signature formats are defined in [RFC4253] for
   "ssh-rsa" and "ssh-dss" keys, in [RFC5656] for "ecdsa-sha2-*" keys
   and in [RFC8709] for "ssh-ed25519" and "ssh-ed448" keys.



Miller                   Expires 23 August 2026                [Page 12]

Internet-Draft             SSH Agent Protocol              February 2026


3.6.1.  Signature flags

   Two flags are currently defined for signature request messages:
   SSH_AGENT_RSA_SHA2_256 and SSH_AGENT_RSA_SHA2_512 (defined in
   Section 6.3).  These two flags are only valid for "ssh-rsa" keys and
   request that the agent return a signature using the "rsa-sha2-256" or
   "rsa-sha2-512" signature methods respectively.  These signature
   schemes are defined in [RFC8332].

3.7.  Locking and unlocking an agent

   The agent protocol supports instructing an agent to temporarily lock
   itself with a pass-phrase.  When locked, an agent MUST suspend
   processing of sensitive operations (private key signature operations
   at the very least) until it has been unlocked with the same pass-
   phrase.

   The following message instructs an agent to lock itself:

       byte             SSH_AGENTC_LOCK
       string           passphrase

   The agent MUST reply with SSH_AGENT_SUCCESS if locked successfully or
   SSH_AGENT_FAILURE otherwise (e.g. if the agent was already locked).

   The following message requests unlocking an agent:

       byte             SSH_AGENTC_UNLOCK
       string           passphrase

   If the agent is already locked and the pass-phrase matches the one
   used to lock it then it MUST unlock and reply with SSH_AGENT_SUCCESS.
   If the agent is already unlocked or if the pass-phrase does not match
   it MUST reply with SSH_AGENT_FAILURE.

3.8.  Extension mechanism

   The agent protocol includes an optional extension mechanism that
   allows vendor-specific and experimental messages to be sent via the
   agent protocol.  Extension requests from the client consist of:

       byte             SSH_AGENTC_EXTENSION
       string           extension type
       byte[]           extension request-specific contents







Miller                   Expires 23 August 2026                [Page 13]

Internet-Draft             SSH Agent Protocol              February 2026


   The extension type indicates the type of the extension message as a
   UTF-8 string.  Implementation-specific extensions MUST be suffixed by
   the implementation domain following the extension naming scheme
   defined in Section 6 of [RFC4251], e.g. "foo@example.com".

   An agent that does not support extensions of the supplied type MUST
   reply with an empty SSH_AGENT_FAILURE message.  This reply is also
   sent by agents that do not support the extension mechanism at all.

   The contents of successful extension reply messages are specific to
   the extension type.  Successful extension requests MUST return either
   SSH_AGENT_SUCCESS on success or an extension-specific response
   message:

       byte             SSH_AGENT_EXTENSION_RESPONSE
       string           extension type
       byte[]           extension response-specific contents

   Where the extension type is the same as that in the request.

   Extension failure SHOULD be signaled using an
   SSH_AGENT_EXTENSION_FAILURE message:

       byte             SSH_AGENT_EXTENSION_FAILURE

   Extensions SHOULD NOT use the standard SSH_AGENT_FAILURE message.
   This allows failed requests to be distinguished from the extension
   not being supported.

3.8.1.  Query extension

   A single, optional extension request "query" is defined to allow a
   client to query which, if any, extensions are supported by an agent.

       byte             SSH_AGENTC_EXTENSION
       string           "query"

   If an agent supports the query extension it SHOULD reply with a list
   of supported extension names.

       byte             SSH_AGENT_EXTENSION_RESPONSE
       string           "query"
       string[]         supported extension types








Miller                   Expires 23 August 2026                [Page 14]

Internet-Draft             SSH Agent Protocol              February 2026


4.  Connecting to an agent

   Agents are exposed to the local system using a connection-oriented
   endpoint.  On Unix-like systems, it is typical to arrange for the
   agent to listen on a filesystem-based Unix domain socket.  On
   Microsoft Windows, it is usual to use a Windows Named Pipe.  Access
   to these endpoints SHOULD be controlled as discussed in Section 8.
   Multiple clients may access a single agent by making connections to
   these sockets.

   In both cases, it is common to expose the name or address of the
   listening endpoint via an environment variable named "SSH_AUTH_SOCK".
   Clients of an agent will use this variable to locate and connect to
   the listening agent.  Agents alternately MAY use an implicit
   mechanism for clients to locate their endpoint, such as a default
   per-user location.

5.  Forwarding access to an agent

   The agent protocol may be forwarded over an SSH connection, using the
   [RFC4254] connection protocol, allowing agent forwarding to be
   requested for any session channel, using a model that is similar to
   the connection protocol's support for X11 Forwarding (Section 6.3 of
   [RFC4254]).  This feature is OPTIONAL for SSH protocol and agent
   implementations.

5.1.  Advertising agent forwarding support

   Support for agent forwarding may be advertised by an SSH server using
   the [RFC8308] extension mechanism using the name "agent-forward" in
   the SSH_MSG_EXT_INFO message.

       string           "agent-forward"
       string           "0" (version)

   Note that this protocol substantially predates the existence of the
   [RFC8308] extension mechanism and several widely-deployed SSH
   implementations that support agent forwarding do not advertise their
   ability to do so.  SSH Clients MAY opportunistically attempt to
   request agent forwarding in the absence of an [RFC8308] advertisement
   using the vendor-specific names mentioned below.  Likewise, SSH
   servers MAY implement the vendor-specific names in addition to the
   one described here.








Miller                   Expires 23 August 2026                [Page 15]

Internet-Draft             SSH Agent Protocol              February 2026


5.2.  Requesting agent forwarding

   An SSH client may request agent forwarding for a previously-opened
   session (Section 6.1 of [RFC4254]) using the following channel
   request.  This request is sent after the channel has been opened, but
   before a shell, command or subsystem has been executed.

       byte             SSH_MSG_CHANNEL_REQUEST
       uint32           channel_id
       string           "agent-req" or "auth-agent-req@openssh.com"
       boolean          want_reply

   Where channel_id is the identifier for an established session channel
   (as returned from a previous SSH_MSG_CHANNEL_OPEN request, and the
   want_reply flag indicates whether the SSH server should respond with
   a confirmation of whether the request was successful (as specified in
   Section 5.4 of [RFC4254])

   If an SSH server accepts this request, typically it will arrange to
   make an endpoint (e.g. a listening socket) available and advertise
   this fact to the subordinate session.  Most implementations on Unix-
   like systems do this by providing a user-private listening Unix
   domain socket and recording its location in an environment variable
   SSH_AUTH_SOCK.

   As mentioned previously, many deployed implementations only support
   the pre-standardisation "auth-agent-req@openssh.com" request name.
   The "agent-req" name SHOULD only be used if support was explicitly
   advertised as per Section 5.1.

5.3.  Agent connection requests

   After an SSH client has requested that a session have agent
   forwarding enabled, the SSH server later may request a connection to
   the forwarded agent.  The SSH server does this by requesting a
   dedicated channel to communicate with the SSH client's agent.

       byte             SSH_MSG_CHANNEL_OPEN
       string           "agent-connect" or "auth-agent@openssh.com"
       uint32           channel_id
       uint32           local_window
       uint32           local_maxpacket

   The channel_id, local_window and local_maxpacket fields should be
   interpreted as specified by Section 5.1 of [RFC4254].

   As above, the "agent-connect" open type name SHOULD only be used if
   support was explicitly advertised as per Section 5.1.



Miller                   Expires 23 August 2026                [Page 16]

Internet-Draft             SSH Agent Protocol              February 2026


   An SSH client SHOULD be prepared to handle multiple concurrent
   forwarded connections to a client-side agent, otherwise requests to
   access the agent from the remote side that happen to overlap prior
   requests may fail.  Overlapping requests may occur because the SSH
   connection protocol [RFC4254] allows multiple user sessions over a
   single [RFC4253] transport, which may each request use of the agentcw
   independently and potentially concurrently.

   An SSH client MAY accept agent connection requests (subject to
   authorisation) without a prior agent forwarding request having been
   made to support the situation where agent forwarding without opening
   a session is desired.  Similarly, an SSH client MAY continue to
   accept agent connection requests after the session for which agent
   forwarding was requested has closed.

   An SSH client MUST refuse unauthorised agent connection requests,
   when agent forwarding is neither requested nor desired by the SSH
   client but an SSH server sends an agent connection request anyway.

   Because the "agent-connect" request contains no identifier to
   distinguish which session channel originated the connection request,
   an SSH connection can effectively forward access to only a single SSH
   client-side agent using this protocol (although there may be multiple
   concurrent connections to that single agent).

6.  Protocol numbers

6.1.  Message type numbers

   The following numbers are used as message types for requests from the
   client to the agent.

       SSH_AGENTC_REQUEST_IDENTITIES                  11
       SSH_AGENTC_SIGN_REQUEST                        13
       SSH_AGENTC_ADD_IDENTITY                        17
       SSH_AGENTC_REMOVE_IDENTITY                     18
       SSH_AGENTC_REMOVE_ALL_IDENTITIES               19
       SSH_AGENTC_ADD_SMARTCARD_KEY                   20
       SSH_AGENTC_REMOVE_SMARTCARD_KEY                21
       SSH_AGENTC_LOCK                                22
       SSH_AGENTC_UNLOCK                              23
       SSH_AGENTC_ADD_ID_CONSTRAINED                  25
       SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED       26
       SSH_AGENTC_EXTENSION                           27

   The following numbers are used as message types for replies from the
   agent to the client.




Miller                   Expires 23 August 2026                [Page 17]

Internet-Draft             SSH Agent Protocol              February 2026


       SSH_AGENT_FAILURE                               5
       SSH_AGENT_SUCCESS                               6
       SSH_AGENT_IDENTITIES_ANSWER                     12
       SSH_AGENT_SIGN_RESPONSE                         14
       SSH_AGENT_EXTENSION_FAILURE                     28
       SSH_AGENT_EXTENSION_RESPONSE                    29

6.1.1.  Reserved message type numbers

   The following message type numbers are reserved for implementations
   that implement support for the legacy SSH protocol version 1: 1-4,
   7-10, 15-16 and 24 (inclusive).  These message numbers MAY be used by
   an implementation supporting the legacy protocol but MUST NOT be
   reused otherwise.

   Message number 0 is also reserved and MUST NOT be used.

   The range of message numbers 240-255 are reserved for Private Use
   extensions to the agent protocol and MUST NOT be used by generic
   implementations.

6.2.  Constraint identifiers

   The following numbers are used to identify key constraints.  These
   are only used in key constraints and are not sent as message numbers.

       SSH_AGENT_CONSTRAIN_LIFETIME                    1
       SSH_AGENT_CONSTRAIN_CONFIRM                     2
       SSH_AGENT_CONSTRAIN_EXTENSION                   255

   The constraint identifier 0 is reserved.

6.3.  Signature flags

   The following numbers may be present in signature request
   (SSH_AGENTC_SIGN_REQUEST) messages.  These flags form a bit field by
   taking the logical OR of zero or more flags.

       SSH_AGENT_RSA_SHA2_256                          0x00000002
       SSH_AGENT_RSA_SHA2_512                          0x00000004

   The flag value 1 is reserved for historical implementations.









Miller                   Expires 23 August 2026                [Page 18]

Internet-Draft             SSH Agent Protocol              February 2026


7.  IANA Considerations

   This protocol requires five registries be established, one for
   message type numbers, one for constraint numbers, one for signature
   request flags, one for constraint extension names and one for
   extension request names.  Additionally, new codepoints are requested
   in three existing registries.

7.1.  Guidance for Designated Experts

   When a Designated Expert (DE) is asked to review additions to the new
   registries described above (Section 7.2, Section 7.3, Section 7.5 and
   Section 7.6), they are requested to verify that suitable
   documentation as described in [RFC8126] exists and is permanently and
   publicly available.  The DE is also requested to check the clarity of
   purpose and use of the requested code points.  The DE should also
   verify that specifications produced in the IETF that request code
   points in these registries have been made available to the SSHM
   working group and the ssh@ietf.org mailing list for review.  Requests
   for code points made for specifications produced outside the IETF
   should not conflict with active IETF work or prior IETF
   specifications.

   The available number of code points in the SSH agent protocol numbers
   (Section 7.2), constraint numbers (Section 7.3) and SSH agent
   signature flags (Section 7.5) registries are limited, so the DE is
   requested to ensure the use of code points is very well justified.
   For the SSH agent protocol message numbers, named extension requests
   (Section 7.6) provide an alternative for most uses with no practical
   limitation on the number of available code points.  For key
   constraint numbers, the constraint extension mechanism
   (Section 3.2.7.3) provides a similar alternative that is not limited
   by available code points.

7.2.  New registry: SSH agent protocol message type numbers

   This registry, titled "SSH agent protocol message type numbers"
   records the message type numbers for client requests and agent
   responses.  It should be created in the Secure Shell (SSH) Protocol
   Parameters registry group [IANA-SSH].  Its initial state should
   consist of the following numbers and reservations.  Future message
   number allocations shall occur via Expert Review as per [RFC8126].









Miller                   Expires 23 August 2026                [Page 19]

Internet-Draft             SSH Agent Protocol              February 2026


   +===========+==========================================+===========+
   | Number(s) | Identifier                               | Reference |
   +===========+==========================================+===========+
   | 0         | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 1         | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 2         | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 3         | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 4         | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 5         | SSH_AGENT_FAILURE                        | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.1 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 6         | SSH_AGENT_SUCCESS                        | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.1 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 7         | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 8         | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 9         | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 10        | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |



Miller                   Expires 23 August 2026                [Page 20]

Internet-Draft             SSH Agent Protocol              February 2026


   +-----------+------------------------------------------+-----------+
   | 11        | SSH_AGENTC_REQUEST_IDENTITIES            | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.5 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 12        | SSH_AGENT_IDENTITIES_ANSWER              | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.5 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 13        | SSH_AGENTC_SIGN_REQUEST                  | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.6 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 14        | SSH_AGENT_SIGN_RESPONSE                  | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.6 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 15        | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 16        | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 17        | SSH_AGENTC_ADD_IDENTITY                  | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.2 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 18        | SSH_AGENTC_REMOVE_IDENTITY               | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.4 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 19        | SSH_AGENTC_REMOVE_ALL_IDENTITIES         | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.4 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 20        | SSH_AGENTC_ADD_SMARTCARD_KEY             | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.2.6 and |
   |           |                                          | 6.1       |



Miller                   Expires 23 August 2026                [Page 21]

Internet-Draft             SSH Agent Protocol              February 2026


   +-----------+------------------------------------------+-----------+
   | 21        | SSH_AGENTC_REMOVE_SMARTCARD_KEY          | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.4 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 22        | SSH_AGENTC_LOCK                          | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.7 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 23        | SSH_AGENTC_UNLOCK                        | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.7 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 24        | reserved                                 | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1.1     |
   +-----------+------------------------------------------+-----------+
   | 25        | SSH_AGENTC_ADD_ID_CONSTRAINED            | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.2 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 26        | SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.2.6 and |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 27        | SSH_AGENTC_EXTENSION                     | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.8 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 28        | SSH_AGENT_EXTENSION_FAILURE              | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.8 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 29        | SSH_AGENT_EXTENSION_RESPONSE             | thisrfc,  |
   |           |                                          | Sections  |
   |           |                                          | 3.8 and   |
   |           |                                          | 6.1       |
   +-----------+------------------------------------------+-----------+
   | 240-255   | Private Use                              | thisrfc,  |
   |           |                                          | Section   |
   |           |                                          | 6.1       |



Miller                   Expires 23 August 2026                [Page 22]

Internet-Draft             SSH Agent Protocol              February 2026


   +-----------+------------------------------------------+-----------+

                                 Table 1

7.3.  New registry: SSH agent key constraint numbers

   This registry, titled "SSH agent key constraint numbers" records the
   message numbers for key use constraints.  It should be created in the
   Secure Shell (SSH) Protocol Parameters registry group [IANA-SSH].
   Its initial state should consist of the following numbers.  Future
   key constraint number allocations shall occur via Expert Review as
   per [RFC8126].

     +========+===============================+======================+
     | Number | Identifier                    | Reference            |
     +========+===============================+======================+
     | 0      | reserved                      | thisrfc, Section 6.2 |
     +--------+-------------------------------+----------------------+
     | 1      | SSH_AGENT_CONSTRAIN_LIFETIME  | thisrfc, Section 6.2 |
     +--------+-------------------------------+----------------------+
     | 2      | SSH_AGENT_CONSTRAIN_CONFIRM   | thisrfc, Section 6.2 |
     +--------+-------------------------------+----------------------+
     | 255    | SSH_AGENT_CONSTRAIN_EXTENSION | thisrfc, Section 6.2 |
     +--------+-------------------------------+----------------------+

                                  Table 2

7.4.  New registry: SSH agent key constraint extension names

   This registry, titled "SSH agent key constraint extension names"
   records the names used in the SSH_AGENT_CONSTRAIN_EXTENSION
   constraint extension type (Section 3.2.7.3).  It should be created in
   the Secure Shell (SSH) Protocol Parameters registry group [IANA-SSH].
   Its initial state should be empty.  Future key constraint extension
   name allocations shall occur via Expert Review as per [RFC8126].

7.5.  New registry: SSH agent signature flags

   This registry, titled "SSH agent signature flags" records the values
   for signature request (SSH_AGENTC_SIGN_REQUEST) flag values.  It
   should be created in the Secure Shell (SSH) Protocol Parameters
   registry group [IANA-SSH].  Its initial state should consist of the
   following numbers.  Note that as the flags are combined by bitwise
   OR, all flag values must be powers of two and the maximum available
   flag value is 0x80000000.

   Future signature flag allocations shall occur via Expert Review as
   per [RFC8126].



Miller                   Expires 23 August 2026                [Page 23]

Internet-Draft             SSH Agent Protocol              February 2026


        +========+========================+======================+
        | Number | Identifier             | Reference            |
        +========+========================+======================+
        | 0x01   | reserved               | thisrfc, Section 6.3 |
        +--------+------------------------+----------------------+
        | 0x02   | SSH_AGENT_RSA_SHA2_256 | thisrfc, Section 6.3 |
        +--------+------------------------+----------------------+
        | 0x04   | SSH_AGENT_RSA_SHA2_512 | thisrfc, Section 6.3 |
        +--------+------------------------+----------------------+

                                 Table 3

7.6.  New registry: SSH agent extension request names

   This registry, titled "SSH agent extension request names" records the
   names used in the generic extension request message
   (SSH_AGENTC_EXTENSION).  It should be created in the Secure Shell
   (SSH) Protocol Parameters registry group [IANA-SSH].  Its initial
   state should consist of the following names.

   Future name allocations shall occur via Expert Review as per
   [RFC8126].

                +================+========================+
                | Extension Name | Reference              |
                +================+========================+
                | query          | thisrfc, Section 3.8.1 |
                +----------------+------------------------+

                                  Table 4

7.7.  Additions to SSH Extension Names

   IANA is requested to insert the following entries into the table
   Extension Names [IANA-SSH-EXT] in the Secure Shell (SSH) Protocol
   Parameters registry group [IANA-SSH].

                 +================+======================+
                 | Extension Name | Reference            |
                 +================+======================+
                 | agent-forward  | thisrfc, Section 5.1 |
                 +----------------+----------------------+

                                  Table 5







Miller                   Expires 23 August 2026                [Page 24]

Internet-Draft             SSH Agent Protocol              February 2026


7.8.  Additions to SSH Connection Protocol Channel Request Names

   IANA is requested to insert the following entries into the table
   Connection Protocol Channel Request Names [IANA-SSH-CHANREQ] in the
   Secure Shell (SSH) Protocol Parameters registry group [IANA-SSH].

                  +==============+======================+
                  | Request Type | Reference            |
                  +==============+======================+
                  | agent-req    | thisrfc, Section 5.2 |
                  +--------------+----------------------+

                                  Table 6

7.9.  Additions to SSH Connection Protocol Channel Types

   IANA is requested to insert the following entries into the table
   Connection Protocol Channel Types [IANA-SSH-CHANTYPE] under Secure
   Shell (SSH) Protocol Parameters [IANA-SSH].

                 +===============+======================+
                 | Request Type  | Reference            |
                 +===============+======================+
                 | agent-connect | thisrfc, Section 5.3 |
                 +---------------+----------------------+

                                 Table 7

8.  Security Considerations

   The agent is a service that is tasked with retaining and providing
   controlled access to what are typically long-lived login
   authentication credentials.  It is by nature a sensitive and trusted
   software component.  Moreover, the agent protocol itself does not
   include any authentication or transport security; ability to
   communicate with an agent is usually sufficient to invoke it to
   perform private key operations.

   Since being able to access an agent is usually sufficient to perform
   private key operations, it is critically important that the agent
   only be exposed to its owner and their authorised delegates.  On
   Unix-like systems this may be achieved via filesystem permissions on
   the agent socket and/or identity checks on the client connected to a
   socket (e.g. SO_PEERCRED on some Unix-like systems).  On Windows,
   access to a named pipe may be controlled by attaching a security
   descriptor at the time of its creation.





Miller                   Expires 23 August 2026                [Page 25]

Internet-Draft             SSH Agent Protocol              February 2026


   The primary design intention of an agent is that an attacker with
   unprivileged access to their victim's agent should be prevented from
   gaining a copy of any keys that have been loaded into it.  This may
   not preclude the attacker from stealing use of those keys (e.g.  if
   they have been loaded without a confirmation constraint).

   Given this, the agent should, as far as possible, prevent its memory
   being read by other processes to prevent theft of loaded keys.  This
   typically includes disabling debugging interfaces and preventing
   process memory dumps on abnormal termination.

   Another, more subtle, means by which keys may be stolen are via
   cryptographic side-channels.  Private key operations may leak
   information about the contents of keys via differences in timing,
   power use or by side effects in the memory subsystems (e.g. CPU
   caches) of the host running the agent.  For the case of a local
   attacker and an agent holding unconstrained keys, the only limit on
   the number of private key operations the attacker may be able to
   observe is the rate at which the CPU can perform signatures.  This
   grants the attacker an almost ideal oracle for side-channel attacks.
   While a full treatment of side-channel attacks is beyond the scope of
   this specification, agents SHOULD use cryptographic implementations
   that are resistant to side-channel attacks and MAY take additional
   measures to hide the actual time spent processing private key
   operations.  Failure to do so may expose keys to recovery through
   these side-channels.

   Forwarding access to a local agent over an SSH connection (Section 5)
   inherently creates a transitive trust relationship.  SSH
   implementations SHOULD NOT forward use of an agent by default and
   users SHOULD NOT forward use of an agent to hosts that are not fully
   trusted, as doing so could expose access to the user's keys to
   attackers on remote hosts.  Agents SHOULD implement additional
   controls over key visibility and use for forwarded agent connections,
   otherwise the user has only an all-or-nothing choice over whether to
   forward an agent.

   Implementation of token/smartcard-hosted keys requires some care too.
   On some systems, tokens may invoked by providing a path to shared
   library that must be loaded to make use of keys hosted on the device
   (a path to a library for a particular PKCS#11 module, for example).
   Loading a shared library on most platforms implies automatic
   execution of code in that library in the address space of the process
   that loads it.  To avoid loading of potentially-hostile code, agents
   that support loading token-hosted keys via library path SHOULD ensure
   that only trusted token provider libraries are loadable.
   Additionally agents SHOULD ensure that loaded token library code
   cannot gain access to other keys loaded in the agent and MAY disallow



Miller                   Expires 23 August 2026                [Page 26]

Internet-Draft             SSH Agent Protocol              February 2026


   remote clients from loading token keys entirely.  Protection for
   existing keys from tokey library code may be achieved by loading the
   token library into a separate process to the agent and arranging for
   the agent to invoke token operations to this process via IPC.

   Finally, with respect to the agent locking functionality in
   Section 3.7, an agent SHOULD take countermeasures against brute-force
   guessing attacks against the pass-phrase.  This may take the form of
   enforced delays when an unlock attempt is made with an incorrect
   password (potentially increasing for subsequent failures), a lockout
   period where the agent refuses to accept further requests after some
   threshold of failed unlock attempts has been made and/or deletion of
   all keys held by the agent after a threshold of failed unlock
   attempts.

9.  Implementation Status

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

   Note to editor: please also remove the orphaned reference to RFC7942.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   The following projects maintain an implementation of this protocol:

   OpenSSH  OpenSSH is the originating implementation of this protocol
      and has supported it since 2000.

      Website: https://www.openssh.com/




Miller                   Expires 23 August 2026                [Page 27]

Internet-Draft             SSH Agent Protocol              February 2026


   PuTTY  PuTTY is a popular SSH client implementation for multiple
      platforms that has included a compatible agent client since 2001.

      Website: https://www.chiark.greenend.org.uk/~sgtatham/putty/

   Dropbear  Dropbear is an SSH client and server implementation for
      Unix-like systems.  It has supported the agent protocol since
      2005.

      Website: https://matt.ucc.asn.au/dropbear/dropbear.html

   Paramiko  Paramiko is an SSH client and server implementation in the
      Python programming language.  It has supported an agent protocol
      implementation since 2005.

      Website: https://www.paramiko.org/

   Golang x/crypto/ssh/agent  The Go programming language project has
      supported an implementation of this protocol in its external "x"
      repository since 2015.

      Website: https://pkg.go.dev/golang.org/x/crypto/ssh/agent

   This list is not exhaustive.

10.  References

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

   [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
              January 2006, <https://www.rfc-editor.org/info/rfc4251>.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
              January 2006, <https://www.rfc-editor.org/info/rfc4253>.

   [RFC4254]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
              January 2006, <https://www.rfc-editor.org/info/rfc4254>.






Miller                   Expires 23 August 2026                [Page 28]

Internet-Draft             SSH Agent Protocol              February 2026


   [RFC5656]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
              Integration in the Secure Shell Transport Layer",
              RFC 5656, DOI 10.17487/RFC5656, December 2009,
              <https://www.rfc-editor.org/info/rfc5656>.

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

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

   [RFC8308]  Bider, D., "Extension Negotiation in the Secure Shell
              (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
              2018, <https://www.rfc-editor.org/info/rfc8308>.

   [RFC8332]  Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in
              the Secure Shell (SSH) Protocol", RFC 8332,
              DOI 10.17487/RFC8332, March 2018,
              <https://www.rfc-editor.org/info/rfc8332>.

   [RFC8709]  Harris, B. and L. Velvindron, "Ed25519 and Ed448 Public
              Key Algorithms for the Secure Shell (SSH) Protocol",
              RFC 8709, DOI 10.17487/RFC8709, February 2020,
              <https://www.rfc-editor.org/info/rfc8709>.

   [FIPS.186-4]
              National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", FIPS PUB 186-4,
              DOI 10.6028/NIST.FIPS.186-4, July 2013,
              <https://doi.org/10.6028/NIST.FIPS.186-4>.

   [FIPS.186-5]
              National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", FIPS PUB 186-5,
              DOI 10.6028/NIST.FIPS.186-5, February 2023,
              <https://doi.org/10.6028/NIST.FIPS.186-5>.

10.2.  Informative References

   [RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
              January 2006, <https://www.rfc-editor.org/info/rfc4252>.






Miller                   Expires 23 August 2026                [Page 29]

Internet-Draft             SSH Agent Protocol              February 2026


   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

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

   [IANA-SSH-CHANREQ]
              IANA, "Connection Protocol Channel Types",
              <https://www.iana.org/assignments/ssh-parameters/>.

   [IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters",
              <https://www.iana.org/assignments/ssh-parameters/ssh-
              parameters.xhtml>.

   [IANA-SSH-CHANTYPE]
              IANA, "Extension Names",
              <https://www.iana.org/assignments/ssh-parameters/>.

   [IANA-SSH-EXT]
              IANA, "Connection Protocol Channel Request Names",
              <https://www.iana.org/assignments/ssh-parameters/>.

   [IANA-PUBKEYS]
              IANA, "Public Key Algorithm Names",
              <https://www.iana.org/assignments/ssh-parameters/>.

   [draft-ietf-secsh-agent-02]
              Ylonen, T., Rinne, T. J., and S. Lehtinen, "Secure Shell
              Authentication Agent Protocol", January 2004,
              <https://datatracker.ietf.org/doc/html/draft-ietf-secsh-
              agent-02>.

Acknowledgments

   This protocol was designed and first implemented by Markus Friedl,
   based on a similar protocol for an agent to support the legacy SSH
   version 1 by Tatu Ylonen.

   Thanks to Simon Tatham, Niels Möller, James Spencer, Simon Josefsson,
   Matt Johnston, Jakub Jelen, Rich Salz, Caspar Schutijser, Florian
   Obser, Martin Thomson, Deb Cooley and Tero Kivinen who reviewed and
   helped improve this document.





Miller                   Expires 23 August 2026                [Page 30]

Internet-Draft             SSH Agent Protocol              February 2026


Author's Address

   Damien Miller
   OpenSSH
   Email: djm@openssh.com
   URI:   https://www.openssh.com/













































Miller                   Expires 23 August 2026                [Page 31]


name: draft-oauth-ai-agents-on-behalf-of-user
rev: 02
title: OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents
time: 2026-02-27T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-02-27T03:24:34Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
tags: []
fetched_at: 2026-02-27T22:56:03.420398+00:00
abstract:
This specification extends the OAuth 2.0 Authorization Framework
   [RFC6749] to enable AI agents to securely obtain access tokens for
   acting on behalf of users.  It introduces the *requested_actor*
   parameter in authorization requests to identify the specific agent
   requiring delegation and the *actor_token* parameter in token
   requests to authenticate the agent during the exchange of an
   authorization code for an access token.  The flow can be initiated by
   a resource server challenge, ensuring that user consent is obtained
   dynamically when access is attempted.  This extension ensures secure
   delegation with explicit user consent, streamlines the authorization
   flow, and enhances auditability through access token claims that
   document the delegation chain from the user to the agent via a client
   application.

full_text:
Web Authorization Protocol                                T. S. Senarath
Internet-Draft                                            A. Dissanayaka
Intended status: Informational                                      WSO2
Expires: 27 February 2026                                 26 August 2025


   OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents
               draft-oauth-ai-agents-on-behalf-of-user-02

Abstract

   This specification extends the OAuth 2.0 Authorization Framework
   [RFC6749] to enable AI agents to securely obtain access tokens for
   acting on behalf of users.  It introduces the *requested_actor*
   parameter in authorization requests to identify the specific agent
   requiring delegation and the *actor_token* parameter in token
   requests to authenticate the agent during the exchange of an
   authorization code for an access token.  The flow can be initiated by
   a resource server challenge, ensuring that user consent is obtained
   dynamically when access is attempted.  This extension ensures secure
   delegation with explicit user consent, streamlines the authorization
   flow, and enhances auditability through access token claims that
   document the delegation chain from the user to the agent via a client
   application.

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-
   user/.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (mailto:oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.
   Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/shashimalcse/oauth-ai-agents.

Status of This Memo

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






Senarath & Dissanayaka  Expires 27 February 2026                [Page 1]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 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 27 February 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  High-Level Overview . . . . . . . . . . . . . . . . . . .   5
   4.  Detailed Protocol Steps . . . . . . . . . . . . . . . . . . .   9
     4.1.  User Authorization Request  . . . . . . . . . . . . . . .   9
       4.1.1.  Parameters  . . . . . . . . . . . . . . . . . . . . .   9
       4.1.2.  Authorization Server Processing . . . . . . . . . . .   9
       4.1.3.  Authorization Code Response . . . . . . . . . . . . .  10
       4.1.4.  Error Response  . . . . . . . . . . . . . . . . . . .  10
     4.2.  Access Token Request  . . . . . . . . . . . . . . . . . .  10
       4.2.1.  Parameters  . . . . . . . . . . . . . . . . . . . . .  11
       4.2.2.  Authorization Server Processing . . . . . . . . . . .  11
       4.2.3.  Access Token Response . . . . . . . . . . . . . . . .  11
       4.2.4.  Error Response  . . . . . . . . . . . . . . . . . . .  12
     4.3.  Access Token Structure and Claims . . . . . . . . . . . .  12
     4.4.  Resource Server Challenge . . . . . . . . . . . . . . . .  13
       4.4.1.  Resource Server Processing  . . . . . . . . . . . . .  13
       4.4.2.  The WWW-Authenticate Response Header Field  . . . . .  14
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14



Senarath & Dissanayaka  Expires 27 February 2026                [Page 2]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


   6.  Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   AI agents are increasingly common in systems, performing tasks on
   behalf of users.  These agents often need access to protected
   resources, requiring a secure and robust authorization mechanism that
   clearly reflects the user's intent and the agent's role in the access
   request.

   Standard OAuth 2.0 flows, such as the Authorization Code Grant and
   the Client Credentials Grant [RFC6749], do not fully address the
   complexities of agent delegation.  They lack specific mechanisms to
   obtain explicit user consent for an agent's actions or to treat the
   agent as a distinct identity during the token exchange process.

   The OAuth 2.0 Token Exchange specification [RFC8693] provides a
   framework for token exchange, but it is primarily designed for
   server-side communication or impersonation scenarios.  It does not
   natively support obtaining explicit user consent for an agent via the
   front channel from the authorization endpoint.  Furthermore,
   [RFC8693] does not specify how to acquire the subject token, adding
   complexity to the delegation process.

   To overcome these limitations, this specification extends the OAuth
   2.0 Authorization Code Grant flow to enable user-delegated
   authorization for AI agents.  It introduces the following
   enhancements:

   1.  The *requested_actor* parameter at the authorization endpoint,
       allowing the client to specify the agent for which delegation is
       requested.

   2.  The *actor_token* parameter at the token endpoint, enabling the
       agent to authenticate itself when exchanging a user-approved
       authorization code for an access token.

   3.  Detailed claims in the resulting access token, capturing the
       identities of the user, agent, and client application for
       transparency and auditability.

   This approach builds on existing OAuth 2.0 infrastructure to deliver
   a secure, simplified, and user-centric delegation process tailored
   for AI agents.






Senarath & Dissanayaka  Expires 27 February 2026                [Page 3]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


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

2.  Terminology

   This specification uses the following terms:

   Actor:  An entity that acts on behalf of a user.  In context of AI
      applications, the actor is the agent that performs actions on
      behalf of the user.

   Client:  An application that initiates the authorization flow and
      facilitates the interaction between the user, actor, and
      authorization server.  This is the "client" as defined in OAuth
      2.0 [RFC6749].

   User:  The resource owner who grants consent for an actor to access
      their protected resources.

   Authorization Server:  The server that issues access tokens to the
      client and actor after successfully authenticating a resource
      owner and obtaining authorization.

   Resource Server:  The server hosting the protected resources, capable
      of accepting and validating access tokens.  In context of AI
      applications, resource server can be a model context protocol
      (MCP) server, another agent or genaric protected resource.

   Authorization Code:  A temporary, single-use code issued by the
      authorization server to the client's redirect URI after the user
      has authenticated and granted consent for a specific actor to act
      on their behalf.

   Actor Token:  A security token (e.g., a JWT [RFC7519]) used by an
      actor to authenticate itself to the authorization server or
      resource servers.  The sub claim of an Actor Token identifies the
      actor.  An actor can obtain an Actor Token by authenticating
      itself to the authorization server using a different grant, which
      is not included in the scope of this specification.

   Access Token:  An access token issued by the authorization server to
      an actor, permitting it to access protected resources on behalf of
      a specific user.  This token explicitly documents the delegation
      path.




Senarath & Dissanayaka  Expires 27 February 2026                [Page 4]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


3.  Protocol Overview

   This extension defines a flow where a client application facilitates
   user consent for an actor, and the actor then uses this consent along
   with its own authentication to obtain an access token.

3.1.  High-Level Overview

   1.  The Actor signals to the Client that it needs to perform an
       action on the User's behalf, providing its identifier (ActorID)

   2.  The Client attempts the action by making a request to the
       Resource Server

   3.  If access is unsuccessful (e.g., HTTP 401 Unauthorized due to an
       invalid/missing token, or HTTP 403 Forbidden due to insufficient
       scope), Resource Server challenges the Client.

   4.The Client initiates the authorization flow by redirecting the
   User's User-Agent to the Authorization Server's authorization
   endpoint.  This request includes a requested_actor parameter
   (matching the ActorID).

   1.  The Authorization Server authenticates the User (if not already
       authenticated) and presents a consent screen detailing the
       Client, the requested_actor, and the requested scopes.

   2.  Upon User consent, the Authorization Server issues a short-lived
       Authorization Code (tied to the User, Client, and consented
       Actor) and redirects the User-Agent back to the Client's
       redirect_uri.

   3.  The Client receives the Authorization Code via the User-Agent
       redirect.

   4.  The Client requests an Access Token from the Authorization
       Server's token endpoint.  This request uses the standard
       authorization_code grant type.  The request includes the
       Authorization Code, the PKCE code_verifier, and the actor_token
       (the authentication token of the Actor).

   5.  The Authorization Server validates the entire request:
       Authorization Code, PKCE code_verifier, and the actor_token.  It
       ensures the actor_token corresponds to the requested_actor for
       whom the User granted consent (which is linked to the
       Authorization Code).





Senarath & Dissanayaka  Expires 27 February 2026                [Page 5]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


   6.  Upon successful validation, the Authorization Server issues an
       Access Token to the Client.  This token is a JWT containing
       claims identifying the User (e.g., sub), the Client (e.g., azp or
       client_id), and the Actor (e.g., act claim).

   7.  The Client retries the action or performs a new action on the
       Resource Server using this newly obtained Access Token.

   8.  If access is successful (either initially or on retry): The
       Resource Server validates the Access Token (including the
       delegation claims like act) and processes the request, returning
       the resource or confirming the action.

   The Client may then pass the result to the Actor. ## Sequence Diagram

    +-----------+   +--------+    +-----------+   +---------------------+    +---------------+
    | User-Agent|   | Client |   | Act as Actor|  | Authorization Server|   | Resource Server |
    +-----------+   +--------+    +-----------+   +---------------------+    +---------------+
          |             |              |                   |                       |
          |     (1) Signals need to act on User's behalf   |                       |
          |             |  by passing ActorID              |                       |
          |             |<-------------|                   |
          |             |              |                   |                       |
          |             |              (2) Client attempts action                  |
          |             | -------------------------------------------------------> |
          |             |              |                   |                       |
    /--------------------------------- Access Unsuccessful ----------------------------------\
    |     |             |              |                   |                       |         |
    |------------------------------------[If Unauthorized]-----------------------------------|
    |     |             |              |                   |                       |         |
    |     |             |              |             +---------------------------------+     |
    |     |             |              |             | Token validation is failed      |     |
    |     |             |              |             +---------------------------------+     |
    |     |             |              |                   |                       |         |
    |     |             |  (3) CHALLENGE: HTTP 401, WWW-Authenticate:              |         |
    |     |             |           Bearer error="invalid_token"                   |         |
    |     |             | <--------------------------------------------------------|         |
    |     |             |              |                   |                       |         |
    |  (4) Redirect to AS (for User Authentication and Consent)                    |         |
    |              with requested_actor request parameter                          |         |
    |     |<------------|              |                   |                       |         |
    |     |             |              |                   |                       |         |
    |     |         (5) Authorization Request              |                       |         |
    |     |----------------------------------------------->|                       |         |
    |     |             |              |                   |                       |         |
    |     |     (6) User Authenticates & Consents          |                       |         |
    |     |<---------------------------------------------->|                       |         |
    |     |             |              |                   |                       |         |



Senarath & Dissanayaka  Expires 27 February 2026                [Page 6]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


    |------------------------------------[If Forbidden]--------------------------------------|
    |     |             |              |                   |                       |         |
    |     |             |              |            +---------------------------------+      |
    |     |             |              |            |   Insufficient Authorization    |      |
    |     |             |              |            +---------------------------------+      |
    |     |             |              |                   |                       |         |
    |     |               (7) CHALLENGE: HTTP 403, WWW-Authenticate:               |         |
    |     |       Bearer error="insufficient_scope" required_scope="scope1 scope2" |         |
    |     |             | <--------------------------------------------------------|         |
    |     |             |              |                   |                       |         |
    |  (8) Redirect to AS (for User Consent)               |                       |         |
    |    with requested_actor request parameter            |                       |         |
    |     |<------------|              |                   |                       |         |
    |     |             |              |                   |                       |         |
    |     |         (9) Authorization Request              |                       |         |
    |     |----------------------------------------------->|                       |         |
    |     |             |              |                   |                       |         |
    |     |            (10) User Consents                  |                       |         |
    |     |<---------------------------------------------->|                       |         |
    |----------------------------------------------------------------------------------------|
    |     |             |              |                   |                       |         |
    |     | (11) Redirect with Authorization Code          |                       |         |
    |     | <----------------------------------------------|                       |         |
    |     |             |              |                   |                       |         |
    |     | (12) Authorization Code    |                   |                       |         |
    |     |------------>|              |                   |                       |         |
    |     |             |              |                   |                       |         |
    |     |             | (13) Token Request with actor_token request parameter    |         |
    |     |             | ---------------------------------|                       |         |
    |     |             |              |                   |                       |         |
    |     |             |  (14) Access Token (JWT)         |                       |         |
    |     |             | <--------------------------------|                       |         |
    |     |             |              |                   |                       |         |
    |     |             |  (15) Client Retries Action with Access Token            |         |
    |     |             |--------------------------------------------------------->|         |
    \----------------------------------------------------------------------------------------/
    /------------------------------------ Access Successful ---------------------------------\
    |     |             |              |                   |                       |         |
    |     |             |  (16) Protected Resource / Action Succeeded              |         |
    |     |             |<---------------------------------------------------------|         |
    \----------------------------------------------------------------------------------------/

   The steps in the sequence diagram are as follows:

   1.   Actor signals its intent to the Client, providing its identifier
        (ActorID).





Senarath & Dissanayaka  Expires 27 February 2026                [Page 7]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


   2.   Client attempts to access protected resources on the Resource
        Server.

   3.   If access is unsuccessful with token validation, the Resource
        Server challenges the Client with a WWW-Authenticate header
        indicating the invalid token error.

   4.   Client redirects the User-Agent to the Authorization Server's
        authorization endpoint, including requested_actor and PKCE
        challenge.

   5.   User-Agent makes the Authorization Request to the Authorization
        Server.

   6.   User authenticates and grants consent.

   7.   If access is unsuccessful with insufficient scopes, the Resource
        Server challenges the Client with a WWW-Authenticate header
        indicating the insufficient scope error.

   8.   Client redirects the User-Agent to the Authorization Server's
        authorization endpoint, including requested_actor and PKCE
        challenge.

   9.   User-Agent makes the Authorization Request to the Authorization
        Server.

   10.  User grants consent.

   11.  Authorization Server redirects the User-Agent back to the
        Client's redirect_uri with an Authorization Code.

   12.  Client receives the Authorization Code via the User-Agent
        redirect.

   13.  Client requests an Access Token from the Authorization Server's
        token endpoint, including the Authorization Code, PKCE
        code_verifier, and actor_token.

   14.  Authorization Server validates the request and issues an Access
        Token (JWT) to the Client.

   15.  Client retries the action on the Resource Server using the newly
        obtained Access Token.

   16.  Resource Server validates the Access Token and processes the
        request, returning the protected resource or confirming the
        action.



Senarath & Dissanayaka  Expires 27 February 2026                [Page 8]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


4.  Detailed Protocol Steps

4.1.  User Authorization Request

   The client initiates the flow by directing the user's user-agent to
   the authorization server's authorization endpoint.  This request is
   the standard Authorization Code Grant request (Section 4.1.1 of
   [RFC6749]) and MUST include the requested_actor request parameter.

   GET /authorize?response_type=code&
   client_id=<client_id>&
   redirect_uri=<redirect_uri>&
   scope=<scope>&
   state=<state>&
   code_challenge=<code_challenge>&
   code_challenge_method=S256&
   requested_actor=<actor_id> HTTP/1.1

4.1.1.  Parameters

   requested_actor:  REQUIRED.  The unique identifier of the actor for
      which the client is requesting delegated access on behalf of the
      user.  This identifier MUST uniquely identify the actor within the
      system and MUST be understood by the Authorization Server.

   other parameters:  The request MUST also include the standard OAuth
      2.0 parameters such as response_type, client_id, redirect_uri,
      scope, state, and PKCE parameters (code_challenge and
      code_challenge_method).

4.1.2.  Authorization Server Processing

   Upon receiving the authorization request, the Authorization Server
   MUST perform the following steps:

   1.  Validate the request parameters according to the OAuth 2.0
       Authorization Code Grant (Section 4.1.1 of [RFC6749]).

   2.  Validate the requested_actor.  The Authorization Server MUST
       verify that the provided requested_actor corresponds to a
       recognized actor identity.

   3.  Authorization server MAY display a consent screen to the User.
       This screen SHOULD clearly indicate:

       *  The name or identity of the client application initiating the
          request.




Senarath & Dissanayaka  Expires 27 February 2026                [Page 9]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


       *  The identity of the actor (requested_actor) for which
          delegation is being requested.

       *  The specific scopes of access being requested.

   If the request is valid and the user grants consent, the
   Authorization Server proceeds to issue an Authorization Code.  If the
   request is invalid, the Authorization Server returns an Error
   Response.

4.1.3.  Authorization Code Response

   If the user grants consent, the Authorization Server issues an
   Authorization Code and redirects the user-agent back to the client's
   redirect_uri (if provided in the request) or a pre-registered
   redirect URI.

   HTTP/1.1 302 Found
   Location: <redirect_uri>?code=<authorization_code>&state=<state>

4.1.3.1.  Parameters

   Similar to the standard Authorization Code Grant (Section 4.1.2 of
   [RFC6749]), the response includes:

   code:  REQUIRED.  The Authorization Code is issued by the
      Authorization Server.

   state:  OPTIONAL.  The state parameter passed in the initial request,
      if present.  This value MUST be included in the redirect URI to
      maintain state between the request and callback.

4.1.4.  Error Response

   If the request fails, the Authorization Server redirects the user-
   agent back to the client's redirect_uri with error parameters.

   HTTP/1.1 302 Found
   Location: <redirect_uri>?error=<error_code>&state=<state>

4.2.  Access Token Request

   Upon receiving the Authorization Code, the client then requests an
   Access Token from the Authorization Server's token endpoint using the
   authorization_code grant type with the actor_token request parameter.






Senarath & Dissanayaka  Expires 27 February 2026               [Page 10]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


   POST /token HTTP/1.1
   Host: authorization-server.com
   Content-Type: application/x-www-form-urlencoded

   grant_type=authorization_code&
   client_id=<client_id>&
   code=<authorization_code>&
   code_verifier=<code_verifier>&
   redirect_uri=<redirect_uri>&
   actor_token=<actor_token>

4.2.1.  Parameters

   actor_token:  REQUIRED.  The actor token is used to authenticate the
      actor.  This token MUST be a valid token issued to the actor and
      MUST include the sub claim identifying the actor.

   other parameters:  The request MUST also include the standard OAuth
      2.0 parameters such as client_id, code, code_verifier, and
      redirect_uri.

4.2.2.  Authorization Server Processing

   Upon receiving the token request, the Authorization Server MUST
   perform the following steps:

   1.  Validate the request parameters according to the OAuth 2.0 Token
       Endpoint (Section 4.1.3 of [RFC6749]).

   2.  The Authorization Server MUST verify that the actor token is
       valid, not expired.

   3.  Verify that the authenticated actor identity (obtained from the
       Actor Token's sub claim) matches the requested_actor value that
       the user consented to during the initial Authorization Request
       and which is associated with the code.

   If all validations pass, the Authorization Server issues an Access
   Token.  If any validation fails, the Authorization Server returns an
   Error Response.

4.2.3.  Access Token Response

   If the Token Request is valid, the Authorization Server issues an
   Access Token to the actor.  This token SHOULD be a JSON Web Token
   (JWT) [RFC7519] to include claims that document the delegation.





Senarath & Dissanayaka  Expires 27 February 2026               [Page 11]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


   HTTP/1.1 200 OK
   Content-Type: application/json;charset=UTF-8
   Cache-Control: no-store
   Pragma: no-cache

   {
     "access_token": "<delegated_access_token>",
     "token_type": "Bearer",
     "expires_in": 3600,
     "scope": "<granted_scope>"
   }

4.2.3.1.  Parameters

   Similar to the standard Authorization Code Grant (Section 4.1.4 of
   [RFC6749])

4.2.4.  Error Response

   If the request is invalid, the Authorization Server returns an error
   response with an HTTP 400 (Bad Request) status code.

   HTTP/1.1 400 Bad Request
   Content-Type: application/json;charset=UTF-8
   Cache-Control: no-store
   Pragma: no-cache

   {
     "error": "invalid_grant"
   }

4.3.  Access Token Structure and Claims

   The Access Token SHOULD be a JWT Profile for OAuth 2.0 Access Tokens
   [RFC9068].  It SHOULD carry claims that explicitly document the
   delegation chain.

   In addition to standard JWT claims (e.g., iss, aud, exp, iat, jti),
   an Access Token issued via this flow MUST contain the following
   claims:

   act:  REQUIRED.  Actor - represents the party acting on behalf of the
      subject (Section 4.1 of [RFC8693]).  In an Access Token issued via
      this flow, this claim MUST contain a JSON object with at least the
      following member: * sub: REQUIRED.  The unique identifier of the
      actor that is acting on behalf of the user. * Additional members
      MAY be included in the act claim.




Senarath & Dissanayaka  Expires 27 February 2026               [Page 12]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


   Example Decoded JWT Payload:

   {
     "iss": "https://authorization-server.com/oauth2/token",
     "aud": "resource_server",
     "sub": "user-456",
     "azp": "s6BhdRkqt3",
     "scope": "read:email write:calendar",
     "exp": 1746009896,
     "iat": 1746006296,
     "jti": "unique-token-id",
     "act": {
       "sub": "actor-finance-v1"
     },
     "aut": "APPLICATION_USER"
   }

   Resource Servers consuming this token can inspect the sub claim to
   identify the user and the act.sub claim to identify the specific
   actor that is performing the action.  This provides a clear and
   auditable delegation path.

4.4.  Resource Server Challenge

   The authorization flow is often triggered by a resource server
   challenge, such as an HTTP 401 (Unauthorized) or 403 (Forbidden)
   response, indicating a missing, invalid, or insufficient access
   token.  This prompts the client to initiate the authorization process
   to obtain user consent and a valid token.

   When the client, prompted by an actor or speculatively, requests a
   protected resource, it includes an access token in the Authorization
   header if available.  If the token is invalid or lacks required
   scopes or delegation claims, the resource server returns a challenge
   with a WWW-Authenticate header (e.g., error="invalid_token" or
   error="insufficient_scope").  The client then redirects the user's
   user-agent to the authorization server's authorization endpoint to
   obtain an authorization code.

   GET /some/protected/resource HTTP/1.1
   Host: resource-server.com
   Authorization: Bearer <existing_access_token_if_any>

4.4.1.  Resource Server Processing

   Upon receiving the request, the Resource Server MUST validate the
   Access Token (if provided).  This validation includes:




Senarath & Dissanayaka  Expires 27 February 2026               [Page 13]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


   1.  Ensuring the token is present if required.

   2.  Verifying the token's signature, issuer, and audience.

   3.  Checking if the token is expired or revoked.

   4.  Confirming the token contains the necessary scopes for the
       requested action.

   5.  If the resource requires action on behalf of a specific Actor,
       verifying the token contains the appropriate delegation claims
       (e.g., an act claim) for that Actor.

   If the Access Token is missing, invalid, or insufficient for the
   requested action, the Resource Server MUST return an error response,
   typically an HTTP 400 (Bad Request), HTTP 401 (Unauthorized) or HTTP
   403 (Forbidden), including a WWW-Authenticate header.

4.4.2.  The WWW-Authenticate Response Header Field

   The Resource Server MUST include a WWW-Authenticate header field in
   the response to indicate the reason for the challenge.  This header
   field MUST include the error code and other relevant information.

   Example:

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope", error_description="The access token does not have the required scope(s)", required_scope="scope1 scope2"
Content-Type: application/json;charset=UTF-8

{
  "error": "insufficient_scope",
  "error_description": "The access token does not have the required scope(s)",
  "required_scope": "scope1 scope2"
}

5.  Security Considerations

   Actor Authentication:  The security of this flow relies heavily on
      the Authorization Server's ability to securely authenticate the
      actor during the Token Request using the Actor Token.  The method
      by which actors obtain and secure their Actor Tokens is critical
      and outside the scope of this specification, but MUST be
      implemented securely.

   Proof Key for Code Exchange (PKCE):  PKCE [RFC7636] is REQUIRED to





Senarath & Dissanayaka  Expires 27 February 2026               [Page 14]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


      prevent authorization code interception attacks, especially
      relevant if the client (and thus the actor receiving the code) is
      a public client or runs in an environment where the redirect URI
      cannot be strictly protected.

   Single-Use and Short-Lived Authorization Codes:  Authorization Codes
      MUST be single-use and have a short expiration time to minimize
      the window for compromise.

   Binding Code to Actor and Client:  The Authorization Server MUST bind
      the Authorization Code to the specific user, client (client_id),
      and requested actor (requested_actor) during issuance and verify
      this binding during the Token Request.

   Clear User Consent:  The consent screen presented to the user SHOULD
      clearly identify the actor and the requested scopes to ensure the
      user understands exactly what authority they are delegating and to
      whom.

   Auditability:  The claims in the Access Token (sub, act) provide
      essential information for auditing actions performed using the
      token, clearly showing who (user) authorized the action, which
      application (client) facilitated it, and which entity (actor)
      performed it.

6.  Normative References

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

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

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

   [RFC7636]  Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
              for Code Exchange by OAuth Public Clients", RFC 7636,
              DOI 10.17487/RFC7636, September 2015,
              <https://www.rfc-editor.org/rfc/rfc7636>.

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



Senarath & Dissanayaka  Expires 27 February 2026               [Page 15]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 2025


   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8693>.

   [RFC9068]  Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
              Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
              2021, <https://www.rfc-editor.org/rfc/rfc9068>.

Authors' Addresses

   Thilina Shashimal Senarath
   WSO2
   Email: thilinasenarath97@gmail.com


   Ayesha Dissanayaka
   WSO2
   Email: ayshsandu@gmail.com
































Senarath & Dissanayaka  Expires 27 February 2026               [Page 16]

categories:
["Identity / authentication for AI agents", "Human-agent interaction", "Agent-to-agent communication protocols"]


name: draft-sarischo-6gip-aiagent-requirements
rev: 00
title: AI Agents for 6G Requirements and Implementation Approaches
time: 2025-09-11T16:24:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-15T16:24:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Autonomous netops", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420400+00:00
abstract:
This document provides requirements for 3GPP Artificial Intelligence/
   Machine Learning (AI/ML) Agents for the 6th generation mobile
   network, or 6G.  Requirements depend on the types and application
   areas of agents.  We describe each type and state their requirements.
   AI Agent implementation efforts, how APIs can be discovered, how
   inter-domain and intra domain AI Agents can be discovered using DNS
   lookup are explained.

full_text:
Network Working Group                                        B. Sarikaya
Internet-Draft                                              Unaffiliated
Intended status: Standards Track                               R. Schott
Expires: 15 March 2026                                  Deutsche Telekom
                                                       11 September 2025


      AI Agents for 6G Requirements and Implementation Approaches
              draft-sarischo-6gip-aiagent-requirements-00

Abstract

   This document provides requirements for 3GPP Artificial Intelligence/
   Machine Learning (AI/ML) Agents for the 6th generation mobile
   network, or 6G.  Requirements depend on the types and application
   areas of agents.  We describe each type and state their requirements.
   AI Agent implementation efforts, how APIs can be discovered, how
   inter-domain and intra domain AI Agents can be discovered using DNS
   lookup are explained.

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 15 March 2026.

Copyright Notice

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










Sarikaya & Schott         Expires 15 March 2026                 [Page 1]

Internet-Draft         AI/ML  Agents requirements         September 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.  6G Network AI Agents  . . . . . . . . . . . . . . . . . . . .   3
     2.1.  AI Agents collaboration with third-party AI using LLM . .   4
     2.2.  AI Agents for Artificial General Intelligence . . . . . .   4
     2.3.  AI Agents on Device . . . . . . . . . . . . . . . . . . .   5
     2.4.  Collaborative AI Agents . . . . . . . . . . . . . . . . .   5
     2.5.  Home Robots . . . . . . . . . . . . . . . . . . . . . . .   6
     2.6.  Built-in Intelligent Communication Assistant  . . . . . .   6
   3.  Implementation Issues . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Future Work . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Artificial Intelligence (AI) has historically been defined as the
   science and engineering to build intelligent machines capable of
   carrying out tasks as humans do.  Inspired from the way human brain
   works, machine learning (ML) is defined as the field of study that
   gives computers the ability to learn without being explicitly
   programmed.  Since it is believed that the main computational
   elements in a human brain are 86 billion neurons, the more popular ML
   approaches are using “neural network” as the model.  Neural networks
   (NN) take their inspiration from the notion that a neuron’s
   computation involves a weighted sum of the input values.  A
   computational neural network contains the neurons in the input layer
   which receive some values and propagate them to the neurons in the
   middle layer of the network, which is also called a “hidden layer”.
   The weighted sums from one or more hidden layers are ultimately
   propagated to the output layer, which presents the final outputs of
   the network.




Sarikaya & Schott         Expires 15 March 2026                 [Page 2]

Internet-Draft         AI/ML  Agents requirements         September 2025


   Recurrent neural network (RNN) models are a type of deep neural
   networks which use sequential data feeding.  The input of RNN
   consists of the current input and the previous samples.  RNN models
   recently have been replaced with parallel processing [LLMPaper] and
   the transformer architecture and they are being used in the natural
   language processing task on mobile devices, e.g., language modeling,
   machine translation, question answering, word embedding, and document
   classification.  The resulting system is commonly called Large
   Language Model (LLM).

   AI Agents play a crucial role in modern telecommunications by
   enabling intelligent automation, decision-making, and adaptive
   network management.  These agents are software-driven entities that
   leverage artificial intelligence, including machine learning and
   natural language processing, to interact with users, applications,
   and network components.  In a 6G environment, AI agents enhance
   network efficiency by dynamically optimizing resources, predicting
   network conditions, and facilitating providing seamless communication
   between services.  By integrating Large Language Models (LLM), AI
   agents can understand complex requests, translate them into
   actionable insights, and orchestrate 3GPP services (e.g.
   communication service, sensing service, AI-related) network
   capabilities and functions autonomously, ultimately improving user
   experience when consuming the 3GPP services, operational efficiency,
   and service innovation.

   This document aims to present the types of AI agents 6G network needs
   and the requirements needed to support each case.  We discuss
   implementation issues next.

   In a related work, [aiagent6g] attempts to analyze the agent protocol
   requirements and relevant enabling technologies based on 6G mobile
   communication system specific characteristics.

   On the other hand [aiagentusecase] introduces use cases and
   requirements on AI Agents in 6G networks.  It attempts to elaborate
   on the requirements for high performance communication, security and
   energy efficiency.

2.  6G Network AI Agents

   The following use cases and requirements are from [TR22.870].









Sarikaya & Schott         Expires 15 March 2026                 [Page 3]

Internet-Draft         AI/ML  Agents requirements         September 2025


2.1.  AI Agents collaboration with third-party AI using LLM

   A third-party application (e.g. a smart city traffic management
   system) AI Agent sends a text-based request or query to the 6G
   network.  The request is processed by an AI agent in the 6G network
   that leverages LLMs and the network's advanced capabilities (e.g.
   sensing, real-time data processing, telemetry, analytics, and others)
   to provide a response or perform an action.  This interaction mimics
   how users interact with chatbots like ChatGPT, but it is tailored for
   network-specific tasks and applications.

   *  Requirements

   The network shall be able to support secure means to expose its
   services to the authorised third-party AI agent based on its intent.

   The network shall be able to take into account information related to
   user mobility context, subscription information when invoking 3GPP
   services based on user intent(s).

2.2.  AI Agents for Artificial General Intelligence

   Autonomous agents (AI agents) have long been recognized as a
   promising approach to achieving artificial general intelligence
   (AGI), which is expected to accomplish tasks through self-directed
   planning and actions.  In recent years, these agents, leveraging the
   capabilities of LLMs, are expected to effectively perform diverse
   tasks in social science, natural science, and engineering, among
   others.  AI agents can take on various forms, such as embodied
   intelligent robots, virtual assistants, and autonomous systems (e.g.
   drones).

   *  Requirements

   The network shall support trusted network access for 3rd party AI
   agent and support a mechanism to expose 3rd party AI agent’s
   attributes (e.g. related users, sensing capabilities, AI
   capabilities, service features) to other 3rd party AI agents.

   The network shall be able to support security identification for 3rd
   party AI agents provided by authorized 3rd party associated with a
   user (e.g. AI agents belonging to a customer).

   The network shall support mechanisms for 3rd party AI agents to
   provide/register their attributes (e.g. sensing capabilities, AI
   capabilities, service features, associated authorized users) to 6G
   network, and discover other authorized 3rd party AI agents to achieve
   collaborative task.



Sarikaya & Schott         Expires 15 March 2026                 [Page 4]

Internet-Draft         AI/ML  Agents requirements         September 2025


   The network shall provide means to support efficient and secure
   communication between 3rd party AI agents over a wide area in a group
   considering the diverse lifetime of tasks.

2.3.  AI Agents on Device

   AI agent on device will be popular in 6G era, due to the fast
   development on device-based computing power and model light-
   weighting.

   *  Requirements

   The system shall provide a suitable means for an AI agent application
   on UE to invoke some 3GPP services (e.g. IMS service).

   The system shall provide an efficient way to expose information (e.g.
   change of QoS) to the application on the UE.

   The network shall be able to support the message exchange between the
   AI agent application on different UEs considering the diverse
   capabilities supported by different AI applications (e.g. AI agents
   applications).

2.4.  Collaborative AI Agents

   AI Agents can perform tasks for or represent e.g. devices, persons,
   drones, or cars.  These AI Agents may be either implemented in a UE
   or in the network.  By offloading tasks to the network, devices can
   save on complexity and energy consumption.  Furthermore, an AI Agent
   in the network can still represent a device, person, drone or car,
   when that device, person, drone or car is not reachable, e.g. because
   of radio conditions or battery outage.  Offload can happen towards a
   local/edge network but can also be to a nearby other device with more
   processing capabilities.

   *  Requirements

   The system shall support hosting of large amounts of AI agent
   applications managed and controlled by the 6G core network and/or
   multiple AI Agent applications on a UE.

   The system shall support secure interoperability between AI Agents
   and between AI Agents and applications to achieve a collaborative
   task.







Sarikaya & Schott         Expires 15 March 2026                 [Page 5]

Internet-Draft         AI/ML  Agents requirements         September 2025


2.5.  Home Robots

   Home robots will engage in household chores based on preconfigured
   models, such as sweeping the floor, vacuuming, folding clothes,
   washing dishes, and organizing rooms.  They will also take care of
   family members by monitoring health data, reminding medication, and
   dialling emergency calls.  Additionally, they will socialize and
   entertain with humans while interacting with other smart devices to
   create a more intelligent ecosystem.  All of this aims to bring us a
   more convenient, comfortable, and safe family life.  All or part of
   the AI inference services are provided by home robots.

   *  Requirements

   The network shall be able to provide AI service (e.g. AI model
   inference) to a UE.

   The system shall be able to support negotiation of the service
   performance (e.g. latency, inference accuracy), between UE and 6G
   network, when providing AI service (e.g. AI model inference).

   The network shall be able to support mechanism to guarantee the
   service performance (e.g. latency, inference accuracy) when providing
   AI service (e.g. AI model inference).

2.6.  Built-in Intelligent Communication Assistant

   Empowered by the rapid development of the AI technology, the service
   providers are able to provide personalized and enriched services to
   their users when making daily routines within their homes, at their
   workplaces, in stores, at restaurants, as well as traveling for work
   or leisure.  These kinds of personalized services are widely enjoyed
   by the customers.  For example, a lot of countries are facing a major
   challenge in providing care support for senior citizens due to their
   rapidly ageing population and declining old-age support.  The
   capability to introduce AI techs to provide more personalized and
   real-time communication services would be a great help.

   *  Requirements

   The network (e.g. in conjunction to IMS) shall be able to provide
   intelligent communication assistant service to users.

   The network shall support charging information collection for the
   intelligent communication assistant service.






Sarikaya & Schott         Expires 15 March 2026                 [Page 6]

Internet-Draft         AI/ML  Agents requirements         September 2025


   The network (e.g. in conjunction to IP Multimedia Subsystem, IMS)
   shall be able to support the interaction and collaboration between
   different user’s intelligent communication assistants, e.g. during an
   IMS calling service, both calling and callee parties are using
   intelligent communication services.

   The network (e.g. in conjunction to IMS) shall be able to support the
   intelligent communication assistant to use operator native
   capabilities (e.g. AR rendering, XR rendering in service hosting
   environment, SMS or voice).

3.  Implementation Issues

   In the section above Section 2 we described various kinds of AI
   agents 6G network needs.  In this section we will look at AI Agent
   implementation efforts so far.

   General purpose AI Agents like a travel AI Agent, loan handling,
   shopping for clothing AI agent are discussed in [aiprotocol].  These
   types of AI Agents can be built using Large Language Models, like GPT
   (Generative Pre-Trained Transformer)-4o, Gemini, Anthropic, etc.
   There are also open source ones like Llama.

   Like LLM tools, AI Agents work on prompt-completion mode, they get
   prompts and they reply with completions.  Designing AI Agents for
   specific tasks is developing to be an engineering practice.

   We will shortly describe the steps involved:

   Protocols involved include IP, TCP, UDP, QUIC for host communication,
   HTTP, SIP and RTP at the application layer.  Above all that are the
   protocols for AI Agents.  So far Model Context Protocol (MCP) [MCP]
   and Agent to Agent protocol [Agent2agent] which operate at the HTTP
   level and are expected to be standardized.

   AI Agent to API communication.  Agents provide services to user by
   invoking APIs either in the same domain or another domain.  AI Agent
   design includes to teach the agent what they are and give them enough
   information to know how to use them appropriately.

   User to AI Agent communication could be via various means like a
   phone call, a chat like by a chat app or via video.  Several types of
   media are involved simultaneously using protocols, tools established
   currently and widely used.







Sarikaya & Schott         Expires 15 March 2026                 [Page 7]

Internet-Draft         AI/ML  Agents requirements         September 2025


   AI Agent to user communication is similarly involving well
   established techniques like email, voice or chat when both the user
   and agent are on the same administrative domain.  If not,
   administrative configuration is required to allow the systems to
   communicate with each other using protocols like SIP.

   AI Agent implementation points to many areas in user to AI Agent, AI
   Agent to API and AI Agent to AI Agent where new protocol work is
   needed, these are discussed next.

3.1.  Future Work

   In AI Agent to API case, the discovery of APIs can happen using a
   well known URI and a link relation.  [RFC9727] defines the api-
   catalog well-known URI to which HTTPS GET request to the Publishers
   site returns an API catalog document.

   In the case of user to AI Agent, AI Agent discovery can be made using
   DNS [ajand].  For that purpose a DNS TXT record is specified.
   Providers advertise their agent service by publishing a single DNS
   TXT record at _agent.<domain> such as

   text _agent.example.com. 300 IN TXT
   "v=aid1;u=https://api.example.com/mcp;p=mcp;a=pat;s=Example AI Tools"

   which advertises a remote AI Agent called mcp.  Local agents can be
   advertised using Docker.

   Agents can be discovered using DNS lookups querying TXT records
   giving the domain name.  If the query succeeds and the protocol is
   supported the client can start using the AI Agent with the protocol.

   Authentication and authorization [RFC6749], [RFC6819] are to be
   discussed later.

4.  Security Considerations

   Security considerations of 6G AI Agents is TBD.

5.  IANA Considerations

   There are no IANA considerations for this document.

6.  Acknowledgements

7.  References

7.1.  Normative References



Sarikaya & Schott         Expires 15 March 2026                 [Page 8]

Internet-Draft         AI/ML  Agents requirements         September 2025


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

   [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", RFC 6819,
              DOI 10.17487/RFC6819, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6819>.

   [RFC9727]  Smith, K., "api-catalog: A Well-Known URI and Link
              Relation to Help Discovery of APIs", RFC 9727,
              DOI 10.17487/RFC9727, June 2025,
              <https://www.rfc-editor.org/rfc/rfc9727>.

7.2.  Informative References

   [Agent2agent]
              Google, "Agent2Agent (A2A) Protocol", June 2025,
              <https://google.github.io/A2A/>.

   [aiagent6g]
              Yang, C., Huang,, H., Akhavain, A., Liu, F., An,, X.,
              Xing,, W., Li, J., Wang, A., and Y. Wencong,,
              "Requirements and Enabling Technologies of Agent Protocols
              for 6G Networks", Work in Progress, Internet-Draft, draft-
              hw-ai-agent-6g-00, 19 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-hw-ai-agent-
              6g-00>.

   [aiagentusecase]
              Yu, M., Wang, A., Li, J., and Z. Li, "AI Agent Use Cases
              and Requirements in 6G Network", Work in Progress,
              Internet-Draft, draft-yu-ai-agent-use-cases-in-6g-01, 7
              July 2025, <https://datatracker.ietf.org/doc/html/draft-
              yu-ai-agent-use-cases-in-6g-01>.

   [aiprotocol]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [ajand]    Agent Community, "Agent Identity and Discovery (AID)",
              August 2025, <https://docs.agentcommunity.org/aid/>.

   [LLMPaper] al., A. V. et., "Attention is all you need", August 2017,
              <https://arxiv.org/html/1706.03762v7>.



Sarikaya & Schott         Expires 15 March 2026                 [Page 9]

Internet-Draft         AI/ML  Agents requirements         September 2025


   [MCP]      Anthropic, "Model Context Protocol", June 2025,
              <https://modelcontextprotocol.io/>.

   [TR22.870] 3rd Generation Partnership Project, "Study on 6G Use Cases
              and Service Requirements", June 2025,
              <https://www.3gpp.org/ftp/Specs/
              archive/22_series/22.870/22870-031.zip>.

   [TS22.261] 3rd Generation Partnership Project, "Service Requirements
              for the 5G System", December 2024.

Authors' Addresses

   Behcet Sarikaya
   Unaffiliated
   Email: sarikaya@ieee.org


   Roland Schott
   Deutsche Telekom
   Deutsche-Telekom-Allee 9
   64295 Darmstadt
   Germany
   Email: Roland.Schott@telekom.de



























Sarikaya & Schott         Expires 15 March 2026                [Page 10]


name: draft-hong-nmrg-agenticai-ps
rev: 00
title: Motivations and Problem Statement of Agentic AI for network management
time: 2025-10-20T14:08:11Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T14:08:11Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420402+00:00
abstract:
This document outlines the key objectives of introducing Agentic AI
   to the field of network management and highlights the fundamental
   issues with existing technologies that must be addressed to achieve
   these goals.  It emphasizes the necessity for relevant groups within
   the IETF/IRTF and presents the core technological areas requiring
   standardization.  The aim of Agentic AI is to facilitate a paradigm
   shift in which multiple autonomous AI agents collaborate to fully
   automate network operation, management and security.

full_text:
Network Management                                               Y. Hong
Internet-Draft                                        Daejeon University
Intended status: Informational                                   J. Youn
Expires: 23 April 2026                               DONG-EUI University
                                                                   Q. Wu
                                                                  Huawei
                                                               B. Claise
                                                          Everything OPS
                                                         20 October 2025


 Motivations and Problem Statement of Agentic AI for network management
                  draft-hong-nmrg-agenticai-ps-00

Abstract

   This document outlines the key objectives of introducing Agentic AI
   to the field of network management and highlights the fundamental
   issues with existing technologies that must be addressed to achieve
   these goals.  It emphasizes the necessity for relevant groups within
   the IETF/IRTF and presents the core technological areas requiring
   standardization.  The aim of Agentic AI is to facilitate a paradigm
   shift in which multiple autonomous AI agents collaborate to fully
   automate network operation, management and security.

Discussion Venues

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

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

   Source for this draft and an issue tracker can be found at
   https://github.com/billwuqin/agentic-ai-ps.

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 23 April 2026.

Copyright Notice

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

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

Table of Contents

   1.  Introduction
   2.  Conventions and Definitions
   3.  Agentic AI for Network mMnagement
     3.1.  Role of Agentic AI in Network Operations
     3.2.  Operation of Agentic AI for Network Management
       3.2.1.  Intelligence core
       3.2.2.  Execution & Interaction
   4.  Problem Statement of Existing Techniques for Agentic AI
     4.1.  Architectural Bottlenecks and the Failure of Centralization
     4.2.  Absence of agent-to-agent (A2A) Semantic Interoperability
     4.3.  Lack of Dynamic Trust and Accountability in Autonomous
           Behavior
     4.4.  Real-time Data Validity and Resilience Issues
     4.5.  Problems with the Existing IBN System: Rigidity of the
           Intent Translation Engine (ITE)
     4.6.  ANIMA ASA's Problem: Cognitive Simplicity
   5.  Objectives of Agentic AI for Operations & Management
     5.1.  Objective 1 - Autonomous Network Operations & Management
     5.2.  Objective 2 - Intelligent & Dynamic Resource Orchestration
     5.3.  Objective 3 - Predictive & Adaptive Network Security
     5.4.  Objective 4 - Enabling Novel Network Service Models
     5.5.  Objective 5 - Autonomous, High-Fidelity & Action-Aware
           Network Measurement
   6.  Use cases of Agentic AI for Operations & Management
     6.1.  Intent Based Service Delivery
     6.2.  Cross-layer and Cross-domain Multi-Agent communication for
           Complaint handling
     6.3.  AI Agent Driven Network Management
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgments
   Authors' Addresses

1.  Introduction

   The explosive growth of digital services and the increasing
   complexity of networks in 5G and future 6G environments demand real-
   time responsiveness, high efficiency and the ability to make
   autonomous decisions on a large scale from operational environments.
   To overcome the limitations of existing static automation methods and
   human-led Intent-Based Networking (IBN), a new Agentic AI-based
   paradigm is required.  This involves introducing autonomous software
   entities that can interpret information, make decisions, perform
   meaningful autonomous actions and adjust plans in response to
   changing circumstances.

   Unlike traditional automation, which relies on pre-programmed rules,
   agentic AI uses autonomous decision-making capabilities to handle
   large-scale network activities and customer requests swiftly and
   accurately.  These agents perform tasks such as network traffic
   management, fault resolution, and customer interaction support,
   continuously executing responses that previously required manual
   human review or escalation.

   Agentic AI uses large language models (LLMs) to encompass a wide
   variety of capabilities, such as reasoning, problem-solving,
   interacting with external environments and performing actions, which
   extend far beyond natural language processing.  It can decompose
   tasks, breaking down complex objectives into specific tasks and
   subtasks to achieve them.  This cognitive capacity enables a
   persistent cognitive cycle (observation, inference, action),
   continuously aligning network operations with high-level business
   intent.

   When such autonomous agents are widely deployed across the
   communications and network domains, standardized protocols are
   essential to ensure interoperability and security between different
   vendor platforms and network domains.  The collaborative nature of
   agent-based AI systems (multi-agent systems, or MAS) means that
   standardized agent-to-agent protocols (A2A protocols) must be defined
   to prevent silos forming within the system and to facilitate
   discovery, understanding and collaboration between agents.

2.  Conventions and Definitions

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

3.  Agentic AI for Network mMnagement

3.1.  Role of Agentic AI in Network Operations

   The complexity of network management and network operations are
   increasing exponentially, due to the increased size of networks and
   the increased frequency of change, for for the new 5G and future 6G
   services.  This makes it increasingly difficult for existing
   automation techniques to meet the requirements for operational
   efficiency and service quality.  Consequently, Agentic AI is an
   essential technological advancement for the realization of autonomous
   networks.

   Agentic AI refers to intelligent systems that can act autonomously to
   achieve specific business objectives with minimal human supervision.
   These systems can reason through multi-step problems and adjust their
   actions in real time.  Unlike passive traditional AI systems that
   respond only to direct commands, Agentic AI is an active system
   operating within an autonomous, closed-loop framework.  This
   framework enables the system to perceive its environment, reason,
   plan a sequence of actions and execute them using various tools and
   APIs.  This autonomy enables it to perform complex, multi-step
   processes such as software development, data analysis and network
   management.

   The aim of autonomous networks is to leverage the capabilities of
   Agentic AI in order to transition operations and maintenance from
   static, human-managed, rule-based automation to dynamic, intent-based
   automation that is governed by humans.  The ultimate goal is to
   reduce management costs and complexity, enabling rapid business
   optimization at unprecedented levels.

   The primary objective of Agentic AI is to enable autonomous decision-
   making and the resolution of complex, multi-domain tasks.  This is
   crucial in bringing operations closer to the level of autonomy that
   Agentic AI aims to achieve, by facilitating cross-domain
   collaboration.  To achieve this, Agentic AI must align network
   capabilities with strategic business priorities, such as improving
   customer experience and reducing operational costs.  This involves
   translating comprehensive business intent into localized, actionable
   network configuration plans.

   Agentic AI optimizes resource allocation based on real-time demand
   and business objectives, enabling smarter resource and energy usage.
   In architecture research for 6G, for example, the application of
   constrained agentic AI techniques focused on energy efficiency and
   secure real-time learning for dynamic resource allocation has been
   identified as a key objective [Agentic-AI-Wireless].

   The Autonomic Networking Integrated Model and Approach (ANIMA)
   Working Group of the IETF developed the Autonomic Service Agent (ASA)
   for autonomic networking.  [RFC7575] defines the ASA as An agent
   implemented on an autonomic node that implements an autonomic
   function, either in part (in the case of a distributed function) or
   whole [RFC7575].  In other words, the ASA is a core component of
   ANIMA: a software module that performs autonomic functions on network
   nodes.  The ANIMA Working Group is defining design guidelines,
   lifecycle management, authorization and coordination standards for
   the ASA [ANIMA].

   IETF’ AI Preferences (AIPREF) Working Group is focused on
   standardizing a common vocabulary and mechanism through which users
   and systems can express their preferences regarding the use of their
   content in the development, training, deployment and use of AI models
   [AIPREF].

3.2.  Operation of Agentic AI for Network Management

   The principal components of agentic AI can be broadly divided into
   the intelligence core and the execution tool domain.

3.2.1.  Intelligence core

   The intelligence core is responsible for an agent's decision-making
   and problem-solving capabilities.  Large language models (LLMs) or
   specialized AI models form the basis of this core.  Reasoning Engine/
   LLM: This constitutes the core of the agent's brain.  It understands
   abstract objectives (intent) received from users or higher-level
   systems, creates step-by-step plans (plan) to achieve them, evaluates
   the outcomes of execution (reflection) and uses logical reasoning to
   modify plans or determine subsequent steps.

   Memory is the data repository that agents learn from and refer to.

   *  Short-term memory: It stores the context of the current task and
      recent execution results.

   *  Long-term memory: It stores persistent information such as
      previously successful solutions, general knowledge and network
      architecture guidelines.

   The tool Orchestrator manages the list of external tools (APIs,
   functions) available for agents to use.  During the planning phase,
   it determines which tool is most appropriate and, during the
   execution phase, it is responsible for calling the tool and
   accurately configuring the necessary parameters.

3.2.2.  Execution & Interaction

   These components enable the agent to communicate with and make
   changes to the external environment (i.e. the network or system).

   *  Tool set/capability: A collection of all the external interfaces
      that an agent uses to perform tasks within a network environment.

   *  Execution environment: A sandbox environment in which code
      generated according to the plan is executed safely, and external
      tools are invoked.

   *  Sensing/observation mechanism: The channel through which the agent
      verifies execution results and collects the current environmental
      state.  This involves more than just invoking tools; it
      continuously draws network events, sensor data and similar inputs
      into a feedback loop.

    +----------------------------------------------------------------+
    |                                                                |
    |   +--------------------------+                                 |
    |   |  1.GOAL / INTENT(Input)  |                                 |
    |   +------------------|-------+                                 |
    |                      v                                         |
    |            +---------+----------------+                        |
    |            |    2.AI AGENT(Brain)     |                        |
    |            |  (LLM/Reasoning Engine)  |                        |
    |            +---|-----------------|----+                        |
    |                |  Memory/Context |    |                        |
    |                +-----------------+    |                        |
    |                ^                      v                        |
    |      +---------|----------+    +------|------------+           |
    |      | 4.REFLECT(Compare) |    |  3.PLAN(Sequence) |           |
    |      | (Evaluate Outcome) |<---| (Action Breakdown)|           |
    |      +---------|----------+    +------|------------+           |
    |                |                      v                        |
    |                |   +------------------+----------------------+ |
    |                +---| 5.EXECUTE(Action) via Tool Orchestrator | |
    |                    +------------------|----------------------+ |
    |                                       v                        |
    |                 +---------------------+-----------------+      |
    |                 | 6.TOOL USE(API Calls & Configuration) |      |
    |                 |     (RESTCONF, Monitoring, etc.)      |      |
    |                 +-----------|-------------------|-------+      |
    |                             v                   ^              |
    |                 +-----------+-------------------+--------+     |
    |                 |   7.NETWORK ENVIRONMENT (The World)    |     |
    |                 | (Apply Changes & Sense/Observe State)  |     |
    |                 +----------------------------------------+     |
    |                                                                |
    +----------------------------------------------------------------+

                     Figure 1: Execution & Interaction

4.  Problem Statement of Existing Techniques for Agentic AI

4.1.  Architectural Bottlenecks and the Failure of Centralization

   Existing AI and automation systems have often relied on centralized
   infrastructure for data aggregation and heavy computing.  However,
   these centralized models cannot handle the volume, velocity, and
   distributed nature of Agentic AI workloads.  Centralized AI systems
   are constrained by central infrastructure, resulting in high latency
   due to round-trip times to the cloud.  Such latency is unacceptable
   for real-time applications such as self-healing and 5G slicing
   management.  There is also the issue that the central server becomes
   a bottleneck, limiting scalability.  The inherent limitations of such
   centralized models (single point of failure (SPoF), latency)
   inevitably drive Agentic AI architectures towards a distributed mesh
   form.  This leverages local processing at the edge for low latency
   and fault tolerance, requiring the standardization of distributed
   control and communication mechanisms that transcend conventional
   centralized SDN/management models.

4.2.  Absence of agent-to-agent (A2A) Semantic Interoperability

   Agentic systems are often built by different vendors using various
   frameworks, leading to fragmented and siloed system operations.
   Complex network management tasks require the decomposition of work
   and collaboration between specialized agents.  Without standardized
   agent-to-agent (A2A) protocols, bespoke connectors become necessary
   to connect these fragmented systems, slowing down development and
   integration speeds.

   Standardization must define consistent payloads and interfaces that
   support real-time interactions between systems, enabling agents to
   discover, understand, and collaborate with one another regardless of
   their underlying implementations.

4.3.  Lack of Dynamic Trust and Accountability in Autonomous Behavior

   The introduction of AI agents as autonomous entities performing
   actions at machine speed presents significant security and governance
   challenges.  Traditional identity and access management (IAM) focuses
   on human users or predefined roles.  However, autonomous agents
   operate with dynamic intent, require context-aware access, and must
   maintain provable accountability for every action they perform.
   Without a robust Zero Trust framework specifically designed for non-
   human autonomous entities, there is a risk of catastrophic security
   breaches or manipulation where autonomous systems could outpace human
   control capabilities.

4.4.  Real-time Data Validity and Resilience Issues

   The decision-making of AI agents is determined by the quality of the
   data they receive.  In a network environment, data quality is of
   paramount importance.  Incomplete, delayed, semantic-less, context-
   less, or corrupted data feeds can lead to severe operational or
   financial losses when agents take autonomous actions (e.g., traffic
   rerouting, forced execution of financial transactions).  Therefore,
   it must extend beyond the current focus on bandwidth and speed to
   include quality verification of the data agents rely upon and
   resilience of service paths.  This is essential to meet the
   requirements of continuously operating intelligent agents.

4.5.  Problems with the Existing IBN System: Rigidity of the Intent
      Translation Engine (ITE)

   Existing IBN systems rely on the Intent Translation Engine (ITE) or
   the Intent-Based System (IBS) spatial functionality to bridge the gap
   between the business intent and the network operational
   infrastructure.  This translation is typically driven by predefined
   data models such as YANG models and lacks the necessary adaptive
   flexibility when unforeseen conditions arise.  IBN fundamentally
   shifts operational modes to a dynamic intent-based approach, yet
   retains the inherent limitation that control remains under human
   oversight.  Agentic AI minimises or eliminates human intervention in
   this cognitive loop through LLM-based reasoning and planning
   capabilities, refining the IBN closed loop by integrating continuous
   reasoning and conflict resolution capabilities into the cognitive
   layer.  These capabilities represent what was lacking in the
   classical IBN definition and form the core technical objective.

4.6.  ANIMA ASA's Problem: Cognitive Simplicity

   ANIMA's ASAs are typically designed for specific, localized
   autonomous functions (e.g., prefix management, bootstrapping).  They
   rely heavily on predefined policy structures and lack the complex
   reasoning, planning, or self-reflection capabilities characteristic
   of Agentic AI (LLM-based task decomposition).  ANIMA's ASA is
   conceptually a precursor to Agentic AI, but lacks a cognitive core
   (LLM/inference engine).  Agentic AI introduces LLM-based planning and
   tool-use capabilities that require complex, semantic negotiation
   (A2A) beyond simple information exchange (GeneRic Autonomic Signaling
   Protocol; GRASP), demonstrating the necessity for a dedicated
   protocol layer that extends beyond the existing ANIMA framework.

5.  Objectives of Agentic AI for Operations & Management

5.1.  Objective 1 - Autonomous Network Operations & Management

   Beyond minimizing human intervention, it must implement a Autonomous
   Driving Netowrk (defined in TMF) that autonomously recognises,
   diagnoses, infers, and resolves issues even in unpredictable
   situations.

   Key Features:

   *  Predictive & Proactive Fault Management: AI agents learn traffic
      patterns, logs, and performance metrics in real time to identify
      potential causes before faults occur.  The network autonomously
      reroutes traffic or reallocates resources to prevent service
      interruptions at source.

   *  Intelligent Root Cause Analysis: In complex, intertwined fault
      scenarios, multiple agents collaborate to synthesize distributed
      data.  They deduce the root cause as a "problem of correlations"
      rather than a single point of failure and propose solutions.

   *  Autonomous Configuration & Optimization: AI agents comprehend
      high-level objectives such as ‘optimize user experience’ and
      autonomously configure and continuously fine-tune routing
      protocols, QoS policies, security rules, and other elements to
      achieve them.

5.2.  Objective 2 - Intelligent & Dynamic Resource Orchestration

   To address unpredictable traffic demands such as 6G, holographic
   communications, and large-scale IoT, network resources (computing,
   storage, bandwidth) are allocated and coordinated in real time and
   proactively.

   Key Features:

   *  Dynamic Network Slicing: AI agents recognize application
      requirements (latency, bandwidth, etc.) in real time, instantly
      creating, scaling, and downsizing customized network slices per
      user or service.

   *  Cross-Domain Resource Negotiation: AI agents distributed across
      networks of different telecommunications or cloud providers
      negotiate in real time to dynamically secure optimal resources,
      ensuring end-to-end quality for global services.

   *  Edge Computing Resource Optimization: By predicting edge node load
      and user mobility, AI agents dynamically reallocate workloads to
      optimal edge nodes while ensuring service continuity.

5.3.  Objective 3 - Predictive & Adaptive Network Security

   Beyond defending against known attack patterns, AI agents
   autonomously detect unknown zero-day attacks or advanced persistent
   threats (APTs) and reconfigure defence systems in real time.

   Key Features:

   *  Autonomous threat hunting and response: Security agents
      continuously detect minute anomalies across the entire network.
      If an anomaly is deemed a threat, they respond immediately by
      taking action such as isolating infected nodes or blocking attack
      traffic, all without human intervention.

   *  Dynamic Defense Posture: AI agents dynamically modify firewall
      policies, access control lists (ACLs), and traffic filtering rules
      in real time based on attack type and intensity, thereby
      minimizing the attack surface.

5.4.  Objective 4 - Enabling Novel Network Service Models

   By transforming the network itself into a single, vast distributed AI
   platform, it enables new communication services and business models
   that were previously impossible.

   Key Features:

   *  Intent-driven Service Creation: When a user requests in natural
      language, 'I want to play a lag-free VR game with my friends,' an
      AI agent interprets this and provides a Network-as-a-Service that
      instantly allocates the necessary resources (such as network
      slices and edge servers).

   *  Semantic Communication: Communication focuses on the “meaning” or
      “purpose” conveyed by data rather than the bits themselves,
      enabling ultra-efficient communication that achieves maximum
      effect with minimal data transmission.

5.5.  Objective 5 - Autonomous, High-Fidelity & Action-Aware Network
      Measurement

   To turn raw network telemetry into trustworthy, context-rich insight
   that continuously retrains itself, explains its own uncertainty, and
   feeds closed-loop control without human analysts.

   Key Features: - Generative Telemetry Synthesis & Gap-Filling: Gen-AI
   models learn multi-modal telemetry (packets, flow records, SNMP,
   syslogs, DPI, spectrum scans) and hallucinate statistically faithful
   “missing data” where sensors are sparse or silent, delivering 100 %
   coverage at any time/space scale.

   *  Semantic Anomaly Narratives & Root-Cause Metrics: Instead of
      threshold alerts, the model outputs human-readable stories
      (“Between 02:13-02:19 UTC, TCP RTT on slice-C rose 38 % because 17
      % of ECN-marked packets were re-routed via the Seattle POP due to
      a mis-announced BGP community”).  Each sentence is back-traced to
      verifiable measurement samples.

   *  Self-Driving Measurement Campaigns: The AI translates high-level
      intents (“tell me if user-perceived 4 K latency could exceed 150
      ms during the next football final”) into dynamic sampler
      schedules, probe paths, and packet structures; it launches the
      campaign, stops when statistical confidence is reached, and
      releases resources back to the data plane.

   *  Counterfactual & Predictive “What-if” Metrics: Given a proposed
      config change (new AQM, additional slice, 400 GbE upgrade), the
      generator produces the expected delay/loss/jitter distributions
      before any byte is moved, letting operators compare KPI deltas
      without real-world probing.

6.  Use cases of Agentic AI for Operations & Management

   Different use cases for Agentic AI on Operation & Management can be
   identified, as described in the following sections.

6.1.  Intent Based Service Delivery

   Below is the diagram showcasing how network management AI agent takes
   effect on the intent based service delivery process.

        +----------------------------------------------------------+
        |            L3VPN Service Delivery Application            |
        +-------------------------+--------------------------------+
                                  |
                           Intent |LPI
                          interface
                                  |
        +---------+  +------------V--------------------------------+
        |         |  |                                             |
        |Knowledge|  |       Network Management AI Agent           |
        |  Base   <-->                                             |
        |         |  |  +----------------------------------------+ |
        +---------+  |  |     Intent Decomposing&Analysis        | |
                     |  |                                        | |
        +---------+  |  | +----------++----------+ +------------+| |
        |         |  |  | |  Config  || Config   | |   Config   || |
        | Network |  |  | |Generation||Validation| |Distribution|| |
        | Digital <-->  | +----------++----------+ +------------+| |
        | Twin    |  |  +----------------------------------------+ |
        | Tools   |  |                                             |
        +---------+  +---------------------------------------------+

        +----------------------------------------------------------+
        |            Network  Infrastructure                       |
        +----------------------------------------------------------+

       Legend: LPI - Language Programming Interface

                  Figure 2: Intent Based Service Delivery

   Step a.  L3VPN Service Delivery Application at the OSS layer uses
   Language Programming Interface (LPI) to send service intent request
   "Create L3VPN service with 2 VPN sites in London and Paris using L3SM
   Service Model".

   Step b.  The Network Management AI Agent looks up knowledge base to
   understand the intent and identify user's objective "VPN Service
   Creation".

   Step c.  The Network Management AI Agent further interacts with
   Knowledge base for expert experience and looks up thought of chain
   related to "VPN Service Creation".  And then the Knowledge base
   returns results to the Network management AI Agent.

   Step d.  The Network Management AI Agent decomposes user intent and
   break down the tasks into operational workflow including
   configuration generation, configuration validation, configuration
   distribution.  For configuration validation, it will interact with
   Network Digital Twin tools to obtain the validation results.

   Step e.  After L3VPN Service is delivered successfully, the Network
   Management AI Agent will use LPI to return success results.

6.2.  Cross-layer and Cross-domain Multi-Agent communication for
      Complaint handling

   In this scenario, automotive companies centrally collect complaints
   from their customers (drivers) and use the operator’s complaint
   system to feedback issues to the operator.  The operator's BSS
   trouble ticket system generates tickets from these complaints and
   dispatches them to the OSS.  The integrated vehicle networking
   complaint handling agent within the OSS analyzes the trouble tickets
   and performs fault localization.  The ticket will be sent to the
   corresponding vehicle networking trouble ticket agent within OSS
   based on whether fault localization is within or beyond specific
   maintenance domain.

   The vehicle networking trouble ticket agent within the OSS will parse
   the ticket into multiple multi-steps workflow and interact with the
   IP network agent and mobile network agent within its management
   domain to resolve the problem.

                        +-----------------------+
                        |Automobile Manufacturer|
                        |    Complaints         |
                        +-----------------------+
                                   |
                        +----------------------+
                        | BSS Trouble tickets  |
                        |      System          |
                        +----------------------+
                                   |
                 +-------------------------------------------+
                 |                 OSS                       |
                 |                                           |
                 | +---------------+       +----------------+|
                 | |   Complaint   |       |   Complaint    ||
                 | | Handling Agent|-------| Handling Agent ||
                 | |  In Domain A  |       |   In Domain B  ||
                 | +-------+-------+       +----------------+|
                 +---------+---------------------------------+
                        +--+-----------------------+
                   +----+---------+         +------+-------+
                   |   Mobile     |         |    IP        |
                   |   Network    |         |   Network    |
                   |   Agent      |         |   Agent      |
                   +--------------+         +--------------+

                   Figure 3: IoV User Complaints Handling

   o Tasks are triggered by natural language

   *  Complaints usually come from end-users or enterprises

      -  who may not have a deep understanding of network

         o  sometimes are unable to provide accurate descriptions

   o Tasks possess both abstraction and expertise

   *  Abstraction: complaint content is unpredictable and the involved
      domains cannot be anticipated

   *  Expertise: The final closed-loop of the task depends on the
      network

   o Tasks involve cross-layer and cross-domain aspects

   *  Cross-Layer: BSS/OSS -> Network

   *  Cross-domain:

      -  Technical domains (wireless network domain, backhaul network
         domain)

      -  management & maintenance domains (i.e. across provinces and
         cities)

6.3.  AI Agent Driven Network Management

                                  +-----------------+
                                  |       OSS       |
                                  +--------+--------+
                                           |
                                           |LPI
                                           |
                                           |
             Model Invocation    +---------+--------+
      +--------------------------+                  |
      |         Momery Access     Network Management -----------+
      |        +-----------------+     AI Agent     |           |
      |        |            +----|                  |           |
      |        |            |    +-------^---+------+           |
      |        |            |   Response |   |Execution         |
      |   +----V---+   +----+-----+    +-+---V-----+     +------+------+
      |   |        |   |          |    |           |     |             |
      |   | Memory +---|Tools-box <----| Validation+----->  Execution  |
      |   |        |   |          |    |           |     |             |
      |   +--------+   +----^-----+    +-----------+     +-------------+
      |              Model  |     Tool Calling     Action Execution
      |           Invocation|
      |                     |
    +-V---------------------V------------------------------------------+
    |                     Model Repository                             |
    |  (Task Decomposing, Reasoning, Data Analysis, Decision Making..) |
    |              +--------------+      +-----------------+           |
    |              |  LLM Models  |      |Specialized Small|           |
    |              +--------------+      |    AI Models    |           |
    |                                    +-----------------+           |
    +------------------------------------------------------------------+

                Figure 4: AI Agent Driven Network Management

   Traditional network operation and maintenance require extensive human
   oversight and are constrained by predefined policies, limiting real-
   time adaptability.  Network management AI agents at the network level
   enhance network intelligence and automation by integrating large
   network foundation models, specialized small AI models, and feedback
   closed loops mechanisms.  The key functional requirements of the
   Network management AI agent include:

   *  Integrate with large foundation models and specialized small
      models for context-aware decision-making;

   *  Support Intent realizing including task decomposition,reasoning,
      inference&prediction and decision making.

   *  Support autonomous execution of network service lifecycle
      management, including network service delivery, network anomaly
      detection, predictive maintenance and troubleshooting, network re-
      optimization;

   *  Work with upper layer OSS to facilitate cross-layer collaboration,
      enabling seamless communication between network elements;

7.  Security Considerations

   TODO Security

8.  IANA Considerations

   This document has no IANA actions.

9.  References

9.1.  Normative References

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

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

9.2.  Informative References

   [Agentic-AI-Wireless]
              "Advanced Architectures Integrated with Agentic AI for
              Next-Generation Wireless Networks", 2025,
              <https://arxiv.org/html/2502.01089v3>.

   [AIPREF]   "IETF AIPREF WG", 2025,
              <https://datatracker.ietf.org/group/aipref/about/>.

   [ANIMA]    "IETF ANIMA WG", 2025,
              <https://datatracker.ietf.org/group/anima/about/>.

   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7575>.

Acknowledgments

   TBA

Authors' Addresses

   Yong-Geun Hong
   Daejeon University
   62 Daehak-ro, Dong-gu
   Daejeon
   34520
   South Korea
   Email: yonggeun.hong@gmail.com


   Joo-Sang Youn
   DONG-EUI University
   176 Eomgwangno Busan_jin_gu
   Busan
   614-714
   South Korea
   Email: joosang.youn@gmail.com


   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Jiangsu
   210012
   China
   Email: bill.wu@huawei.com


   Benoit Claise
   Everything OPS
   Belgium
   Email: benoit@everything-ops.net


name: draft-zhao-nmrg-ai-agent-for-dtn
rev: 00
title: AI Agent Architecture for DTN Digital Twin Network
time: 2025-10-20T14:09:13Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T14:09:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Data formats/interop", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:03.420405+00:00
abstract:
This document proposes an AI agent architecture for Digital Twin
   Network (DTN) that integrates AI agents with digital twin technology.
   The architecture extends the traditional DTN architecture by
   incorporating autonomous AI agents at each component level, enabling
   more intelligent and adaptive network management capabilities.

full_text:
nmrg                                                        J. Zhao, Ed.
Internet-Draft                                              R. Pang, Ed.
Intended status: Standards Track                           S. Zhang, Ed.
Expires: 23 April 2026                                      China Unicom
                                                         20 October 2025


           AI Agent Architecture for DTN Digital Twin Network
                  draft-zhao-nmrg-ai-agent-for-dtn-00

Abstract

   This document proposes an AI agent architecture for Digital Twin
   Network (DTN) that integrates AI agents with digital twin technology.
   The architecture extends the traditional DTN architecture by
   incorporating autonomous AI agents at each component level, enabling
   more intelligent and adaptive network management capabilities.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 23 April 2026.

Copyright Notice

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

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



Zhao, et al.              Expires 23 April 2026                 [Page 1]

Internet-Draft        AI Agent Architecture for DTN         October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  AI Agent Architecture for Digital Twin Network  . . . . . . .   2
   3.  Architecture Components . . . . . . . . . . . . . . . . . . .   3
     3.1.  Digital Twin Network Management AI Agent  . . . . . . . .   3
     3.2.  Functional Model AI Agent . . . . . . . . . . . . . . . .   4
     3.3.  Basic Model AI Agent  . . . . . . . . . . . . . . . . . .   4
     3.4.  Data Repository AI Agent  . . . . . . . . . . . . . . . .   4
   4.  Agent Interactions  . . . . . . . . . . . . . . . . . . . . .   5
   5.  Intelligent Use Case Realization  . . . . . . . . . . . . . .   5
     5.1.  Simulation Scenario Construction  . . . . . . . . . . . .   5
     5.2.  Simulation Execution  . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Digital twins have emerged as a powerful paradigm for network
   management, providing virtual representations of physical networks
   that enable simulation, analysis, and optimization.  However,
   traditional digital twin architectures often lack the autonomous
   decision-making capabilities needed for modern network environments.
   This document proposes a architecture that combines digital twin
   concepts with intelligent AI agents, creating a more dynamic and
   responsive network management system.

   The architecture is designed to be compatible with existing digital
   twin architectures.  This approach enables distributed decision-
   making, adaptive behavior, and enhanced collaboration between digital
   twin components.

2.  AI Agent Architecture for Digital Twin Network

   Based on the concept of the Network Management Agent (NMA)
   [I-D.zhao-nmop-network-management-agent], we propose an AI Agent
   architecture for Digital Twin Networks (DTN)
   [I-D.irtf-nmrg-network-digital-twin-arch].  This architecture extends
   the traditional digital twin network by integrating AI agents into
   each core component.  While preserving the fundamental structure of
   digital twins, the architecture introduces enhanced autonomous
   capabilities and intelligent decision-making across the network
   management lifecycle.






Zhao, et al.              Expires 23 April 2026                 [Page 2]

Internet-Draft        AI Agent Architecture for DTN         October 2025


   +----------------------------------------------------------------------------------------------------------------------------+
   |                                            Digital Twin Network Management Agent                                           |
   |                                       - Resource Monitor                                                                   |
   |                                       - Lifecycle Management (DTN Instantiation)                                           |
   |                                       - Intent Translation & Policy Derivation                                             |
   |                                       - Virtual-Physical Synchronization Control                                           |
   +----------------------------------------------------------------------------------------------------------------------------+
                                   |                                                                         |
   +-----------------------------------------------------------------+    +-----------------------------------------------------------------+
   |                    Functional Model Agent                       |    |                        Data Repository Agent                    |
   |                                                                 |    |                                                                 |
   |                                                                 |<-->|                    - Real-time Data Collection                  |
   | - Service Model Optimization                                    |    |                                                                 |
   | - Scenario-specific Model Creation                              |    |                    - Historical Data Intelligence Management    |
   +-----------------------------------------------------------------+    |                                                                 |
                                  |                                       |                    - Adaptive Data Services                     |
   +-----------------------------------------------------------------+    |                                                                 |
   |                     Basic Model Agent                           |<-->|                                                                 |
   |                                                                 |    +-----------------------------------------------------------------+
   | - Network Element Models (Config, State, Environment)           |
   | - Topology Models (Connectivity, Link Relationships)            |
   +-----------------------------------------------------------------+

       Figure 1: AI Agent Architecture for Digital Twin Network

   TBD.

3.  Architecture Components

3.1.  Digital Twin Network Management AI Agent

   The Digital Twin Network Management Agent serves as the central
   coordination and management component in the architecture, providing
   the following key functionalities:

   *  Resource Monitoring: Continuously tracks and monitors the status,
      performance metrics, and operational health of all resources
      within the digital twin environment.

   *  Lifecycle Management: Governs the complete lifecycle of Digital
      Twin Network instances, encompassing instantiation, configuration,
      state synchronization, maintenance, and termination.

   *  Session Control: Manages and orchestrates communication sessions
      and interactions among the various AI agents within the
      architecture to ensure coherent operation.





Zhao, et al.              Expires 23 April 2026                 [Page 3]

Internet-Draft        AI Agent Architecture for DTN         October 2025


   *  Intent Translation & Policy Derivation: Translates high-level
      business or operational intents from users into specific,
      executable policies and configuration models for the digital twin
      and its physical counterpart.

   *  Virtual-Physical Synchronization Control: Manages the
      bidirectional data flow and state synchronization between the
      digital twin and the physical network to ensure accurate
      representation and control.

3.2.  Functional Model AI Agent

   The Functional Model Agent is responsible for advanced service
   modeling and optimization capabilities, it can autonomously invoke
   the required functional models based on validation policies, while
   continuously optimizing models through the analysis of historical
   data.  Additionally, it develops specialized models tailored to
   specific operational scenarios, use cases, and network conditions.

   *  Service Model Optimization: Continuously refines and optimizes
      service models through performance analysis and adaptive learning
      algorithms.

   *  Scenario-specific Model Creation.

   TBD.

3.3.  Basic Model AI Agent

   The Basic Model Agent maintains fundamental network element and
   topology representations, capable of updating itself in real-time
   based on changes in the physical network to ensure the accuracy of
   validation.

3.4.  Data Repository AI Agent

   The Data Repository AI Agent serves as the intelligent data
   governance and provisioning component, enabling data-driven
   operations across the digital twin ecosystem.  It autonomously
   manages data lifecycle with the following AI-enhanced capabilities:

   *  Real-time Data Collection: Implementing multi-protocol ingestion
      for streaming network telemetry and performance metrics, while
      autonomously detecting and flagging data anomalies or
      inconsistencies.






Zhao, et al.              Expires 23 April 2026                 [Page 4]

Internet-Draft        AI Agent Architecture for DTN         October 2025


   *  Historical Data Intelligence Management: Building structured data
      and integrates intelligent analytics capabilities to support trend
      analysis and pattern mining, providing data foundation for model
      training and proactive optimization.

   *  Adaptive Data Services: Providing context-aware data retrieval
      with intelligent caching, pre-processing, and conflict resolution,
      dynamically prioritizing datasets for critical tasks such as
      simulation or root cause analysis.

4.  Agent Interactions

   The architecture employs bidirectional Agent-to-Agent (A2A)
   communication to ensure seamless operation: the Functional and Basic
   Model Agents interact with the Data Repository Agent for data access
   and synchronization, while the Digital Twin Network Management Agent
   centrally orchestrates these interactions and manages inter-agent
   dependencies to maintain a coherent workflow across the entire
   system.

5.  Intelligent Use Case Realization

5.1.  Simulation Scenario Construction

   S1: The Digital Twin Network Management Agent receives user
   instructions, performs intent translation, and generates simulation
   strategies.

   S2: The Functional Model Agent constructs functional models or
   coordinates existing models based on the strategies.

   S3: The Basic Model Agent provides real-time configuration models and
   topological relationships for the migration scenario.

   S4: The Data Repository Agent injects real-time traffic information.

   All agents collaborate to create a simulation sandbox consistent with
   the actual physical network, within which the Functional Model Agent
   simulates the complete migration process.

5.2.  Simulation Execution

   S1: The Functional Model Agent continuously evaluates network
   performance indicators.

   S2: If KPIs fail to meet standards or risks are detected, a rollback
   mechanism is immediately triggered.  The agent coordinates with the
   Basic Model Agent to develop and execute a rollback plan.



Zhao, et al.              Expires 23 April 2026                 [Page 5]

Internet-Draft        AI Agent Architecture for DTN         October 2025


   S3: After analyzing and optimizing the solution, the simulation
   restarts and cycles iteratively until a compliant migration plan is
   generated.

   S4: Upon simulation completion, the Functional Model Agent leverages
   historical data to optimize existing service models.

6.  Security Considerations

   TBD.

7.  IANA Considerations

   TBD.

8.  Informative References

   [I-D.irtf-nmrg-network-digital-twin-arch]
              Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu,
              Q., Boucadair, M., and C. Jacquenet, "Network Digital
              Twin: Concepts and Reference Architecture", Work in
              Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
              twin-arch-11, 6 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
              network-digital-twin-arch-11>.

   [I-D.zhao-nmop-network-management-agent]
              XingZhao, Wang, M., Wu, B., Ceccarelli, D., Zheng, H., and
              J. Zhou, "AI based Network Management Agent(NMA): Concepts
              and Architecture", Work in Progress, Internet-Draft,
              draft-zhao-nmop-network-management-agent-03, 17 October
              2025, <https://datatracker.ietf.org/doc/html/draft-zhao-
              nmop-network-management-agent-03>.

Authors' Addresses

   Jing Zhao (editor)
   China Unicom
   Beijing
   China
   Email: zhaoj501@chinaunicom.cn


   Ran Pang (editor)
   China Unicom
   Beijing
   China
   Email: pangran@chinaunicom.cn



Zhao, et al.              Expires 23 April 2026                 [Page 6]

Internet-Draft        AI Agent Architecture for DTN         October 2025


   Shuai Zhang (editor)
   China Unicom
   Beijing
   China
   Email: zhangs366@chinaunicom.cn














































Zhao, et al.              Expires 23 April 2026                 [Page 7]


name: draft-zyyhl-agent-networks-framework
rev: 01
title: Framework for AI Agent Networks
time: 2025-10-20T16:12:33Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T16:12:33Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:03.420407+00:00
abstract:
This document defines the framework of AI agent networks based on
   Agent Network Protocol (ANP) protocol.  [ANP] It provides the basic
   functions that needs to support AI agent communication in the AI
   agent networks within the trust domain.

full_text:
Network Working Group                                            Y. Zhou
Internet-Draft                                 ANP Open Source Community
Intended status: Informational                                    K. Yao
Expires: 23 April 2026                                      China Mobile
                                                                   M. Yu
                                                           China Telecom
                                                                  M. Han
                                                            China Unicom
                                                                   C. Li
                                                                  Huawei
                                                         20 October 2025


                    Framework for AI Agent Networks
                draft-zyyhl-agent-networks-framework-01

Abstract

   This document defines the framework of AI agent networks based on
   Agent Network Protocol (ANP) protocol.  [ANP] It provides the basic
   functions that needs to support AI agent communication in the AI
   agent networks within the trust domain.

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 23 April 2026.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.



Zhou, et al.              Expires 23 April 2026                 [Page 1]

Internet-Draft          Agent Networks Framework            October 2025


   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
     1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview of the operation . . . . . . . . . . . . . . . . . .   4
     3.1.  Roles . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Digital Identifier  . . . . . . . . . . . . . . . . . . . . .   6
   5.  Agent Description . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Agent Description Document Format . . . . . . . . . . . .   7
       5.1.1.  Natural Language Format . . . . . . . . . . . . . . .   7
       5.1.2.  Structured Format . . . . . . . . . . . . . . . . . .   8
     5.2.  Agent Information Interaction Mechanism . . . . . . . . .   8
       5.2.1.  Information . . . . . . . . . . . . . . . . . . . . .   8
       5.2.2.  Interface . . . . . . . . . . . . . . . . . . . . . .   8
     5.3.  Security Mechanism  . . . . . . . . . . . . . . . . . . .   9
     5.4.  Integrity Verification  . . . . . . . . . . . . . . . . .   9
   6.  Agent Registration  . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Self-Declaration Mode . . . . . . . . . . . . . . . . . .   9
     6.2.  Centralized Registration Mode . . . . . . . . . . . . . .  10
   7.  Agent Discovery . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Proactive Discovery Mode (Corresponding to Self-Declaration
           Mode) . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.2.  Centralized Query Mode (Corresponding to Centralized
           Registration Mode)  . . . . . . . . . . . . . . . . . . .  11
   8.  Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.2.  Task States . . . . . . . . . . . . . . . . . . . . . . .  13
     8.3.  Task coordination . . . . . . . . . . . . . . . . . . . .  13
   9.  Message mode  . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Point-to-Point Communication  . . . . . . . . . . . . . .  14
     9.2.  Group Communication . . . . . . . . . . . . . . . . . . .  15
     9.3.  PUB/SUB Communication . . . . . . . . . . . . . . . . . .  15
   10. Multimodality . . . . . . . . . . . . . . . . . . . . . . . .  15
   11. Session management  . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Session Establishment and Control  . . . . . . . . . . .  16
     11.2.  Differentiated QoS Guarantees  . . . . . . . . . . . . .  16
   12. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     12.1.  Agent ID-based Route look-up . . . . . . . . . . . . . .  16



Zhou, et al.              Expires 23 April 2026                 [Page 2]

Internet-Draft          Agent Networks Framework            October 2025


     12.2.  Semantic-based Route resolution  . . . . . . . . . . . .  17
   13. Protocol Stack Considerations . . . . . . . . . . . . . . . .  17
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  18
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   16. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  19
   17. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     18.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     18.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

1.1.  Overview

   With the development of AI agent technology, its application
   scenarios have been continuously expanding.  From initial simple task
   execution to complex collaborative tasks among multiple agents,
   agents have demonstrated great potential in various fields.  This
   multi-agent collaboration model can fully leverage the strengths of
   individual agents, improving the quality and efficiency of task
   execution.  However, as the demand for multi-agent collaboration
   grows, defining standardized communication protocols among agents to
   achieve wide-area interconnection, cross-domain interoperability, and
   secure collaboration has become an urgent issue to address.

   To meet the communication needs of AI agents and promote the
   widespread services of multi-agent collaboration
   [I-D.stephan-ai-agent-6g], it is imperative to define standardized
   agent communication protocols that support interconnection,
   interoperability, and secure scalability between agents in trust
   domain.

   In this draft we propose to use Agent Network Protocol (ANP) as a
   baseline for further description.

1.2.  Scope

   From the perspective of network service domain division, future
   agents can be simply categorized into 3 types based on their
   deployment locations: terminal-side agents, network-side agents, and
   agents outside the network.  This draft mainly focuses on the
   communication between agents directly managed within the operator's
   network, i.e. the communication between the first two types of
   agents:

   *  Communication between different terminal-side agents registered in
      the same network service domain.



Zhou, et al.              Expires 23 April 2026                 [Page 3]

Internet-Draft          Agent Networks Framework            October 2025


   *  Communication between terminal-side agents and network-side agents
      registered in the same network service domain.

   *  Communication between network-side agents registered in the same
      network service domain.

   Furthermore, the communication between agents registered in different
   network domains is not within the scope of this draft.

1.3.  Requirements Language

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

2.  Terms and Definitions

   Task: Task is actions required to achieve a specific goal.  These
   actions can be physical or cognitive.

   Task chain: A Task chain defines an ordered set of tasks and ordering
   constraints that is to be applied to, e.g., packets, frames, or
   flows.  The implied order may not be a linear progression as the
   architecture allows for task chain of more than one branch, and also
   allows for cases where there is flexibility in the order in which
   tasks need to be applied.

   Coordinator Agent: An agent that receives tasks and decomposes or
   distributes tasks to other agents.

   Execution Agent: An agent responsible for executing tasks distributed
   by the Coordinator Agent.

3.  Overview of the operation

3.1.  Roles

   The Agent communication network defines three roles:

   *  AI Agent: An automated intelligent entity that achieves a specific
      goal (autonomously or not) on behalf of another entity, by e.g.
      interacting with its environment, acquiring contextual
      information, reasoning, self-learning, decision-making, and
      executing tasks (independently or in collaboration with other AI
      Agents).




Zhou, et al.              Expires 23 April 2026                 [Page 4]

Internet-Draft          Agent Networks Framework            October 2025


   *  Agent Registration Server: The server enables Agents to register
      their capabilities, and discover each other’s capabilities based
      on intent, task or other information.

   *  Agent Communication Server The server enables Agents to
      communicate and collaborate with each other, which provides
      session management and routing function.

3.2.  Protocol Flow

+------+                           +-------------+                            +------+
|      |                           |             |<-(A)-Capability Register---|      |
|      |                           |             |                            |      |
|      |                           |    Agent    |-(B)-------Response-------->|      |
|      |-(C)-Capability Discover-->| Registration|                            |      |
|      |                           |    Server   |                            |      |
|      |<-(D)----Matched Agents----|             |                            |      |
|  AI  |                           |             |                            |  AI  |
| Agent|                           +-------------+                            | Agent|
|   A  |                                                                      |   B  |
|      |                           +-------------+                            |      |
|      |-(E)Communication Request->|             |                            |      |
|      |                           |    Agent    |-(F)Communication Request-->|      |
|      |                           |Communication|                            |      |
|      |                           |   Server    |<-(G)Communication Response-|      |
|      |<-(H)Communication Response|             |                            |      |
|      |                           +-------------+                            |      |
|      |                                                                      |      |
|      |-----------------------(E')Communication Request--------------------->|      |
|      |                                                                      |      |
|      |>----------------------(F')Communication Response---------------------|      |
+------+                                                                      +------+

                   Figure 1: Abstract Protocol Flow

   The abstract flow illustrated in Figure 1 describes the interaction
   between the three roles and includes the following steps:

   (A) The AI Agent B requests to register its capabilities and related
   attributes to Agent Registration Server.

   (B) The Agent Registration Server authenticates the AI Agent B’s
   capabilities and then stores them, e.g., in its local database.

   (C) AI Agent A initiates a capability discover request to the Agent
   Registration Server, the request includes the intent, task or other
   information.




Zhou, et al.              Expires 23 April 2026                 [Page 5]

Internet-Draft          Agent Networks Framework            October 2025


   (D) The Agent Registration Server matches the intent or task with the
   capabilities stored in its local database, and responses with matched
   AI Agents list to the AI Agent A.

   Option1:

   (E) The AI Agent A selects AI Agent B from the list and sends a
   communication request to AI Agent B via Agent Communication Server.

   (F) The Agent Communication Server establishes the session and routes
   the message to AI Agent B.

   (G) The AI Agent B receives the communication request and sends a
   response to the Agent Communication Server.

   (H) The Agent Communication Server transfers the response to the AI
   Agent A.

   Option2:

   (E') The AI Agent A selects AI Agent B from the list and sends a
   communication request to AI Agent B directly.

   (F') The AI Agent B receives the communication request and sends a
   response to the AI Agent A.

4.  Digital Identifier

   The digital identity mechanism is used for the registration,
   discovery and communication flows.

   *  Registration: digital identity contains a global unique identifier
      of AI agent as a basis for authentication and addressing during
      communication flow.  Several agent-related attributes
      (capabilities/skills/services) are contained in the digital
      identity and registered with the identifier at the same time.  The
      related credentials in the digital identity can be used for the
      verification.

   *  Discovery: the registered AI agent can then be discovered by other
      agents based on either identifier or capabilities.  The agent can
      be discovered across different domains.

   *  Communication: one AI agent can communicate with the other AI
      agent, by sending an initial message with the identifier obtained
      from the discovered digital identity.  The network can use this
      identifier for addressing and routing the message to the target AI
      agent.



Zhou, et al.              Expires 23 April 2026                 [Page 6]

Internet-Draft          Agent Networks Framework            October 2025


   *  Authentication: during the communication establishment, both AI
      agents can use the credentials for the identifier for
      authentication.  Attributes can be negotiated after the
      authentication.

   *  Authorization: compared to human communication, AI agent
      communication needs to be explicitly authorized at all time.  The
      attribute-based authorization mechanism can support both direct
      agent-agent authorization and delegated authorization, even for
      the user authorization.

   In order to fulfill the requirements mentioned above, it is suggested
   to introduce the W3C Decentralized Identifier (DID)[DID] and
   Verifiable Credential (VC) [VC_Card]standards as the basic digital
   identity components.

   *  DID: The core DID specification does not require implementers to
      use specific computational infrastructure to build decentralized
      identifiers, allowing us to fully leverage existing mature
      technologies and well-established network infrastructure to build
      DIDs.

   *  VC: The VC can be used as container of attributes of an AI agent.
      The attributes of an AI agent may come from different sources
      which can be verified by the VC.  This will help increase the
      interoperability of cross-domain communications.

5.  Agent Description

   Agent Description (AD) exists in document form.  The AD document
   serves as the entry point to access an agent, functioning similarly
   to a website homepage.  Other agents can obtain information such as
   the agent's name, affiliated entity, functionalities, and interaction
   APIs or protocols from this AD document.  With this information, data
   communication and collaboration between agents can be achieved.

5.1.  Agent Description Document Format

   The Agent Description (AD) document serves as the external entry
   point for an agent and can be provided in either of the following
   formats:

5.1.1.  Natural Language Format

   Leveraging advancements in AI capabilities, the AD document can be
   entirely described using natural language.





Zhou, et al.              Expires 23 April 2026                 [Page 7]

Internet-Draft          Agent Networks Framework            October 2025


5.1.2.  Structured Format

   Since different agents may utilize varying models with distinct
   capabilities, a structured approach is recommended for ensuring
   consistent and accurate interpretation of the same data across
   diverse models.  Structured Format supports multiple document types:

   *  JSON

   *  JSON-LD

   *  Other structured document formats

5.2.  Agent Information Interaction Mechanism

   Agent description documents include the following two types of
   resources:

5.2.1.  Information

   Agents may provide the following types of data:

   *  Textual files (e.g.: .txt, .csv, .json)

   *  Image files (e.g.: .jpg, .png, .svg)

   *  Video files (e.g.: .mp4, .mov, .webm)

   *  Audio files (e.g.: .mp3, .wav, .aac)

   *  Other files

5.2.2.  Interface

   Agent interfaces are categorized into two types:

   *  Natural Language Interface: Enables agents to deliver personalized
      services through natural language interaction, supports human-like
      communication and adaptive responses.

   *  Structured Interface: Facilitates efficient and standardized
      service delivery via predefined protocols, ensures
      interoperability and machine-to-machine automation.








Zhou, et al.              Expires 23 April 2026                 [Page 8]

Internet-Draft          Agent Networks Framework            October 2025


5.3.  Security Mechanism

   Security configuration in Agent Description (AD) documents is
   mandatory.  The security definition must be activated through the
   security member at the agent level.  This configuration constitutes
   the required security mechanism for agent interactions.

   *  Global Scope: When security is declared at the root level of an AD
      document, all resources within the document must enforce this
      security mechanism for access.

   *  Resource-Specific Scope: If security is defined within an
      individual resource, access to that resource is granted only when
      the specified security conditions are met.

   *  Precedence Rule: In cases where resource-level security conflicts
      with root-level security, the resource-level definition takes
      precedence.

5.4.  Integrity Verification

   To prevent malicious tampering, impersonation, or reuse of Agent
   Description (AD) documents, a verification mechanism Proof is
   incorporated into the AD document structure.  The definition of Proof
   shall comply with the specification [VC_Card].

6.  Agent Registration

   Agent Registration Includes the Following Two Modes:

6.1.  Self-Declaration Mode

   In this mode, intelligent agents interconnect externally provided
   resources (including information, interfaces, etc.) using Linked-Data
   technologies, forming a networked ecosystem through agent description
   documents.  Other agents can selectively retrieve appropriate
   resources via metadata described in these agent profile documents.
   Advantages of the Self-Declaration Mode:

   *  Compatibility with Existing Internet Architecture: Facilitates
      search engine indexing of agent-publicized information, enabling
      the creation of an efficient agent data network.

   *  Enhanced Privacy Protection: Pulling remote data to local systems
      for contextual processing mitigates user privacy leakage risks
      inherent in task-delegation models.





Zhou, et al.              Expires 23 April 2026                 [Page 9]

Internet-Draft          Agent Networks Framework            October 2025


   *  Inherent Hierarchical Structure: Supports scalable interactions
      among a large number of agents.

6.2.  Centralized Registration Mode

   In this mode, the AI Agents register their attributes to a
   centralized Agent Registration Server.  The parameters that an Agent
   needs to register in a trust domain (step A in Figure 1) may include:

   *  Name: The name of the Agent, which may not be unique and typically
      represented as a string.

   *  Digital Identifier: The global unique ID of the Agent configured
      by the network provider.

   *  Description: provide a more concise summary of the Agent’s
      relevant details based on natural language.

   *  Address: The access address of the Agent, which might be an URL,
      FQDN, etc.

   *  Version: The current version of the Agent.

   *  Capabilities: The capabilities supported by the Agent, including
      the communication capabilities, interaction modes and multimodal
      capabilities, etc.  The communication capabilities refer to the
      communication protocols supported by the Agent, such as http/2,
      http/3, A2A, ANP, MCP, etc.  The interaction modes may include
      request-response and subscription-notification and others.  The
      multimodal capabilities refer to the data modalities that the
      agent can process, such as text, images, video, real-time audio,
      etc.

   *  Services: The services that the agent can provide.  E.g., AI
      service, sensing service, computing service.

   *  Skills: A list of detailed description of the skills supported by
      the Agent.  The content of each skill includes the name, ID,
      corresponding services, brief abstract, required input, etc.

   *  Interfaces: The APIs interfaces that the agent can provide.

   *  Security related information: For example, the licenses,
      authentication credentials, keys of the Agent.







Zhou, et al.              Expires 23 April 2026                [Page 10]

Internet-Draft          Agent Networks Framework            October 2025


7.  Agent Discovery

   Corresponding to Agent Registration, Agent Discovery Includes the
   Following Two Modes:

7.1.  Proactive Discovery Mode (Corresponding to Self-Declaration Mode)

   In this operational mode, AI agents dynamically acquire Agent
   Description (AD) documents from peer agents through standardized
   discovery protocols (e.g., search engine).  These AD documents serve
   as structured entry points for targeted crawling operations within
   Linked Data networks.  The crawling mechanism implements selective
   resource retrieval, encompassing both semantic information and
   service interfaces, while adhering to ethical crawling policies.

7.2.  Centralized Query Mode (Corresponding to Centralized Registration
      Mode)

   In the mode, the discovery of AI agents depends on the Agent
   Registration Server, and the discovery process consists of two
   phases: "query matching" and "result feedback":

   1) Query Matching Phase:

   The initiating AI Agent A send a Capability Discovery request to the
   Registration Server, and the server screens and matches the target
   agents based on the capability database.  The request parameters
   should be structured (to avoid ambiguous descriptions).  Examples are
   as follows:

   - Requirement description: "Medical image analysis"

   - Location range: "Within 1 kilometer of base station BS-001"

   - Real-time requirement: "Latency ≤ 100ms"

   - Security level: "Medical qualification VC is required"

   The Agent Registration Server matches the requirement with local
   registered Agent description.  After the matching is completed, a
   "target agent list" is generated, which includes Digital Identifier,
   Address, and Capabilities, etc.

   2) Result Feedback Phase:

   The Agent Registration Server feeds back the matched results to the
   initiator AI agent, and the initiator selects a Agent based on the
   results and starts the session establishment with that Agent.



Zhou, et al.              Expires 23 April 2026                [Page 11]

Internet-Draft          Agent Networks Framework            October 2025


8.  Tasks

8.1.  Overview

   The core function of a task is to enable the AI agents involved in
   the communication to agree on "what to do", thereby avoiding
   collaboration failures due to misunderstandings.

   Tasks can be used in capability discovery and communication
   procedures:

   *  Capability Discovery: Obtaining AI agents with matching
      capabilities based on the task descriptions.

   *  Communication: When a Coordinator Agent initiates a communication
      request to an Execution Agent, the request message may carry a
      task description.  In addition, other auxiliary information such
      as images, videos, files, can also be sent along with the task
      description to help accomplish the task.

   An example as shown in Figure 2, a task can be executed by an AI
   agent (e.g., task0 sent to Agent B).  When a complex task is received
   by an AI agent, this task can be broken down into a series of
   subtasks (e.g., task0 broken down to sub-task1 and sub-task2) with a
   clear execution sequence, known as a task chain, and executed by a
   group of AI agents (e.g., sub-task1 sent to Agent B, sub-task2 sent
   to Agent C).  Task chain allows multiple AI agents to execute
   different tasks in a specific sequence based on policy, and enable
   multiple AI agents collaboratively to accomplish a complex task.  The
   Agent communication protocol should support to encapsulate the task
   chain information, e.g., independent with the underlying network
   transport (e.g., IP, MPLS).

   +---------+                                  +---------+
   |         |------------send task0----------->|         |
   | Agent A |                                  | Agent B |
   |         |<-task status/result notification-|         |
   +---------+                                  +---------+

   +---------+                                  +---------+
   |         |-----------send sub-task1-------->|  Agent  |
   |         |<-task status/result notification-|    B    |
   |         |                                  +---------+
   | Agent A |                                  +---------+
   |         |-----------send sub-task2-------->|  Agent  |
   |         |<-task status/result notification-|    C    |
   +---------+                                  +---------+




Zhou, et al.              Expires 23 April 2026                [Page 12]

Internet-Draft          Agent Networks Framework            October 2025


                   Figure 2: Task and Sub-task Assignment

   Tasks can be sent along with the message that establish communication
   session between AI agents, or separately using the established
   session between AI agents.  In the communication session between AI
   agents, one or more tasks can be included, which may be independent
   of each other or associated through context.

   A task is identified by a global unique task ID.  The task ID is
   generated by the agent that creates or assigns the task and are sent
   along with the task to the agent responsible for executing it.

8.2.  Task States

   Based on the length of time to complete the tasks, the task can be
   categorized into:

   *  Short-term tasks: These tasks can be quickly executed and
      completed, often used for simple tasks such as query the weather.

   *  Long-term tasks: These tasks require a longer period of time or
      involve multi-round interaction or extended waiting periods, such
      as writing an article.  During the execution of long-term tasks,
      AI agents can synchronize task states or intermediate results
      among them as needed.

   The task states are maintained by the execution AI agent, and the
   task status can be synchronized among Agents as needed.

8.3.  Task coordination

   The AI Agent communication protocol design MUST consider support for
   Agent Communication Server to facilitate task message forwarding.
   Agent Communication Server SHOULD prioritize message scheduling and
   forwarding based on task requirements to ensure efficient agent
   collaboration and meet transmission QoS objectives.

   This prioritization scheme ensures that critical messages receive
   preferential treatment during congestion or resource contention
   scenarios.

   When delegating tasks to Execution Agents, the Coordinator Agent may
   include task-relevant contextual about the contact information of the
   end user, the task itself, the historical preference information
   known by the Coordinator Agent, and other necessary conversation
   data, to facilitate the task execution.  For example, in trip
   planning case, this may encompass historically booked flight/hotel
   preferences or dynamically perceived context like recent user dialog.



Zhou, et al.              Expires 23 April 2026                [Page 13]

Internet-Draft          Agent Networks Framework            October 2025


   The AI agent protocol should consequently support context sharing
   mechanisms through standardized definitions of context types, length
   constraints, and encoding formats to enhance the effectiveness of
   task execution.

9.  Message mode

   This section defines the message mode of AI agents from two
   dimensions.  One dimension is the number of communication
   participants, which is divided into Point-to-Point Communication (2
   AI agents) and Group Communication (3 or more AI agents), and the
   section is divided into two sub-sections based on this dimension.
   The other dimension is whether the communication between AI agents
   requires the participation of an intermediate node, which divides
   communication into Direct Communication and Indirect Communication,
   and this dimension is further elaborated in the classification within
   each sub-section.

9.1.  Point-to-Point Communication

   Direct Communication: AI agents directly send and receive protocol
   messages without the need for intermediate nodes for processing, or
   AI agents are unaware of these intermediate nodes.  Indirect
   Communication: Communication between AI agents requires processing/
   relaying by the Agent Communication server, and the AI agent must be
   aware of and interact with the Agent Communication server.  The
   function of the Agent Communication server includes but is not
   limited to:

   *  AI agent access control (allowing or blocking an AI agent's
      messages based on its identity or permissions).

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

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

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

   *  handle authentication and message relaying between the two
      communicating parties.








Zhou, et al.              Expires 23 April 2026                [Page 14]

Internet-Draft          Agent Networks Framework            October 2025


9.2.  Group Communication

   To better accomplish communication collaboration, agents can
   dynamically form groups.  Information sent by an agent within a group
   can be received simultaneously by other agents in the same group.

9.3.  PUB/SUB Communication

   In this mode, the AI agent sending the information does not know
   which AI agents need to receive it.  It first Publishes the
   information to Agent Communication Server, and this Agent
   Communication Server then distributes the information to the
   subscribing Agents based on their Subscribe status.  Pub/Sub
   communication is a common and efficient method of information
   distribution, especially suitable for large-scale group communication
   scenarios.

10.  Multimodality

   Interactions between AI agents must support multimodality, e.g.,
   text, file, document, image, structured data, real-time audio stream,
   video streaming.  The data size of different multimodality as well as
   the transmission modes (e.g., real-time steaming, or push
   notification) may be different.

   Given these traffic characteristics above, the Agent communication
   protocol should support multimodal data transmission which mentioned
   above.  At the same time, the Agent communication protocol and
   possible protocols of other layers should be designed with the
   principle that the multimodal data can be distinguished and aware,
   based on which they can be handled with differentiated policies for
   better performance assurance and resource efficiency.  For example,
   different multimodal data can be transmitted with different transport
   streams of different quality guarantee.  Or, they can be transmitted
   within a same transport stream but with different policies (e.g.,
   transmission priority).

11.  Session management

   After discovering the peer Agent (e.g., Agent B), the local Agent
   (e.g., Agent A) needs to establish a session with it to communicate.










Zhou, et al.              Expires 23 April 2026                [Page 15]

Internet-Draft          Agent Networks Framework            October 2025


11.1.  Session Establishment and Control

   Before communicating with Agent B, Agent A should first establish a
   secure connection with the Agent Communication Server.  Prior to
   this, Agent A must undergo authentication by the Agent Communication
   Server.  Similarly, Agent B also needs to be authenticated by the
   Agent Communication Server to establish a secure connection.

   Therefore, the Agent Communication Server needs to support the states
   maintenance of the registered Agents, such as the states of Agent A
   and Agent B.

   In order to communicate with Agent B, Agent A initiates a session
   establishment request to the Agent Communication Server.  After
   verifying its permissions, the Agent Communication Server proceeds to
   establish the session, for example, by assigning a globally unique
   Session ID to the new session.  This ID will be used throughout the
   entire session lifecycle to correlate all activities and data.
   Correspondingly, the Agent Communication Server needs to maintain a
   session table, which includes information about all Agents involved
   in the session, especially information about the session initiator.

   Alternately, after authentication and authorization, the Agent A can
   also initial a connection directly to the Agent B.  In this
   situation, the control plane and data plane can be separated.

11.2.  Differentiated QoS Guarantees

   During the session establishment, Agent A can provide the relevant
   QoS requirements for the session.  Consequently, the Agent
   Communication Server can prioritize the processing and forwarding of
   messages according to these requirements to ensure the session's QoS.

12.  Routing

12.1.  Agent ID-based Route look-up

   The scenario described in this section is when an Agent sends a
   message to another Agent (or a group of Agents), and the sending
   Agent knows the recipient Agent's ID or Group ID.  According to the
   two major types of communication modes in Section 6, the situations
   can be classified as follows:

*  Point-to-Point Communication (P2P):

  - In the direct communication mode, the Agent looks up the corresponding IP address using the recipient's ID, thus allowing the message to be sent to the recipient.

  - In the indirect communication mode, the Agent can delegate the ID lookup task to the Agent Communication Server, which is then responsible for sending the message to the recipient Agent based on the ID.



Zhou, et al.              Expires 23 April 2026                [Page 16]

Internet-Draft          Agent Networks Framework            October 2025


*  Group Communication:

  - The Agent delegates the Group ID lookup task to the Agent Communication Server, which is then responsible for sending the message to the recipient Agent in the same group.

12.2.  Semantic-based Route resolution

   The scenario described in this section is when an Agent wants to
   communicate with other Agents that possess a certain capability or
   attribute, but does not yet know their IDs.  In this case, a semantic
   search system is needed to search for the Agent IDs that meet the
   criteria based on the capabilities or attributes described by the
   Agent.  The message is then routed according to the retrieved ID.

13.  Protocol Stack Considerations

   The protocol stack of an AI agent is divided into three functional
   layers: the AI Agent communication protocol layer, the application
   layer, and the transmission layer.  AI Agent applications communicate
   with each other through the interfaces provided by the AI Agent
   communication protocol layer.  The AI Agent communication protocol
   operates above the application layer and has requirements for both
   the application layer and transport layer protocols.

   +--------------------------------------------------------+
   |                  AI Agent Application                  |
   +--------------------------------------------------------+

   +--------------------------------------------------------+
   |  AI Agent Comm Protocol Layer (e.g.,JSON-RPC, JSON-LD) |
   +--------------------------------------------------------+

   +--------------------------------------------------------+
   |            Application Layer (e.g.,HTTP, SIP)          |
   +--------------------------------------------------------+

   +--------------------------------------------------------+
   |         Transmission Layer (e.g.,UDP, TCP, QUIC)       |
   +--------------------------------------------------------+

                  Figure 3: AI Agent protocol stack Layer

   AI Agent Communication Layer: This layer provides the basic
   communication function between Agents, including all the functions
   mentioned above in this draft.

   Application layer: This layer SHALL support the following functions:





Zhou, et al.              Expires 23 April 2026                [Page 17]

Internet-Draft          Agent Networks Framework            October 2025


   *  Support bidirectional full-duplex communication between AI agents,
      meaning that an AI agent can both initiate and receive
      communication requests.  In the same communication session, an
      Agent can send multimodal data as well as receive multimodal data.

   *  Be decoupled from the presentation layer.  For example, after the
      presentation layer chooses to use JSON-RPC protocol, JSON-RPC
      messages MUST support being carried over different application
      layer protocols such as HTTP and WebTransport, etc.

   *  Support a flexible routing mechanism at the application layer,
      including direct routing based on URL querying DNS and segment-
      based routing according to DID.

   *  Support a flexible extension mechanism for protocols to better
      meet the increasingly diverse functional requirements of Agent
      communication.

   Transmission Layer: This layer SHALL provide the following functions:

   *  In mobile scenarios, transport layer should dynamically optimize
      and update QoS parameters according to revised QoS rules.

   *  To achieve multimodal data stream multiplexing, multi-path
      transmission capabilities (i.e., MPTCP, MPQUIC) should be adopted
      to support flexible transmission management of multi-source data
      from agents.

   *  the transport layer should either transmit unfinished data packets
      to the new link or switch data to a backup link, thereby enabling
      mobility management for agent communication.

14.  Security Considerations

   Security of AI agent communication is not detailed in this draft.
   Considering its independence, we suggest that it could be discussed
   separately through other proposals from the following aspects:

   *  Identity: AI agents vary from embodied robots to virtualized
      assistant, which introduces different identity and credential
      storage approach.  The protocol should consider a unified and
      compatibility mechanism to meet these requirements, e.g., SIM-
      based robots, certificate-based AI assistant.

   *  Authentication: AI agents can reuse the authentication mechanism
      provided by the single trusted domain e.g., primary authentication
      between the agent and the core network.  So that the agents may
      simplify the direct authentication process.



Zhou, et al.              Expires 23 April 2026                [Page 18]

Internet-Draft          Agent Networks Framework            October 2025


   *  Authorization: Current practices of agent communication mostly
      rely on existing OAuth 2.0 related mechanism.  It should be
      considered that there will be different authorization mechanisms
      for direct authorization, delegated authorization and user
      authorization.

   *  Cross-domain Security: This draft focused on the communication
      within one trust domain.  However, the cross-domain trust and
      security of AI agents should also be considered in next steps

   *  Discovery Privacy: The publication of an AI agent should get
      owner’s approval.  Not all agent cards/descriptions/identities
      should be published considering the possible sensitive information
      associated with its owner who may be a natural person.

   *  Task Privacy: Agents involved in task execution should follow the
      principle of task description minimization, meaning that each
      agent should only receive the minimum and necessary information
      required to complete its task, in order to prevent unauthorized
      access to sensitive information.  In addition, context sharing may
      impact user privacy, so it is important to consider limitations on
      the scope of context sharing, especially for sensitive information
      such as the user's name, age, and address.

15.  IANA Considerations

   TBD.

16.  Conclusions

   This framework focuses on AI agent communication within a single
   trust domain, introducing the communication framework, basic
   processes, and key mechanisms.  Considering that multiple trust
   domains may exist in practical deployments, the mechanisms such as
   digital identity format, capability registration and discovery, and
   routing involved in cross-domain scenarios may differ from those
   within a single trust domain.  Therefore, further research on cross-
   domain agent communication is needed in the future.

17.  Acknowledgements

   TBD

18.  References

18.1.  Normative References





Zhou, et al.              Expires 23 April 2026                [Page 19]

Internet-Draft          Agent Networks Framework            October 2025


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

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

18.2.  Informative References

   [ANP]      "Agent Network Protocol 1.0", 15 April 2024,
              <https://github.com/agent-network-protocol/
              AgentNetworkProtocol>.

   [I-D.stephan-ai-agent-6g]
              Stephan, E., Schott, R., Lopez, D., Duan, X., and L.
              Morand, "AI Agent protocols for 6G systems", Work in
              Progress, Internet-Draft, draft-stephan-ai-agent-6g-00, 7
              July 2025, <https://datatracker.ietf.org/doc/html/draft-
              stephan-ai-agent-6g-00>.

   [VC_Card]  "Verifiable Credential Data Integrity 1.0", 15 May 2025,
              <https://www.w3.org/TR/vc-data-integrity/#defn-domain>.

   [DID]      "Decentralized Identifiers v1.1", 18 September 2025,
              <https://www.w3.org/TR/did-1.1/>.

Authors' Addresses

   Ye Zhou
   ANP Open Source Community
   No. 188, Zongguantang Road, Gusu District
   Suzhou, Jiangsu Province
   China
   Email: zynetzy1@aliyun.com


   Kehan Yao
   China Mobile
   Email: yaokehan@chinamobile.com


   Menghan Yu
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   China



Zhou, et al.              Expires 23 April 2026                [Page 20]

Internet-Draft          Agent Networks Framework            October 2025


   Email: yumh1@chinatelecom.cn


   Mengyao Han
   China Unicom
   No.9, Shouti South Road, Haidian District
   Beijing
   China
   Email: hanmy12@chinaunicom.cn


   Cheng Li
   Huawei
   Email: c.l@huawei.com





































Zhou, et al.              Expires 23 April 2026                [Page 21]


name: draft-srijal-agents-policy
rev: 00
title: AGENTS.TXT: Strict Policy File for Automated Clients
time: 2025-10-07T15:18:17Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-10T15:18:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420409+00:00
abstract:
This document specifies the AGENTS.TXT protocol, a strict plaintext
   policy file for automated clients, bots, and crawlers.  It defines
   directives, top-line hash verification, optional parameters, and
   mandatory failure behavior for malformed files.  Malformed files are
   treated as fully restrictive to prevent unintended access.

full_text:
Network Working Group                                           S. Dutta
Internet-Draft                                               Independent
Intended status: Standards Track                          7 October 2025
Expires: 10 April 2026


          AGENTS.TXT: Strict Policy File for Automated Clients
                     draft-srijal-agents-policy-00

Abstract

   This document specifies the AGENTS.TXT protocol, a strict plaintext
   policy file for automated clients, bots, and crawlers.  It defines
   directives, top-line hash verification, optional parameters, and
   mandatory failure behavior for malformed files.  Malformed files are
   treated as fully restrictive to prevent unintended access.

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 10 April 2026.

Copyright Notice

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

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




Dutta                     Expires 10 April 2026                 [Page 1]

Internet-Draft                 AGENTS.TXT                   October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  File Location and Name  . . . . . . . . . . . . . . . . . . .   2
   3.  File Format . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Comments and Metadata . . . . . . . . . . . . . . . . . . . .   3
   5.  Agent Behavior on Malformed Files . . . . . . . . . . . . . .   3
   6.  Directive Syntax  . . . . . . . . . . . . . . . . . . . . . .   3
   7.  Hash Computation  . . . . . . . . . . . . . . . . . . . . . .   3
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   9.  Example agents.txt File . . . . . . . . . . . . . . . . . . .   3
   10. Additional Guidance . . . . . . . . . . . . . . . . . . . . .   4
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Appendix A.  Authors' Addresses . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   AGENTS.TXT is a strict policy file format for automated clients,
   similar in purpose to robots.txt (RFC9309) but providing more control
   over client behavior.  Malformed files are treated as completely
   restrictive.

   All AGENTS.TXT traffic validation is based on a SHA-256 hash (FIPS
   180-4 (FIPS180-4)) of the canonical directive content.

2.  File Location and Name

   The canonical path for the file is /agents.txt.  Files must be served
   as UTF-8 with content-type text/plain (HTTP/1.1 Semantics (RFC7231)).

3.  File Format

   The first non-comment, non-empty line MUST be the hash line, starting
   with '*' followed by the lowercase SHA-256 hex digest of the file
   excluding the hash line and comments (SHA-1 comparison (RFC3174) for
   historical reference).  Subsequent lines are directives:

   /status ALLOW

   /dashboard ALLOW limit=50

   /admin DISALLOW








Dutta                     Expires 10 April 2026                 [Page 2]

Internet-Draft                 AGENTS.TXT                   October 2025


4.  Comments and Metadata

   Lines starting with '#' are comments and ignored for hash computation
   and parsing.  Metadata such as version, generated-by, or grace-period
   may be included.

5.  Agent Behavior on Malformed Files

   Any hash missing, hash mismatch, or directive syntax error MUST
   result in treating the entire site as restricted (RFC 2119 (RFC2119)
   requirements).  Cached copies MUST be invalidated.

6.  Directive Syntax

   Each directive line has the format: <path> <action> [params...]

   <path> starts with '/', <action> is ALLOW or DISALLOW, and optional
   params are key=value pairs (URI syntax (RFC3986)).

7.  Hash Computation

   Compute SHA-256 over UTF-8 bytes of the file after removing the hash
   line, comments, and blank lines.  Join remaining lines with '\n' for
   hashing.

8.  Security Considerations

   Strict malformed-file behavior ensures accidental exposure does not
   occur.  Site operators must ensure valid files to prevent clients
   from blocking themselves (TLS Best Practices (RFC7525)).

9.  Example agents.txt File

   # version: 1.0

   *e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 \

   #sample. may not be accurate.

   /status ALLOW

   /dashboard ALLOW limit=50

   /admin DISALLOW







Dutta                     Expires 10 April 2026                 [Page 3]

Internet-Draft                 AGENTS.TXT                   October 2025


10.  Additional Guidance

   Clients SHOULD follow HTTP client best practices (RFC8792) and API
   crawler guidelines (RFC8899) when interpreting AGENTS.TXT directives.
   Use of AGENTS.TXT aims to reduce accidental site disruption (Bot
   traffic management (RFC8309)).

11.  Normative References

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

   [FIPS180-4]
              Technology, N. I. O. S. A., "SHA-256 Secure Hash
              Standard", 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

   [RFC9309]  McCarthy, A., "Robots.txt: History, Use, and
              Standardization", 2022,
              <https://www.rfc-editor.org/rfc/rfc9309>.

   [RFC7231]  Fielding, R., "Hypertext Transfer Protocol (HTTP/1.1):
              Semantics and Content", 2014,
              <https://www.rfc-editor.org/rfc/rfc7231>.

   [RFC3174]  Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", 2001,
              <https://www.rfc-editor.org/rfc/rfc3174>.

   [RFC3986]  Berners-Lee, T., "Uniform Resource Identifier (URI):
              Generic Syntax", 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC7525]  Rescorla, E., "Recommendations for Secure Use of Transport
              Layer Security (TLS) and Datagram TLS (DTLS)", 2015,
              <https://www.rfc-editor.org/rfc/rfc7525>.

   [RFC8309]  Pahl, C., "Bot Traffic and Management Best Practices",
              2018, <https://www.rfc-editor.org/rfc/rfc8309>.

   [RFC8792]  Smith, J., "HTTP Client Best Practices for Automated
              Agents", 2020, <https://www.rfc-editor.org/rfc/rfc8792>.

   [RFC8899]  Tan, L., "Guidelines for Secure API Crawlers", 2021,
              <https://www.rfc-editor.org/rfc/rfc8899>.






Dutta                     Expires 10 April 2026                 [Page 4]

Internet-Draft                 AGENTS.TXT                   October 2025


Appendix A.  Authors' Addresses

   Srijal Dutta

   Email: srijaldutta.official+agentstxt@gmail.com

Author's Address

   Srijal Dutta
   Independent
   Email: srijaldutta.official+agentstxt@gmail.com








































Dutta                     Expires 10 April 2026                 [Page 5]


name: draft-liang-agentdns
rev: 00
title: AgentDNS: A Root Domain Naming System for LLM Agents
time: 2025-10-09T02:15:50Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-12T02:15:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "A2A protocols", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:03.420412+00:00
abstract:
This document describes AgentDNS, a root domain naming and service
   discovery system designed for Large Language Model (LLM) agents.
   Inspired by the traditional Domain Name System (DNS), AgentDNS
   enables agents to autonomously discover, resolve, and securely invoke
   third-party agent and tool services across different vendors.
   AgentDNS introduces a unified namespace, semantic service discovery,
   protocol-aware interoperability, and unified authentication and
   billing.  The system aims to address interoperability, service
   discovery, and trust management challenges in large-scale agent
   collaboration ecosystems.

full_text:
Internet Engineering Task Force                            Z. Liang, Ed.
Internet-Draft                                                    E. Cui
Intended status: Informational          China Telecom Research Institute
Expires: 12 April 2026                                          Y. Cheng
                            University of Science and Technology Beijing
                                                          9 October 2025


          AgentDNS: A Root Domain Naming System for LLM Agents
                        draft-liang-agentdns-00

Abstract

   This document describes AgentDNS, a root domain naming and service
   discovery system designed for Large Language Model (LLM) agents.
   Inspired by the traditional Domain Name System (DNS), AgentDNS
   enables agents to autonomously discover, resolve, and securely invoke
   third-party agent and tool services across different vendors.
   AgentDNS introduces a unified namespace, semantic service discovery,
   protocol-aware interoperability, and unified authentication and
   billing.  The system aims to address interoperability, service
   discovery, and trust management challenges in large-scale agent
   collaboration ecosystems.

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 12 April 2026.

Copyright Notice

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






Liang, et al.             Expires 12 April 2026                 [Page 1]

Internet-Draft              Abbreviated Title               October 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  AgentDNS Architecture . . . . . . . . . . . . . . . . . . . .   7
     3.1.  AgentDNS System Overview  . . . . . . . . . . . . . . . .   7
     3.2.  Service Naming  . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  Service Discovery . . . . . . . . . . . . . . . . . . . .  10
     3.4.  Service Resolution  . . . . . . . . . . . . . . . . . . .  11
     3.5.  Unified Authentication and Billing  . . . . . . . . . . .  12
   4.  AgentDNS Case Study . . . . . . . . . . . . . . . . . . . . .  13
   5.  Future Opportunities  . . . . . . . . . . . . . . . . . . . .  15
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   The rapid evolution of LLM agents across industries has introduced
   new challenges in enabling seamless multi-agent collaboration.
   Existing protocols such as the Model Context Protocol (MCP)
   [MCP-Spec] and Agent-to-Agent (A2A) protocol [A2A-Spec] have improved
   agent-tool interoperability and communication.  However, these
   efforts lack a standardized root naming and discovery infrastructure
   to support autonomous cross-vendor interactions.  As a result,
   collaborations between agents still demands significant manual
   effort, preventing the realization of true autonomous cooperation.
   The specific challenges are as follows:

   *  *The Service Discovery Challenge:* LLM agents typically generate
      an action plan, where each action may require calling external
      tools or agent services [RFC6763].  However, currently, services
      from different vendors are not standardized in naming or
      management, which forces developers to manually maintain service
      information for each tool or agent.  This lack of standardization



Liang, et al.             Expires 12 April 2026                 [Page 2]

Internet-Draft              Abbreviated Title               October 2025


      makes it impossible for LLM agents to autonomously discover other
      agents or tool services, hindering seamless integration and
      collaboration between agents across different platforms.

   *  *The Interoperability Challenge:* Currently, different vendors'
      agents or tool services support various interoperability or
      communication protocols, with typical examples including MCP, A2A,
      and ANP (Agent Network Protocol Project 2025) [ANP-Doc].  We
      anticipate that more interoperability protocols will emerge in the
      future.  However, LLM agents are unable to autonomously recognize
      and adapt to these differences, meaning they still require manual
      configuration and management.  This lack of flexibility in
      handling diverse protocols limits seamless agent-to-agent and
      agent-to-tool communication across platforms.

   *  *The Authentication and Billing Challenge:* Cross-vendor
      collaboration is further complicated by security and
      authentication challenges.  Each service provider typically
      requires proprietary API keys, necessitating manual configuration
      of multiple authentication credentials for agents.  This adds
      significant overhead and disrupts seamless integration.  In
      addition, billing systems are fragmented across vendors, requiring
      manual intervention for payment setup.  As a result, agents are
      unable to autonomously discover and invoke new third-party paid
      agents or tool services without manual configuration.

   To address these challenges, this document introduces AgentDNS, the
   first root domain naming and resolution system designed for LLM
   agents.  Inspired by the Internet's DNS [RFC1035], AgentDNS
   introduces a unified namespace (*agentdns://*), natural language-
   based service discovery, and unified authentication and billing.  As
   shown in Figure 1, AgentDNS is compatible with protocols such as MCP
   and A2A, allowing them to coexist seamlessly.

   <preamble>:Illustrates the interaction between AgentDNS, A2A protocol, MCP, LLMs, and
             enterprise applications across different agent frameworks.
        














Liang, et al.             Expires 12 April 2026                 [Page 3]

Internet-Draft              Abbreviated Title               October 2025


                +-------------------------------------------+
                | | AgentDNS Root Server |                  |
                | +----------------------+   AgentDNS DB    |
                | |         LLM          |                  |
                +-----------+-------------------------------+
                                         |
                         +---------------+--------------+
                         |               |              |
                         v               |              v
              +--------------------+    A2A    +--------------------+
              | Agents (Vendor A)  | <-------> | Agents (Vendor B)  |
              | +----------------+ |     |     | +----------------+ |
              | | Agent Framework| |     |     | | Agent Framework| |
              | +----------------+ |     |     | +----------------+ |
              | |       LLM      | |     |     | |       LLM      | |
              +--------------------+     |     +--------------------+
                      |                  |               |
                     MCP                 |              MCP
                      |                  |               |
                      v                  |               v
          +--------------------------+   |    +--------------------------+
          | API & Enterprise Systems |   |    | API & Enterprise Systems |
          +--------------------------+   |    +--------------------------+
                                         |
                       Organizational / Technological Boundary

   Figure 1: AgentDNS system and its relationship with A2A and MCP
                              Protocols

   With AgentDNS, agents can autonomously discover services,
   authenticate, and interoperate seamlessly across organizational
   boundaries.  AgentDNS redefines the multi-agent collaboration
   ecosystem through four key functions:

   *  *Unified Namespace with Semantic Information:* AgentDNS introduces
      a semantically rich naming scheme (e.g., agentdns://org/category/
      name) for agents and tool services, decoupling service identifier
      name from physical addresses such as URLs.  This also enables the
      semantic embedding of agent capabilities into their identifier
      name, facilitating more efficient classification and retrieval of
      agent and tool services.










Liang, et al.             Expires 12 April 2026                 [Page 4]

Internet-Draft              Abbreviated Title               October 2025


   *  *Natural Language-Driven Service Discovery:* Agents can interact
      with the AgentDNS root service using natural language queries to
      discover third-party agents or tool services.  They can obtain the
      corresponding service identifier names and related metadata,
      including physical addresses, capabilities, and communication
      protocol, etc.  Agents can also dynamically request the AgentDNS
      root service to resolve an identifier name and retrieve the latest
      metadata as needed.

   *  *Protocol-Aware Interoperability:* AgentDNS enables agents to
      dynamically discover the supported interoperability or
      communication protocols of third-party agents and tool services by
      resolving their identifier names into metadata.  This metadata
      includes not only network addresses and capabilities, but also the
      specific protocols (e.g., MCP, A2A, ANP) each service supports.
      Based on this information, agents can autonomously select and
      adapt to the appropriate protocol for communication, eliminating
      the need for manual configuration.

   *  *Unified Authentication and Billing:* AgentDNS replaces fragmented
      API keys with a single-sign-on mechanism.  Agents authenticate
      once with the AgentDNS root server to obtain time-bound access
      tokens, valid across all registered services.  For billing,
      AgentDNS serves as a unified billing platform: users pre-fund
      accounts, usage costs are tracked and deducted in real-time, and
      payments are automatically settled across vendors.  This enables
      transparent billing and autonomous access to paid services by
      agents.

2.  Related Work

   *LLM Agents*
      LLM agents have rapidly emerged as a pivotal research frontier in
      artificial intelligence, driven by their transformative potential
      to bridge human-AI collaboration and autonomous problem-solving.
      In the industrial, several LLM agents have been launched, such as
      Deep Research [Deep-Research], Manus [Manus], and Cursor
      (Anysphere 2025) [Cursor], etc.  Unlike traditional AI systems
      constrained by predefined rules, LLM agents leverage the general-
      purpose reasoning, contextual understanding, and multi-task
      capabilities of LLMs to dynamically adapt to complex environments.
      LLM agents have demonstrated broad application prospects across
      various fields.  The future of LLM agents is expected to trend
      towards multi-agent collaboration.  Researchers are increasingly
      interested in how to design efficient communication protocols and
      coordination mechanisms [hou2025model] [marro2024scalable] that
      enable seamless cooperation among agents.  This collaborative
      approach is seen as a key direction for advancing the capabilities



Liang, et al.             Expires 12 April 2026                 [Page 5]

Internet-Draft              Abbreviated Title               October 2025


      and applications of LLM agents in the coming years.

   *Agent Interaction Protocols*
      *Model Context Protocol.* The Model Context Protocol (MCP) (Hou et
      al.  2025) is an open standard developed by Anthropic, designed to
      facilitate seamless interactions between LLM models and external
      tools, data sources, and services.  Inspired by the concept of a
      universal adapter, MCP aims to simplify the integration process,
      much like how a USB-C port allows various devices to connect
      effortlessly.  MCP operates on a client-server architecture.  The
      AI application (such as a chatbot or an integrated development
      environment) acts as the host and runs an MCP client, while each
      external integration runs as an MCP server.  The server exposes
      capabilities such as functions, data resources, or predefined
      prompts, and the client connects to it to utilize these
      capabilities.  This design allows AI models to interact with
      external systems without directly accessing APIs, thereby
      enhancing security and reducing the complexity of custom
      integrations.

      *Agent-to-Agent Protocol.* The Agent-to-Agent (A2A) protocol
      (Google 2025) is introduced by Google, aimed at enabling seamless
      communication and collaboration between LLM agents, regardless of
      their underlying frameworks or vendors.  A2A was developed in
      collaboration with over 50 technology partners, including major
      companies like Atlassian, Salesforce, SAP, and MongoDB.  This
      protocol uses HTTP-based APIs and JSON data format, ensuring
      compatibility and ease of integration with existing enterprise IT
      systems.  It supports various communication patterns, including
      request-response, event-based communication, and streaming data
      exchange.  A2A complements protocols like MCP, which focuses on
      providing tools and context for agents.  A2A focuses on agent-to-
      agent communication, allowing them to work together more
      effectively.

   *Domain Naming System*
      The Domain Name System (DNS) [danzig1992analysis]
      [cheshire2013rfc6763] serves as the critical naming and discovery
      infrastructure for the human internet, translating memorable
      domain names (e.g., example.  com) into physical addresses (IP
      addresses) through its hierarchical, decentralized architecture.
      While DNS effectively decouples human-readable names from machine-
      level addressing, its design proves inadequate for the emerging
      agent Internet where LLM agents require autonomous service
      discovery and interoperability.  Traditional DNS lacks three
      critical capabilities essential for agent ecosystems: service
      discovery through natural language, querying service metadata
      beyond physical addresses (including capabilities, protocols,



Liang, et al.             Expires 12 April 2026                 [Page 6]

Internet-Draft              Abbreviated Title               October 2025


      etc.), and unified authentication and billing.  These limitations
      necessitate AgentDNS-a purpose-built system that preserves DNS's
      core benefits of naming and resolution while introducing agent-
      specific innovations.

3.  AgentDNS Architecture

3.1.  AgentDNS System Overview

   AgentDNS is a root service system for agent service naming,
   discovery, and resolution, enabling seamless service discovery,
   cross-vendor interoperability, unified authentication and billing.
   As shown in Figure 2, the AgentDNS root server is the central hub of
   the entire system, which connects agent users (e.g., Agent A) with
   service providers (e.g., Agent Service B, Tool Service D).  The
   AgentDNS root server comprises components including service
   registration, service proxy pool[RFC5625], service management,
   service search, service resolution, billing, authentication, etc.
   The core components are as follows:

   *  Service Registration Component: Agent or tool service vendors
      register their services through this component.  The process
      begins with organization registration, where developers first
      create an organization account.  Under the organization's domain,
      they then setup a service category and name to generate a globally
      unique service identifier name (e.g., agentdns://org/category/
      name).  Concurrently, developers must submit service metadata to
      bind with the identifier, including network addresses (e.g.,
      endpoints, URLs), supported interoperability protocols (e.g., MCP,
      A2A), detailed service capabilities, etc.  This metadata is
      securely stored in the AgentDNS database.  During subsequent
      service discovery or resolution phases, the system performs
      semantic matching by analyzing the identifier's category and the
      metadata.  This ensures precise retrieval of services aligned with
      an agent's operational requirements [RFC7720].

   *  Service Proxy Pool: After a vendor registers a service, AgentDNS
      creates a corresponding service proxy within the Service Proxy
      Pool.  This proxy acts as an intermediary, forwarding service
      invocation requests from user agents to the vendor's actual
      service endpoint.  In other words, the user agent sends a service
      request to the AgentDNS root server, which then routes the request
      to the appropriate vendor for execution.  This design allows user
      agents to authenticate only once with AgentDNS, eliminating the
      need for separate registration and authentication with each
      individual vendor.





Liang, et al.             Expires 12 April 2026                 [Page 7]

Internet-Draft              Abbreviated Title               October 2025


   *  Service Search Component: User agents can send natural language
      queries to the AgentDNS root server to discover relevant third-
      party agents or tool services.  This component interprets the
      query and performs intelligent retrieval using a combination of
      keyword matching and retrieval-augmented generation (RAG)
      [gao2023retrieval] techniques.  Based on the search results, it
      returns a list of top-k candidate services that match the agent's
      intent.  Each result includes the service identifier name,
      physical endpoint, supported communication protocols, capability
      descriptions, and pricing information.  The user agent can then
      evaluate these candidates and choose the most appropriate one for
      execution.  Once selected, the agent can directly invoke the
      service by using the appropriate protocol and access the physical
      endpoint with an authentication token issued by AgentDNS.

   *  Service Resolution Component: User agents can cache service
      identifier names and, during subsequent invocations, dynamically
      request the AgentDNS root server to resolve these identifiers and
      get the latest metadata as needed.

   *  Service Management Component: This component handles the lifecycle
      of these service proxies, including their creation, updates, and
      deletion, ensuring that the proxy infrastructure remains up-to-
      date and synchronized with the underlying services.

   *  Service Billing Component: This component is responsible for
      tracking and processing service invocation costs.  Users only need
      to settle payments directly with AgentDNS, which then handles the
      backend settlement with individual vendors.  This design
      significantly simplifies the billing process for users by
      eliminating the need for managing multiple vendor-specific payment
      systems, enabling a streamlined and unified billing experience.

   *  Authentication Component: This component handles identity
      verification and access control for both user agents and service
      providers.  Instead of requiring agents to authenticate separately
      with each vendor, AgentDNS offers a unified authentication
      mechanism.  User agents authenticate once with the AgentDNS root
      server and receive a time-bound access token.  This token can be
      used to securely access any registered third-party service without
      additional logins.  By centralizing authentication, this component
      ensures secure, efficient, and scalable access across a
      heterogeneous agent ecosystem, while also reducing the operational
      burden on both users and service vendors.







Liang, et al.             Expires 12 April 2026                 [Page 8]

Internet-Draft              Abbreviated Title               October 2025


      <preamble>:
                  This figure illustrates the architecture of the AgentDNS system, its API interface,
                  and interactions with agents and services.
          
          
                           +-----------------------------------------+
                           |          AgentDNS Root Server           |
                           |  +----------------+   +--------------+  |
                           |  |   Resolution   |   |    Search    |  |
                           |  +----------------+   +--------------+  |
                           |  |    Billing     |   |    Manage    |  |
                           |  +----------------+   +--------------+  |
                           |  | Authentication |   | Registration |  |
                           |  +----------------+   +--------------+  |
                           |          Service Proxy Pool             |
                           |     (Agent Svc B, C, Tool Svc D...)     |
                           |                                         |
                           |        +------------------------+       |
                           |        | AgentDNS API Server    |       |
                           |        +------------------------+       |
                           +---------------------+-------------------+
                                        ▲          ▲
         +--------------+               |          |
         |   Agent A    |---------------+          |
         +--------------+   Natural Lang Query     |
               |                                   |
               |                                   |
               |                       +----------------------+
               |                       | Service Registration |
               |                       +----------------------+
               |                                   ▲
               |                                   |
               |    Service Call                   |
               | (Proxy by AgentDns)    +---------------------------+
               +----------------------> | AgentSvcB, AgentSvcC, ... |
                                        | Tool Service D ...        |
                                        +---------------------------+

                   Figure 2: AgentDNS System Architecture

   Together, these components form the backbone of AgentDNS, providing a
   unified framework that supports natural language-driven discovery,
   protocol-aware interoperability, trustless authentication, and
   unified billing-paving the way for truly autonomous multi-agent
   ecosystems.  Next, we will provide a detailed introduction to
   AgentDNS's service naming, service discovery, service resolution, and
   unified authentication and billing mechanisms.




Liang, et al.             Expires 12 April 2026                 [Page 9]

Internet-Draft              Abbreviated Title               October 2025


3.2.  Service Naming

   The AgentDNS service naming system provides a structured and globally
   unique service identifier name for each registered agent or tool
   service.  The identifier name follows the format as shown in
   Figure 3.  The organization represents the name of the registering
   entity, such as a company, university, or research lab.  Each
   organization must go through a registration and verification process
   to ensure uniqueness and authenticity.  The category denotes the
   functional domain or classification of the agent service.  This can
   be chosen manually by the developer or automatically generated by
   AgentDNS, and it supports hierarchical structures—allowing for multi-
   level categories using slashes (e.g., academic/nlp/summarization).
   Finally, the name is the unique identifier for the specific agent
   within the organization and category.  This name must be explicitly
   defined by the developer.  Together, this structured naming
   convention ensures precise identification, facilitates organized
   discovery, and supports scalable service management within the
   AgentDNS ecosystem.

      <preamble>:
                  This figure shows the structure of an AgentDNS service name, including prefix,
                  organization, category, and agent name.
          
          
     Service Identifier Format:

     agentdns://{organization}/{category}/{name}
         |            |             |         |
       Prefix    Organization    Category   Name

     Example:
     agentdns://example/academic/paperagent

                     Figure 3: AgentDNS Service Naming

3.3.  Service Discovery

   The service discovery process is illustrated in Figure 4.  In step 1,
   Agent A initiates a natural language query to the AgentDNS root
   server, describing the desired service.  In the example, Agent A is
   looking for an intelligent Agent capable of analyzing academic
   papers.  In step 2, upon receiving the request, AgentDNS searches
   through its registry of available services to identify those with the
   required capabilities.  It returns a list of service identifiers
   along with corresponding metadata, such as the proxy's physical
   address, supported protocols, pricing information, and more.  This
   discovery process employs a hybrid retrieval mechanism that combines



Liang, et al.             Expires 12 April 2026                [Page 10]

Internet-Draft              Abbreviated Title               October 2025


   keyword matching and RAG.  Specifically, we construct a knowledge
   base using the capability descriptions of registered services.
   During service discovery, hybrid retrieval is performed over these
   capability descriptions to identify candidates that best match the
   user agent's intent.  In step 3, after receiving the service
   information, Agent A uses the appropriate protocol and an
   authentication token issued by AgentDNS to directly access the
   physical proxy address and initiate a service call.  Finally, in step
   4, the AgentDNS proxy forwards the request to the actual service
   endpoint hosted by the vendor, ensuring seamless interaction between
   Agent A and the service provider.

   <preamble>:Illustrates how Agent A discovers and interacts with an academic paper analysis
               agent through the AgentDNS Root Server and proxy layers.
          
  +------------------+                              +------------------------+
  |     Agent A      |                              |  AgentDNS Root Server  |
  +------------------+                              +------------------------+
        |   ① Prompt: "I need an agent                         ▲
        |      for academic paper analysis."                   |
        |----------------------------------------------------->|
        |                                                      |
        |   ② Search Result:                                   |
        |      agentdns://example/academic/paperagent          |
        |<-----------------------------------------------------|
        |                                                      |
        |                                                      v
        |   ③ Service call                        +------------------------+
        |---------------------------------------> |   paperagent proxy     |
                                                  +------------------------+
                                                            |
                                                            | ④ Forward
                                                            v
                                                  +------------------------+
                                                  |      paperagent        |
                                                  +------------------------+

            Figure 4: AgentDNS Service Discovery Workflow

3.4.  Service Resolution

   As previously mentioned, user agents can cache service identifier
   names and request the AgentDNS root server for updated metadata when
   needed.  This functionality helps reduce the frequency of accessing
   AgentDNS, improving response times and lowering operational costs.
   The service resolution process is illustrated in Figure 5.  In step
   1, agent vendors update the metadata associated with their agent
   services.  In step 2, Agent A sends a resolution request to the



Liang, et al.             Expires 12 April 2026                [Page 11]

Internet-Draft              Abbreviated Title               October 2025


   AgentDNS root server, providing the cached service identifier name to
   retrieve the latest information.  In step 3, AgentDNS locates the
   most recent metadata based on the identifier and returns it to Agent
   A, ensuring that the service invocation uses up-to-date information.

   <preamble>:
               Illustrates how an agent (paperagent) updates its metadata to the AgentDNS Root Server,
               and how another agent (Agent A) resolves the service via AgentDNS to retrieve updated
               metadata.
          
          
            +-------------+                           +------------------------+
            | paperagent  |                           | AgentDNS Root Server   |
            +-------------+                           +------------------------+
                  |                                            ▲
            ① Metadata Update:                                 |
              Old metadata -> New metadata                     |
                  |------------------------------------------->|
                                                               |
                                                               |
                                                      ② Service Resolution:
                                              agentdns://example/academic/paperagent
                                                               |
                  |<-------------------------------------------|
                  v
            +-------------+
            |  Agent A    |
            +-------------+
                  |
            ③ New metadata
                  |
                  v
            (uses updated metadata)

                Figure 5: AgentDNS service resolution

3.5.  Unified Authentication and Billing

   AgentDNS introduces a unified authentication and billing mechanism by
   acting as a proxy layer between user agents and third-party services.
   As shown in Figure 6, when a user agent (e.g., Agent A) authenticates
   once with the AgentDNS root server using its own access key (Key A),
   it gains the ability to seamlessly invoke multiple external agent or
   tool services without needing to manage individual credentials for
   each provider.  Internally, the AgentDNS root server maintains a
   service proxy pool that forwards user requests to the corresponding
   third-party services.  For each thirdparty service, the proxy uses
   the appropriate authentication key (e.g., Key B, C, or D), which



Liang, et al.             Expires 12 April 2026                [Page 12]

Internet-Draft              Abbreviated Title               October 2025


   corresponds to the access control requirements of the service
   provider.  This abstraction decouples the user agent from vendor-
   specific authentication logic.  Moreover, billing is centralized:
   user agents are charged by AgentDNS based on their usage, while
   AgentDNS handles settlements with the respective thirdparty services.
   This model simplifies cross-vendor interoperability, enforces secure
   access, and enables consistent billing across a heterogeneous service
   ecosystem.

   <preamble>:Agent A resolves services via the AgentDNS Root Server, including billing,
               authentication, and service redirection using keys.
          
  +--------+        +---------------------------+        +------------------+
  | Agent  |        |   AgentDNS Root Server    |        | Service B        |
  |   A    |------->| +-----------------------+ |------->| (via Key B)      |
  |        |  Key A | |  Service Billing      | |        +------------------+
  +--------+        | +-----------------------+ |
                    | +-----------------------+ |        +------------------+
                    | | Authentication        | |------->| Service C        |
                    | +-----------------------+ |        | (via Key C)      |
                    | +-----------------------+ |        +------------------+
                    | | Agent Service B       | |
                    | +-----------------------+ |        +------------------+
                    | +-----------------------+ |------->| Tool Service D   |
                    | | Agent Service C       | |        | (via Key D)      |
                    | +-----------------------+ |        +------------------+
                    | +-----------------------+ |
                    | | Tool Service D        | |
                    | +-----------------------+ |
                    | (Via Service Proxy Pool)  |
                    +---------------------------+

        Figure 6: AgentDNS Unified Authentication and Billing

4.  AgentDNS Case Study

   In this section, we present a case study illustrating the interaction
   between an agent and the AgentDNS root server.  The case demonstrates
   the complete agent workflow—from generating an action plan
   [huang2024understanding], to querying the AgentDNS root server for
   service discovery, and finally to executing the planned actions.

   The full process is illustrated in Figure 7.  After receiving a user
   request—such as “Help me research agent communication protocols and
   write a survey report”—the agent first invokes a LLM to generate an
   action plan.  As shown in Figure 7, the generated plan in this case
   is structured in JSON format and consists of multiple steps.  Each
   step includes a description of its purpose, whether it requires a



Liang, et al.             Expires 12 April 2026                [Page 13]

Internet-Draft              Abbreviated Title               October 2025


   service, and a natural language description of the desired service
   functionality.  These services correspond to third-party agent or
   tool services.  For example, Step 1 requires a search service to
   retrieve relevant keywords, while Step 3 calls for a standards
   retrieval service to query documents from organizations like IEEE
   (IEEE Standards Association 2025) [ieee2025] or ITU-T (International
   Telecommunication Union 2025) [itut2025].

   <preamble>:Illustrates how an LLM-generated action plan is executed through AgentDNS-based
             service discovery and agent invocation.
        
+---------------------------------+       +------------------------------+       +------------------------------+
| Action Plan                     |       |  Service Discovery           |       | Action Execution             |
| (Generated by LLM)              |       |  (via AgentDNS Search)       |       | (Step by step)               |
+---------------------------------+       +------------------------------+       +------------------------------+
| steps:                          |       | agentdns://example/search/   |       | Execute step 1               |
| 1. Use search engines...        |       | searchagent                  |       | (Call searchagent)           |
|    tool_required: true          |       |   - protocol: MCP            |       +------------------------------+
|    tool_function: keyword search|       |   - cost: $1/million tokens  |       | Execute step 2               |
|                                 |       |   - capability: keyword search|      | (LLM + Prompt)               |
| 2. Analyze communication...     |       +------------------------------+       +------------------------------+
|    tool_required: false         |       | agentdns://example/standard/ |       | Execute step 3               |
|                                 |       | standardagent                |       | (Call standardagent)         |
| 3. Summarize standardization    |       |   - protocol: MCP            |       +------------------------------+
|    tool_required: true          |       |   - cost: free               |       | Execute step 4               |
|    tool_function: query IEEE... |       |   - capability: standard query|      | (LLM + Prompt)               |
| 4. Write the research report    |       +------------------------------+       +------------------------------+
+---------------------------------+                    ^                                 ^
        |                                              |                                 |
        |----------------------------------------------|---------------------------------|
                                        Uses AgentDNS Root Server

                    Figure 7: AgentDNS Case Study

   After generating the action plan, the agent submits a natural
   language query to the AgentDNS root server to discover suitable
   third-party services.  For instance, in Step 1, the agent sends the
   tool function description directly to AgentDNS, which uses
   intelligent retrieval methods to identify matching services.  Suppose
   AgentDNS returns a service named agentdns://example/search/
   searchagent; it also provides metadata such as the physical endpoint,
   supported protocols, service cost, capabilities, and available APIs.
   The agent uses this information to invoke the selected third-party
   service.

   Following service discovery, the agent enters the action execution
   phase.  During this stage, it executes the steps of the action plan
   in sequence.  When a step requires a service, the agent uses the



Liang, et al.             Expires 12 April 2026                [Page 14]

Internet-Draft              Abbreviated Title               October 2025


   corresponding protocol to access the thirdparty service obtained from
   AgentDNS and passes the result to the next step.  For steps that do
   not involve external services, the agent inputs the step purpose
   description, along with previous outputs and prompt instructions,
   into the LLM for generation.  This process continues until all steps
   in the action plan are completed.

   This case study presents a simplified example, while in practice, the
   structure and format of an action plan can be adapted to suit
   different needs.  Importantly, the third-party service descriptions
   within the action plan are expressed in natural language, which means
   they are not tightly coupled with specific service identifiers, tool
   names, or endpoint URLs.  AgentDNS plays a critical role in
   decoupling the foundational agent model from vendor-specific details
   such as service names, tool identifiers, and physical addresses,
   enabling more flexible and scalable agent architectures.

5.  Future Opportunities

   While AgentDNS addresses fundamental challenges in service discovery,
   interoperability, and billing in the agent ecosystem, numerous
   directions remain open for future exploration.  These include
   decentralized and federated architecture, AgentDNS-compatible agent
   planning LLMs, privacy-preserving [RFC8932] and trusted discovery, as
   well as AgentDNS service discovery optimization.  First, while the
   current design of AgentDNS adopts a centralized architecture, future
   iterations may benefit from decentralized or federated
   [huang2024aggregate] architecture, such as blockchain
   [karaarslan2018blockchain].  This would improve robustness, reduce
   the risk of single points of failure, and enhance trust in cross-
   organizational collaborations.  Second, training and fine-tuning
   agent planning LLMs [wang2023describe] [hu2024agentgen] specifically
   compatible with AgentDNS is also an important direction.  This can
   involve constructing agent planning datasets and fine-tuning LLMs to
   enhance their compatibility with AgentDNS.  Alternatively,
   reinforcement learning techniques [wen2024reinforcing]
   [jin2025search] [qi2024webrl] [peiyuan2024agile] can be used to train
   agents to autonomously explore and optimize action sequences,
   dynamically selecting and combining various services registered in
   AgentDNS to maximize task success rates and efficiency.  Third,
   security and privacy will remain central in crossvendor agent
   collaboration.  Future directions may involve privacy-preserving
   search and resolution, using technologies such as homomorphic
   encryption [buban2025encrypted], differential privacy, and secure
   multi-party computation.  AgentDNS could also integrate trust and
   reputation systems to allow agents to evaluate service quality and
   security risks before invocation.  Finally, the optimization of
   AgentDNS service discovery and retrieval remains a critical area for



Liang, et al.             Expires 12 April 2026                [Page 15]

Internet-Draft              Abbreviated Title               October 2025


   improving system performance and user experience.

6.  Conclusion

   The rapid advancement of LLM agents has exposed critical gaps in
   cross-vendor service discovery, interoperability, and authentication,
   hindering the vision of autonomous multiagent collaboration.  This
   document introduces AgentDNS, a unified root domain naming system
   designed to bridge these gaps by providing a semantically rich
   namespace, natural language-driven service discovery, protocol-aware
   interoperability, and trustless authentication and billing.  By
   decoupling agent identifiers from physical addresses and embedding
   dynamic metadata resolution, AgentDNS enables agents to autonomously
   discover, resolve, and securely invoke services across organizational
   and technological boundaries.  Our architecture and case studies
   demonstrate its potential to streamline multi-agent workflows, reduce
   manual overhead, and foster an open ecosystem for agent
   collaboration.  Future works include decentralized and federated
   architecture, AgentDNS-compatible agent planning LLMs, privacy-
   preserving and trusted discovery, as well as AgentDNS service
   discovery optimization, etc.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   This document should not affect the security of the Internet.

9.  References

9.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
              BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
              <https://www.rfc-editor.org/info/rfc5625>.






Liang, et al.             Expires 12 April 2026                [Page 16]

Internet-Draft              Abbreviated Title               October 2025


   [RFC7720]  Blanchet, M. and L. Liman, "DNS Root Name Service Protocol
              and Deployment Requirements", BCP 40, RFC 7720,
              DOI 10.17487/RFC7720, December 2015,
              <https://www.rfc-editor.org/info/rfc7720>.

   [RFC8932]  Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
              A. Mankin, "Recommendations for DNS Privacy Service
              Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
              October 2020, <https://www.rfc-editor.org/info/rfc8932>.

9.2.  Informative References

   [MCP-Spec] Model Context Protocol Specification Authors, "Model
              Context Protocol (MCP) Specification", March 2025,
              <https://modelcontextprotocol.io/
              specification/2025-03-26>.

   [A2A-Spec] Agent2Agent Protocol Specification Authors, "Agent2Agent
              (A2A) Protocol Specification", 2025,
              <https://github.com/google/A2A>.

   [ANP-Doc]  Agent Network Protocol Authors, "Agent Network Protocol
              (ANP) | Complete Guide to Agent Network Protocol", 2025,
              <https://agentnetworkprotocol.com/en/docs/>.

   [Deep-Research]
              OpenAI, "Introducing Deep Learning Research", 2025,
              <https://openai.com/index/introducing-deep-research/>.

   [Manus]    Monica, "Manus: A New Kind of AI", 2025,
              <https://manus.im/>.

   [Cursor]   Cursor, "Cursor: A New Kind of AI Editor", 2025,
              <https://cursor.com/en/agents>.

   [hou2025model]
              Hou, Xinyi., Zhao, Yanjie., Wang, Shenao., and Haoyu.
              Wang, "Model context protocol (mcp): Landscape, security
              threats, and future research directions", arXiv preprint
              arXiv:2503.23278 2025, 2025.

   [ding2024large]
              Ding, Han., Li, Yinheng., Wang, Junhao., and Hang. Chen,
              "Large language model agent in financial trading: A
              survey", arXiv preprint arXiv:2408.06361 2024, 2024.






Liang, et al.             Expires 12 April 2026                [Page 17]

Internet-Draft              Abbreviated Title               October 2025


   [chu2025llm]
              Chu, Zhendong., Wang, Shen., Xie, Jian., Zhu, Tinghui.,
              Yan, Yibo., Ye, Jinheng., Zhong, Aoxiao., Hu, Xuming.,
              Liang, Jing., Yu, Philip S., and others, "Llm agents for
              education: Advances and applications", arXiv preprint
              arXiv:2503.11733 2025, 2025.

   [alzubi2025open]
              Alzubi, Salaheddin., Brooks, Creston., Chiniya, Purva.,
              Contente, Edoardo., von Gerlach, Chiara., Irwin, Lucas.,
              Jiang, Yihan., Kaz, Arda., Nguyen, Windsor., Oh, Sewoong.,
              and others, "Open deep search: Democratizing search with
              open-source reasoning agents", arXiv preprint
              arXiv:2503.20201 2025, 2025.

   [chen2024mindsearch]
              Chen, Zehui., Liu, Kuikun., Wang, Qiuchen., Liu,
              Jiangning., Zhang, Wenwei., Chen, Kai., and Feng. Zhao,
              "Mindsearch: Mimicking human minds elicits deep ai
              searcher", arXiv preprint arXiv:2407.20183 2024, 2024.

   [luo2025large]
              Luo, Junyu., Zhang, Weizhi., Yuan, Ye., Zhao, Yusheng.,
              Yang, Junwei., Gu, Yiyang., Wu, Bohan., Chen, Binqi.,
              Qiao, Ziyue., Long, Qingqing., and others, "Large Language
              Model Agent: A Survey on Methodology, Applications and
              Challenges", arXiv preprint arXiv:2503.21460 2025, 2025.

   [googlea2a]
              Google, "An open protocol enabling communication and
              interoperability between opaque agentic applications.",
              2025.

   [marketsandmarkets_ai_agents]
              {MarketsandMarkets}, "AI Agents Market", 2025.

   [guo2024large]
              Guo, Taicheng., Chen, Xiuying., Wang, Yaqi., Chang,
              Ruidi., Pei, Shichao., Chawla, Nitesh V., Wiest, Olaf.,
              and Xiangliang. Zhang, "Large language model based multi-
              agents: A survey of progress and challenges", arXiv
              preprint arXiv:2402.01680 2024, 2024.

   [han2024llm]
              Han, Shanshan., Zhang, Qifan., Yao, Yuhang., Jin,
              Weizhao., Xu, Zhaozhuo., and Chaoyang. He, "LLM multi-
              agent systems: Challenges and open problems", arXiv
              preprint arXiv:2402.03578 2024, 2024.



Liang, et al.             Expires 12 April 2026                [Page 18]

Internet-Draft              Abbreviated Title               October 2025


   [yang2025survey]
              Yang, Yingxuan., Chai, Huacan., Song, Yuanyi., Qi,
              Siyuan., Wen, Muning., Li, Ning., Liao, Junwei., Hu,
              Haoyi., Lin, Jianghao., Chang, Gaowei., and others, "A
              Survey of AI Agent Protocols", arXiv preprint
              arXiv:2504.16736 2025, 2025.

   [yan2025beyond]
              Yan, Bingyu., Zhang, Xiaoming., Zhang, Litian., Zhang,
              Lian., Zhou, Ziyi., Miao, Dezhuang., and Chaozhuo. Li,
              "Beyond self-talk: A communication-centric survey of llm-
              based multi-agent systems", arXiv preprint
              arXiv:2502.14321 2025, 2025.

   [cheshire2013rfc6763]
              Cheshire, Stuart. and Marc. Krochmal, "RFC 6763: DNS-Based
              Service Discovery", 2013.

   [danzig1992analysis]
              Danzig, Peter B., Obraczka, Katia., and Anant. Kumar, "An
              analysis of wide-area name server traffic: A study of the
              internet domain name system", Conference proceedings on
              Communications architectures \& protocols 1992, 1992.

   [openai2025deepresearch]
              {OpenAI}, "Introducing Deep Research", 2025.

   [manus2025]
              {Monica}, "Leave it to Manus", 2025.

   [cursor2025]
              }, {Anysphere., "Cursor: The AI Code Editor", 2025.

   [li2024improving]
              Li, Yunxuan., Du, Yibing., Zhang, Jiageng., Hou, Le.,
              Grabowski, Peter., Li, Yeqing., and Eugene. Ie, "Improving
              multi-agent debate with sparse communication topology",
              arXiv preprint arXiv:2406.11776 2024, 2024.

   [marro2024scalable]
              Marro, Samuele., La Malfa, Emanuele., Wright, Jesse., Li,
              Guohao., Shadbolt, Nigel., Wooldridge, Michael., and
              Philip. Torr, "A scalable communication protocol for
              networks of large language models", arXiv preprint
              arXiv:2410.11905 2024, 2024.






Liang, et al.             Expires 12 April 2026                [Page 19]

Internet-Draft              Abbreviated Title               October 2025


   [huang2024understanding]
              Huang, Xu., Liu, Weiwen., Chen, Xiaolong., Wang, Xingmei.,
              Wang, Hao., Lian, Defu., Wang, Yasheng., Tang, Ruiming.,
              and Enhong. Chen, "Understanding the planning of LLM
              agents: A survey", arXiv preprint arXiv:2402.02716 2024,
              2024.

   [gao2023retrieval]
              Gao, Yunfan., Xiong, Yun., Gao, Xinyu., Jia, Kangxiang.,
              Pan, Jinliu., Bi, Yuxi., Dai, Yixin., Sun, Jiawei., Wang,
              Haofen., and Haofen. Wang, "Retrieval-augmented generation
              for large language models: A survey", arXiv preprint
              arXiv:2312.10997 2023, 2023.

   [ieee2025] Association, IEEE Standards., "IEEE Standards Association
              Official Website", 2025.

   [itut2025] Union, International Telecommunication., "ITU-T:
              Telecommunication Standardization Sector", 2025.

   [li2021b]  Li, Zecheng., Gao, Shang., Peng, Zhe., Guo, Songtao.,
              Yang, Yuanyuan., and Bin. Xiao, "B-DNS: A secure and
              efficient DNS based on the blockchain technology", IEEE
              Transactions on Network Science and Engineering 2021,
              2021.

   [karaarslan2018blockchain]
              Karaarslan, Enis. and Eylul. Adiguzel, "Blockchain based
              DNS and PKI solutions", IEEE Communications Standards
              Magazine 2018, 2018.

   [huang2024aggregate]
              Huang, Chih-Kai. and Guillaume. Pierre, "Aggregate
              Monitoring for Geo-Distributed Kubernetes Cluster
              Federations", IEEE Transactions on Cloud Computing 2024,
              2024.

   [wang2023describe]
              Wang, Zihao., Cai, Shaofei., Chen, Guanzhou., Liu, Anji.,
              Ma, Xiaojian Shawn., and Yitao. Liang, "Describe, explain,
              plan and select: interactive planning with llms enables
              open-world multi-task agents", Advances in Neural
              Information Processing Systems 2023, 2023.








Liang, et al.             Expires 12 April 2026                [Page 20]

Internet-Draft              Abbreviated Title               October 2025


   [hu2024agentgen]
              Hu, Mengkang., Zhao, Pu., Xu, Can., Sun, Qingfeng., Lou,
              Jianguang., Lin, Qingwei., Luo, Ping., and Saravan.
              Rajmohan, "Agentgen: Enhancing planning abilities for
              large language model based agent via environment and task
              generation", arXiv preprint arXiv:2408.00764 2024, 2024.

   [wen2024reinforcing]
              Wen, Muning., Wan, Ziyu., Wang, Jun., Zhang, Weinan., and
              Ying. Wen, "Reinforcing LLM Agents via Policy Optimization
              with Action Decomposition", The Thirty-eighth Annual
              Conference on Neural Information Processing Systems 2024,
              2024.

   [jin2025search]
              Jin, Bowen., Zeng, Hansi., Yue, Zhenrui., Yoon, Jinsung.,
              Arik, Sercan., Wang, Dong., Zamani, Hamed., and Jiawei.
              Han, "Search-r1: Training llms to reason and leverage
              search engines with reinforcement learning", arXiv
              preprint arXiv:2503.09516 2025, 2025.

   [qi2024webrl]
              Qi, Zehan., Liu, Xiao., Iong, Iat Long., Lai, Hanyu., Sun,
              Xueqiao., Zhao, Wenyi., Yang, Yu., Yang, Xinyue., Sun,
              Jiadai., Yao, Shuntian., and others, "WebRL: Training LLM
              Web Agents via Self-Evolving Online Curriculum
              Reinforcement Learning", arXiv preprint
              arXiv:2411.02337 2024, 2024.

   [peiyuan2024agile]
              Peiyuan, Feng., He, Yichen., Huang, Guanhua., Lin, Yuan.,
              Zhang, Hanchong., Zhang, Yuchen., and Hang. Li, "AGILE: A
              Novel Reinforcement Learning Framework of LLM Agents",
              Advances in Neural Information Processing Systems 2024,
              2024.

   [buban2025encrypted]
              Buban, James., Zhang, Hongyang., Angione, Claudio., Yang,
              Harry., Farhan, Ahmad., Sultanov, Seyfal., Du, Michael.,
              Ma, Xuran., Wang, Zihao., Zhao, Yue., and others,
              "Encrypted Large Model Inference: The Equivariant
              Encryption Paradigm", arXiv preprint
              arXiv:2502.01013 2025, 2025.

Authors' Addresses

   Zhiyuan Liang (editor)
   China Telecom Research Institute



Liang, et al.             Expires 12 April 2026                [Page 21]

Internet-Draft              Abbreviated Title               October 2025


   Email: liangzy17@chinatelecom.cn


   Enfang Cui
   China Telecom Research Institute
   Email: cuief@chinatelecom.cn


   Yujun Cheng
   University of Science and Technology Beijing
   Email: yjcheng@tsinghua.edu.cn








































Liang, et al.             Expires 12 April 2026                [Page 22]


