# 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: []
tags: []
fetched_at: 2026-03-04T00:00:04.663385+00:00
source: ietf
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/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.669884+00:00
source: ietf
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]


name: draft-nandakumar-agent-sd-jwt
rev: 02
title: SD Agent: Selective Disclosure for Agent Discovery and Identity Management
time: 2026-03-02T20:53:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T20:53:04Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.673825+00:00
source: ietf
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


  WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsInNraWxscyIsW3siaWQiOiJyb3V0ZS1vcHRp
  bWl6ZXItdHJhZmZpYyIsIm5hbWUiOiJUcmFmZmljLUF3YXJlIFJvdXRlIE9wdGltaXplciIs
  ImRlc2NyaXB0aW9uIjoiQ2FsY3VsYXRlcyBvcHRpbWFsIGRyaXZpbmcgcm91dGUgYmV0d2Vl
  biBsb2NhdGlvbnMgd2l0aCByZWFsLXRpbWUgdHJhZmZpYyIsInRhZ3MiOlsibWFwcyIsInJv
  dXRpbmciLCJuYXZpZ2F0aW9uIiwiZGlyZWN0aW9ucyIsInRyYWZmaWMiXSwiZXhhbXBsZXMi
  OlsiUGxhbiBhIHJvdXRlIGZyb20gJzE2MDAgQW1waGl0aGVhdHJlIFBhcmt3YXksIE1vdW50
  YWluIFZpZXcsIENBJyB0byAnU2FuIEZyYW5jaXNjbyBJbnRlcm5hdGlvbmFsIEFpcnBvcnQn
  IGF2b2lkaW5nIHRvbGxzLiIsIntcIm9yaWdpblwiOiB7XCJsYXRcIjogMzcuNDIyLCBcImxu
  Z1wiOiAtMTIyLjA4NH0sIFwiZGVzdGluYXRpb25cIjoge1wibGF0XCI6IDM3Ljc3NDksIFwi
  bG5nXCI6IC0xMjIuNDE5NH0sIFwicHJlZmVyZW5jZXNcIjogW1wiYXZvaWRfZmVycmllc1wi
  XX0iXSwiaW5wdXRNb2RlcyI6WyJhcHBsaWNhdGlvbi9qc29uIiwidGV4dC9wbGFpbiJdLCJv
  dXRwdXRNb2RlcyI6WyJhcHBsaWNhdGlvbi9qc29uIiwiYXBwbGljYXRpb24vdm5kLmdlbytq
  c29uIiwidGV4dC9odG1sIl19LHsiaWQiOiJjdXN0b20tbWFwLWdlbmVyYXRvciIsIm5hbWUi
  OiJQZXJzb25hbGl6ZWQgTWFwIEdlbmVyYXRvciIsImRlc2NyaXB0aW9uIjoiQ3JlYXRlcyBj
  dXN0b20gbWFwIGltYWdlcyBiYXNlZCBvbiB1c2VyLWRlZmluZWQgcG9pbnRzIG9mIGludGVy
  ZXN0IiwidGFncyI6WyJtYXBzIiwiY3VzdG9taXphdGlvbiIsInZpc3VhbGl6YXRpb24iLCJj
  YXJ0b2dyYXBoeSJdLCJleGFtcGxlcyI6WyJHZW5lcmF0ZSBhIG1hcCBvZiBteSB1cGNvbWlu
  ZyByb2FkIHRyaXAgd2l0aCBhbGwgcGxhbm5lZCBzdG9wcyBoaWdobGlnaHRlZC4iLCJTaG93
  IG1lIGEgbWFwIHZpc3VhbGl6aW5nIGFsbCBjb2ZmZWUgc2hvcHMgd2l0aGluIGEgMS1taWxl
  IHJhZGl1cyBvZiBteSBjdXJyZW50IGxvY2F0aW9uLiJdLCJpbnB1dE1vZGVzIjpbImFwcGxp
  Y2F0aW9uL2pzb24iXSwib3V0cHV0TW9kZXMiOlsiaW1hZ2UvcG5nIiwiaW1hZ2UvanBlZyIs
  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:

  WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImFkZGl0aW9uYWxJbnRlcmZhY2VzIixbeyJ1cmwiOiJodHRwczovL2dlb3JvdXRlLWFnZW50LmV4YW1wbGUuY29tL2EyYS92MSIsInRyYW5zcG9ydCI6IkpTT05SUEMifSx7InVybCI6Imh0dHBzOi8vZ2Vvcm91dGUtYWdlbnQuZXhhbXBsZS5jb20vYTJhL2dycGMiLCJ0cmFuc3BvcnQiOiJHUlBDIn0seyJ1cmwiOiJodHRwczovL2dlb3JvdXRlLWFnZW50LmV4YW1wbGUuY29tL2EyYS9qc29uIiwidHJhbnNwb3J0IjoiSFRUUCtKU09OIn1dXQ

     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:

  WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImNhcGFiaWxpdGllcyIseyJzdHJlYW1pbmciOnRydWUsInB1c2hOb3RpZmljYXRpb25zIjp0cnVlLCJzdGF0ZVRyYW5zaXRpb25IaXN0b3J5IjpmYWxzZSwiZXh0ZW5zaW9ucyI6W3sibmFtZSI6ImFkdmFuY2VkLXJvdXRpbmciLCJ2ZXJzaW9uIjoiMS4wIiwiZGVzY3JpcHRpb24iOiJFbmhhbmNlZCByb3V0ZSBvcHRpbWl6YXRpb24gd2l0aCBtYWNoaW5lIGxlYXJuaW5nIn1dfV0

     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:

  WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsInNlY3VyaXR5U2NoZW1lcyIseyJnb29nbGUiOnsidHlwZSI6Im9wZW5JZENvbm5lY3QiLCJvcGVuSWRDb25uZWN0VXJsIjoiaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9uIn0sImFwaUtleSI6eyJ0eXBlIjoiYXBpS2V5IiwibmFtZSI6IlgtQVBJLUtleSIsImluIjoiaGVhZGVyIn19XQ

     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:

  {
    "agent_card": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3JlZ2lzdHJ5LmV4YW1wbGUuY29tIiwic3ViIjoiYWdlbnQ6YWktYXNzaXN0YW50LXYyIiwiaWF0IjoxNzA0MDYzNjAwLCJleHAiOjE3MzU2ODU5OTksInZjdCI6InVybjppZXRmOnBhcmFtczpvYXV0aDp0b2tlbi10eXBlOnNkLWEyYS1hZ2VudC1jYXJkIiwiX3NkX2FsZyI6InNoYS0yNTYiLCJfc2QiOltdLCJuYW1lIjoiQUkgQXNzaXN0YW50IEFnZW50IiwiZGVzY3JpcHRpb24iOiJHZW5lcmFsIHB1cnBvc2UgQUkgYXNzaXN0YW50IiwidmVyc2lvbiI6IjIuMS4wIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTGlsRGxzN3ZDZUdlbWMiLCJ5IjoiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0.signature~WyJzYWx0MSIsInNraWxscyIsW3sibmFtZSI6InRleHQtZ2VuZXJhdGlvbiJ9XV0~WyJzYWx0MiIsImVuZHBvaW50cyIsW3sibmFtZSI6InByaW1hcnkifV1d~eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.eyJpYXQiOjE3MDQwNjM2MDAsImF1ZCI6aWNsaWVudC5leGFtcGxlLmNvbSIsInNkX2hhc2giOiJLdDdRcU5aQnpxbkpLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSIsImludGVyYWN0aW9uX2lkIjoiMTIzNDU2NzgtMTIzNC0xMjM0LTEyMzQtMTIzNDU2Nzg5YWJjIn0.kb_signature"
  }

  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:

  WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsInNraWxscyIsW3siaWQiOiJyb3V0ZS1vcHRpbWl6ZXItdHJhZmZpYyIsIm5hbWUiOiJUcmFmZmljLUF3YXJlIFJvdXRlIE9wdGltaXplciIsImRlc2NyaXB0aW9uIjoiQ2FsY3VsYXRlcyB0aGUgb3B0aW1hbCBkcml2aW5nIHJvdXRlIGJldHdlZW4gdHdvIG9yIG1vcmUgbG9jYXRpb25zIiwidGFncyI6WyJtYXBzIiwicm91dGluZyIsIm5hdmlnYXRpb24iLCJkaXJlY3Rpb25zIiwidHJhZmZpYyJdLCJleGFtcGxlcyI6WyJQbGFuIGEgcm91dGUgZnJvbSAnMTYwMCBBbXBoaXRoZWF0cmUgUGFya3dheSwgTW91bnRhaW4gVmlldywgQ0EnIHRvICdTYW4gRnJhbmNpc2NvIEludGVybmF0aW9uYWwgQWlycG9ydCcgYXZvaWRpbmcgdG9sbHMuIl0sImlucHV0TW9kZXMiOlsiYXBwbGljYXRpb24vanNvbiIsInRleHQvcGxhaW4iXSwib3V0cHV0TW9kZXMiOlsiYXBwbGljYXRpb24vanNvbiIsImFwcGxpY2F0aW9uL3ZuZC5nZW8ranNvbiIsInRleHQvaHRtbCJdfSx7ImlkIjoiY3VzdG9tLW1hcC1nZW5lcmF0b3IiLCJuYW1lIjoiUGVyc29uYWxpemVkIE1hcCBHZW5lcmF0b3IiLCJkZXNjcmlwdGlvbiI6IkNyZWF0ZXMgY3VzdG9tIG1hcCBpbWFnZXMgb3IgaW50ZXJhY3RpdmUgbWFwIHZpZXdzIiwidGFncyI6WyJtYXBzIiwiY3VzdG9taXphdGlvbiIsInZpc3VhbGl6YXRpb24iLCJjYXJ0b2dyYXBoeSJdLCJleGFtcGxlcyI6WyJHZW5lcmF0ZSBhIG1hcCBvZiBteSB1cGNvbWluZyByb2FkIHRyaXAgd2l0aCBhbGwgcGxhbm5lZCBzdG9wcyBoaWdobGlnaHRlZC4iXSwiaW5wdXRNb2RlcyI6WyJhcHBsaWNhdGlvbi9qc29uIl0sIm91dHB1dE1vZGVzIjpbImltYWdlL3BuZyIsImltYWdlL2pwZWciLCJhcHBsaWNhdGlvbi9qc29uIiwidGV4dC9odG1sIl19XV1d

  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):

  eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3JlZ2lzdHJ5LmV4YW1wbGUuY29tIiwic3ViIjoiYWdlbnQ6Z2Vvcm91dGUtcGxhbm5lci12MSIsImlhdCI6MTcwNDA2MzYwMCwiZXhwIjoxNzM1Njg1OTk5LCJ2Y3QiOiJ1cm46aWV0ZjpwYXJhbXM6b2F1dGg6dG9rZW4tdHlwZTpzZC1hZ2VudC1jYXJkIiwiX3NkX2FsZyI6InNoYS0yNTYiLCJfc2QiOlsia1Y3aS1WZ1BLOVI...~WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsInNraWxscyIsW3siaWQiOiJyb3V0ZS1vcHRpbWl6ZXItdHJhZmZpYyIsIm5hbWUiOiJUcmFmZmljLUF3YXJlIFJvdXRlIE9wdGltaXplciIsImRlc2NyaXB0aW9uIjoiQ2FsY3VsYXRlcyB0aGUgb3B0aW1hbCBkcml2aW5nIHJvdXRlIGJldHdlZW4gdHdvIG9yIG1vcmUgbG9jYXRpb25zIiwidGFncyI6WyJtYXBzIiwicm91dGluZyIsIm5hdmlnYXRpb24iLCJkaXJlY3Rpb25zIiwidHJhZmZpYyJdLCJleGFtcGxlcyI6WyJQbGFuIGEgcm91dGUgZnJvbSAnMTYwMCBBbXBoaXRoZWF0cmUgUGFya3dheSwgTW91bnRhaW4gVmlldywgQ0EnIHRvICdTYW4gRnJhbmNpc2NvIEludGVybmF0aW9uYWwgQWlycG9ydCcgYXZvaWRpbmcgdG9sbHMuIl0sImlucHV0TW9kZXMiOlsiYXBwbGljYXRpb24vanNvbiIsInRleHQvcGxhaW4iXSwib3V0cHV0TW9kZXMiOlsiYXBwbGljYXRpb24vanNvbiIsImFwcGxpY2F0aW9uL3ZuZC5nZW8ranNvbiIsInRleHQvaHRtbCJdfSx7ImlkIjoiY3VzdG9tLW1hcC1nZW5lcmF0b3IiLCJuYW1lIjoiUGVyc29uYWxpemVkIE1hcCBHZW5lcmF0b3IiLCJkZXNjcmlwdGlvbiI6IkNyZWF0ZXMgY3VzdG9tIG1hcCBpbWFnZXMgb3IgaW50ZXJhY3RpdmUgbWFwIHZpZXdzIiwidGFncyI6WyJtYXBzIiwiY3VzdG9taXphdGlvbiIsInZpc3VhbGl6YXRpb24iLCJjYXJ0b2dyYXBoeSJdLCJleGFtcGxlcyI6WyJHZW5lcmF0ZSBhIG1hcCBvZiBteSB1cGNvbWluZyByb2FkIHRyaXAgd2l0aCBhbGwgcGxhbm5lZCBzdG9wcyBoaWdobGlnaHRlZC4iXSwiaW5wdXRNb2RlcyI6WyJhcHBsaWNhdGlvbi9qc29uIl0sIm91dHB1dE1vZGVzIjpbImltYWdlL3BuZyIsImltYWdlL2pwZWciLCJhcHBsaWNhdGlvbi9qc29uIiwidGV4dC9odG1sIl19XV1d~WyJfM3NkZjhtTi0ycDl1WDdMM3ZFOG5HciIsImFkZGl0aW9uYWxJbnRlcmZhY2VzIixbeyJ1cmwiOiJodHRwczovL2dlb3JvdXRlLWFnZW50LmV4YW1wbGUuY29tL2EyYS92MSIsInRyYW5zcG9ydCI6IkpTT05SUEMifSx7InVybCI6Imh0dHBzOi8vZ2Vvcm91dGUtYWdlbnQuZXhhbXBsZS5jb20vYTJhL2dycGMiLCJ0cmFuc3BvcnQiOiJHUlBDIn0seyJ1cmwiOiJodHRwczovL2dlb3JvdXRlLWFnZW50LmV4YW1wbGUuY29tL2EyYS9qc29uIiwidHJhbnNwb3J0IjoiSFRUUCtKU09OIn1dXQ~WyJfN2tSdDJxVy01bVg5ak40Y0Y3elBzIiwicHJvdmlkZXIiLHsib3JnYW5pemF0aW9uIjoiRXhhbXBsZSBHZW8gU2VydmljZXMgSW5jLiIsInVybCI6Imh0dHBzOi8vd3d3LmV4YW1wbGVnZW9zZXJ2aWNlcy5jb20ifV1

  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]


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/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.678081+00:00
source: ietf
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]


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: []
tags: []
fetched_at: 2026-03-04T00:00:04.683981+00:00
source: ietf
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-03-03T16:18: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: []
tags: []
fetched_at: 2026-03-04T00:00:04.687190+00:00
source: ietf
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/108/", "/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/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.701224+00:00
source: ietf
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]


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: []
tags: []
fetched_at: 2026-03-04T00:00:04.704901+00:00
source: ietf
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: 01
title: Motivations and Problem Statement of Agentic AI for network management
time: 2026-03-02T07:08:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T07:08:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.966293+00:00
source: ietf
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/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.708367+00:00
source: ietf
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: []
tags: []
fetched_at: 2026-03-04T00:00:04.711508+00:00
source: ietf
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]


