# drafts

name: draft-song-oauth-ai-agent-collaborate-authz
rev: 00
title: OAuth2.0 Extension for Multi-AI Agent Collaboration: Applier-On-Behalf-Of Authorization
time: 2025-11-06T03:04:20Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-10T03:04:20Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420486+00:00
abstract:
This draft proposes an authorization method for task-oriented multi-
   AI agent collaboration scenarios, where a leading agent coordinates
   sub-AI agents to complete complex tasks.  The method extends the
   OAuth 2.0 protocol by adding an optional applier_id field, enabling
   the leading agent to apply for access tokens on behalf of other sub-
   AI agents.  This approach greatly simplifies the sub-AI agents'
   authorization process, avoids efficiency loss from repeated
   interactions between multiple sub-AI agents and the authorization
   server, meanwhile maintaining full compatibility with existing OAuth
   2.0 workflows.

full_text:
Web Authorization Protocol                                       Y. Song
Internet-Draft                                                     L. Li
Intended status: Experimental                                     Huawei
Expires: 9 May 2026                                               F. Liu
                                                        Huawei Singapore
                                                         5 November 2025


OAuth2.0 Extension for Multi-AI Agent Collaboration: Applier-On-Behalf-
                            Of Authorization
             draft-song-oauth-ai-agent-collaborate-authz-00

Abstract

   This draft proposes an authorization method for task-oriented multi-
   AI agent collaboration scenarios, where a leading agent coordinates
   sub-AI agents to complete complex tasks.  The method extends the
   OAuth 2.0 protocol by adding an optional applier_id field, enabling
   the leading agent to apply for access tokens on behalf of other sub-
   AI agents.  This approach greatly simplifies the sub-AI agents'
   authorization process, avoids efficiency loss from repeated
   interactions between multiple sub-AI agents and the authorization
   server, meanwhile maintaining full compatibility with existing OAuth
   2.0 workflows.

Requirements Language

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 9 May 2026.




Song, et al.               Expires 9 May 2026                   [Page 1]

Internet-Draft              Abbreviated-Title              November 2025


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Extention of Protocol Flow  . . . . . . . . . . . . . . . . .   3
     3.1.  Extension for Client Registration . . . . . . . . . . . .   4
     3.2.  Authorization Request & Response  . . . . . . . . . . . .   4
     3.3.  Access Token Request & Response . . . . . . . . . . . . .   5
     3.4.  Access Token Transmit . . . . . . . . . . . . . . . . . .   6
     3.5.  Access Token Verify . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  References  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.3.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   AI agents are capable of handling tasks.  They can integrate multiple
   technologies such as natural language understanding, data analysis,
   and logical reasoning to meet multi-step and cross-scenario
   requirements.  However, a single AI agent has a limited knowledge
   scope and restricted functions, making it difficult to independently
   complete complex tasks that span multiple professional domains and
   require different capabilities.

   Collaboration among a group of AI agents is an essential approach for
   such complex tasks.  Taking the demand for "real-time health advice"
   as an example, this intent can be split into three tasks: "collect
   the user's health data", "predict the user's health status" and
   "provide health advice based on health status".  These tasks need to
   be accomplished by corresponding professional sub-AI agents: the data
   collection agent is responsible for privacy-compliant data



Song, et al.               Expires 9 May 2026                   [Page 2]

Internet-Draft              Abbreviated-Title              November 2025


   collection, the health status prediction agent invokes medical models
   for analysis, and the advice generation agent outputs solutions based
   on health guidelines.

   What's more, accordingto some existing
   research[multi-agent-research-system], a leading agent is necessary
   for coordination.  In the above example, the leading agent can
   receive the intent "give me real-time health advice" from user,
   understand it and split it into tasks.  Additionally, the leading
   agent can distribute these tasks to sub-AI agents.  Finally, the
   leading agent can integrate the results of sub-AI agents to form a
   complete health advice.  Without the leading agent, tasks are prone
   to confusion and results are difficult to integrate.

   In this collaborative scenario, if each sub-AI agent applies for
   permissions from the authorization server separately, the
   authorization server needs to verify the identity of each sub-AI
   agent one by one and generate access tokens for them.  This will lead
   to problems such as frequent interactions, high computing resource
   consumption of the authorization server and low efficiency of the
   token issuance process.

   Therefore, this draft puts forward an authorization method: configure
   "task scheduling" and "result integration" rights for the leading
   agent, and let the leading agent interface with the authorization
   server centrally.  This method can greatly simplify the authorization
   process of sub-AI agents and avoid efficiency loss caused by repeated
   interactions.

2.  Terminology

   Applier: a role that request the access token on be half of
   client(s), e.g. a leading AI agent.

   This draft uses the terms "authorization server", "client", "resource
   server" defined by OAuth 2.0 [RFC6749]

3.  Extention of Protocol Flow

   This protocol flow is modeled after [RFC6749] and extends it with a
   *applier_id* field to enable authorization request by the applier.










Song, et al.               Expires 9 May 2026                   [Page 3]

Internet-Draft              Abbreviated-Title              November 2025


   u
       +--------+                              +----------------+
       |        |--(A) Authorization Request-->|    Resource    |
       |        |                              |      Owner     |
       |        |<--(B) Authorization Grant----|                |
       |        |                              +----------------+
       |Applier |
       |        |   (C) Authorization Grant    +----------------+
       |        |--------(applier_id)--------->|                |
       |        |                              | Authorization  |
       |        |      (D) Access Token        |    Server      |
       |        |<------(app=applier_id)-------|                |
       +--------+                              +----------------+
           |
           |
   (E) Access Token*
           |
           v
       +--------+                              +----------------+
       |        |-------(F) Access Token*----->|    Resource    |
       | Client |                              |     Server     |
       |        |<---(G) Protected Resource----|                |
       +--------+                              +----------------+

3.1.  Extension for Client Registration

   Before initiating the protocol, the applier registers with the
   authorization server, as defined in [RFC6749].

   In this draft, the applier's role or capability is incorporated into
   its registration process.  For example, the applier's profile
   includes a "capability" parameter with the value "resolve intent and
   distribute tasks".

3.2.  Authorization Request & Response

   This section refers to step (A) and (B).

   The applier receives a requirement from the user, resolves it and
   determines the task(s) and client(s) needed to fulfill the
   requirement.  For example, when the user sends the intent "give me
   real-time health advice" to the leading AI agent, the leading AI
   agent resolves this intent and identifies three tasks: task 1
   (collect the user's health data), task 2 (predict the user's health
   status) and task 3 (provide health advice based on health status).
   The leading agent then utilizes the agent discovery process to select
   sub-AI agent(s) capable of performing the respective tasks.  For
   instance, task 1 assigned to sub-AI agent 1, task 2 to sub-AI agent



Song, et al.               Expires 9 May 2026                   [Page 4]

Internet-Draft              Abbreviated-Title              November 2025


   2, and task 3 to sub-AI agent 3.  In the subsequent authorization
   process proposed in this draft, the leading AI agent is designated as
   the applier, and the selected sub-AI agent(s) are designated as the
   client(s).

   The applier requests authorization from the resource owner, as
   defined in [RFC6749].

3.3.  Access Token Request & Response

   This section refers to step (C) and D).

   The applier requests an access token by authenticating with the
   authorization server and presenting the authorization grant, as
   defined in [RFC6749].  The message may also include the following
   parameter:

   applier_id

      OPTIONAL.  The identifier of the applier which is requesting
      access token on be half of the client(s).

   The authorization server authenticates the applier and validates that
   the applier is capable of requesting access tokens on behalf of
   client(s).  For example, it checks whether the applier's profile
   includes a "capability" parameter whose value includes "distribute
   tasks".

   If the validation is successful, the authorization server may verify
   grants as defined in [RFC6749].  Then the authorization server
   generates access token and send access token response message to the
   applier.  The access token is similar to OAuth2.0, except that it
   consists of an additional claim to specify the applier.

   app

      OPTIONAL.  The identifier of the applier which is requesting
      access token on be half of the client(s).

   The access token includes one *app* parameter and multiple
   *sbj*-*aud*-*scope* pairs.  Below is an example:

      {

      "iss": "authorization server ID",

         "app": "leading agent ID",




Song, et al.               Expires 9 May 2026                   [Page 5]

Internet-Draft              Abbreviated-Title              November 2025


         "sbj": "sub AI agent1 ID",

         "aud": "resource server 1 ID",

         "sbj": "sub AI agent 2 ID",

         "aud": "resource server 1 ID", "resource server 2 ID",

         "sbj": "sub AI agent 3 ID",

         "aud": "resource server 2 ID", "resource server 3 ID"

         ...

      }

   If the validation fails, the access token response message may
   include the reason for failure.  [RFC6749] has defined types of error
   response.  In this case, the authorization server may use a new error
   message "unauthorized_applier" to indicate that the applier is not
   capable of requesting access tokens on be half of client(s).

3.4.  Access Token Transmit

   This section refers to step (E).

   The applier sends the task ID and access token* to the client(s).
   Based on local policies and regulations, the applier may use privacy
   protection mechanisms to process the access token.  Thus, the access
   token* may be the same as the access token, or generated from the
   access token using privacy protection mechanisms.  For example, the
   applier uses a selective disclosure algorithm to generate access
   token 1, access token 2, and access token 3 from the access token
   received in step (D).  Access token 1 may include the leading agent
   ID and sub-AI agent 1 ID; access token2 may include the leading agent
   ID and sub-AI agent 2 ID; access token3 may include the leading agent
   ID and sub-AI agent 3 ID.  The applier may then send access token 1
   to sub-AI agent 1, access token 2 to sub-AI agent 2, and access token
   3 to sub-AI agent 3.

   The client(s) validate the proof of the received access token* and
   check whether the applier ID refers to a trustworthy applier.  For
   example, each AI agent is preconfigured with a list of trusted AI
   agents, and any one of the trusted AI agents that acts as a leading
   agent will pass the validation.

   If the validation fails, the client(s) may send a response message to
   the applier with a failure indication of "unknown_applier".



Song, et al.               Expires 9 May 2026                   [Page 6]

Internet-Draft              Abbreviated-Title              November 2025


3.5.  Access Token Verify

   This section refers to step (F) and (G).

   The client(s) execute the task according to message received in step
   (E).  When resources are needed, the client(s) request the protected
   resource from the resource server and present the access token*, as
   defined in [RFC6749].  The resource server validates the access
   token*, as defined in [RFC6749].  If the access token* includes
   multiple *sbj*-*aud* pairs, the resource server may verify that its
   own ID and the client's ID are in the same pair.  In previous example
   of the access token, "sub-AI agent 1 ID"and "resource server 1 ID"
   are in the same pair.

   If the validation succeeds, the resource server may provide the
   resource to the client(s).

4.  Security Considerations

   TBD

5.  References

5.1.  References

5.2.  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, Dick., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

5.3.  Informative References

   [multi-agent-research-system]
              Anthropic, "How we built our multi-agent research system",
              13 June 2025.

Authors' Addresses

   Yurong Song
   Huawei
   Email: songyurong1@huawei.com




Song, et al.               Expires 9 May 2026                   [Page 7]

Internet-Draft              Abbreviated-Title              November 2025


   Lun Li
   Huawei
   Email: lilun20@huawei.com


   Faye Liu
   Huawei Singapore
   Email: liufei19@huawei.com











































Song, et al.               Expires 9 May 2026                   [Page 8]


name: draft-pang-agents-networking-scenarios
rev: 00
title: Agents Networking Scenarios in Enterprise and Broadband Networks
time: 2025-11-06T08:47:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-10T08:47:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:03.420488+00:00
abstract:
This document describes agents networking scenarios in enterprise and
   home broadband networks.  These scenarios differ from mobile networks
   and Internet scenarios.  Since the agentic service is still at the
   emerging stage, especially in enterprise and home broadband networks,
   the scenarios are mostly based on reasonable assumptions.

full_text:
network working group                                            R. Pang
Internet-Draft                                                    M. Han
Intended status: Informational                              China Unicom
Expires: 10 May 2026                                              B. Liu
                                                                L. Zhang
                                                                  Q. Gao
                                                                 N. Geng
                                                                X. Shang
                                                                   Z. Li
                                                     Huawei Technologies
                                                         6 November 2025


    Agents Networking Scenarios in Enterprise and Broadband Networks
               draft-pang-agents-networking-scenarios-00

Abstract

   This document describes agents networking scenarios in enterprise and
   home broadband networks.  These scenarios differ from mobile networks
   and Internet scenarios.  Since the agentic service is still at the
   emerging stage, especially in enterprise and home broadband networks,
   the scenarios are mostly based on reasonable assumptions.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 10 May 2026.

Copyright Notice

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






Pang, et al.               Expires 10 May 2026                  [Page 1]

Internet-Draft         Agents Networking Scenarios         November 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Enterprise Scenarios  . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Smart Office  . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Agentic Digitalization  . . . . . . . . . . . . . . . . .   4
     2.3.  Industrial Automation . . . . . . . . . . . . . . . . . .   4
   3.  Home Broadband Network Scenarios  . . . . . . . . . . . . . .   5
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   6
     5.1.  Limited domain Deployment . . . . . . . . . . . . . . . .   6
     5.2.  Public domain Deployment  . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   With the rapid development of artificial intelligence, single-agent
   systems have gradually revealed their limitations in handling
   complex, multi-tasking, and cross-domain scenarios.  Agent
   networking, as a core paradigm for breaking through individual
   capabilities and achieving collective intelligence, has become a key
   trend in the future development of agents.

   This document describes agents networking scenarios in enterprise and
   home broadband networks.

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.





Pang, et al.               Expires 10 May 2026                  [Page 2]

Internet-Draft         Agents Networking Scenarios         November 2025


2.  Enterprise Scenarios

   The AI Agent is progressively becoming the key technological unit
   supporting both internal enterprise process automation and cross-
   enterprise ecosystem collaboration.  The AI agent communication in
   enterprise scenarios include the following three types: - Via
   Internal Network: AI agents within the enterprise are interconnected
   to perform tasks via the enterprise internal network. - Via
   Interconnected Network: AI agents deployed across multiple branch of
   enterprise, which collaborate through private line. - Via Internet
   Network: AI agent within enterprise access Internet to collaborate
   with the external AI agents.

2.1.  Smart Office

   In the smart office scenario, AI Agents enhance daily productivity
   and collaboration.

   Agent Collaboration:

   *  Personal Assistant Coordination: A user's personal AI Agent
      (residing on a mobile device or PC) coordinates with other
      specialized Agents, such as the Meeting Room Agent, IT Service
      Agent etc.. This collaboration facilitates automated task
      execution, including scheduling meetings, reserving room
      resources, preparing necessary documents, and initiating video
      conference sessions.

   *  Team Task Alignment: Multiple project-related Agents, representing
      different team members or functions, engage in real-time data
      sharing, automatic summarization of meeting minutes, dynamic task
      prioritization, and collaborative document editing.

   *  Remote Work: In remote work scenarios, efficient telecommuting is
      achieved through the collaboration between terminal AI agents
      (such as mobile phones and laptops) and office equipment AI agents
      (including cloud desktops, printers, video conferencing terminals,
      and file-sharing servers).  The participating roles are employees
      who operate terminal AI agents, terminal AI agents responsible for
      sending and receiving instructions, and office equipment AI agents
      that execute tasks.

   Networking and Communication Requirements:

   *  Low Latency and High Reliability: Crucial for seamless video
      conferencing and real-time collaborative applications.





Pang, et al.               Expires 10 May 2026                  [Page 3]

Internet-Draft         Agents Networking Scenarios         November 2025


   *  Data Privacy and Security: By deploying gateways or other
      technologies to intercept private data, the security of enterprise
      data is ensured.  Technologies such as encryption are used to
      enhance the safety of data during network transmission.

   *  Secure Authentication and Authorization: To ensure Agent actions
      are strictly compliant with the authorized scope granted by the
      human user or project manager.

2.2.  Agentic Digitalization

   This scenario focuses on automating and optimizing business processes
   using autonomous Agents.

   Agent Collaboration:

   *  Business Workflow Automation: A Process Management Agent
      collaborates with various Business System Agents (e.g., CRM Agent,
      ERP Agent).  It autonomously translates high-level business
      intents (e.g., "maximize customer retention") into executable
      plans, decomposes the overall task, and executes complex workflows
      across disparate business systems by invoking their respective
      Agents.

   *  Data-Driven Decision Making: Data Collection Agents aggregate
      information from various sources, feeding it to Data Analysis
      Agents.  The resulting insights guide Decision Agents, which
      autonomously take prescribed actions, such as dynamically
      adjusting cloud resource allocations.

   Networking and Communication Requirements:

   *  Heterogeneous Interoperability: Agent communication protocols must
      be designed to bridge communication gaps between legacy IT system
      APIs and modern AI Agent platforms.

   *  High Concurrency and Scalability: The network infrastructure must
      be capable of supporting numerous Agents engaged in frequent,
      complex, and high-volume interactions across the enterprise.

2.3.  Industrial Automation

   This scenario applies Agents to the operational domain, demanding
   strict performance guarantees.

   Agent Collaboration:





Pang, et al.               Expires 10 May 2026                  [Page 4]

Internet-Draft         Agents Networking Scenarios         November 2025


   *  High Efficient Producing: On the production floor, Sensors,
      Robots, Controllers agent collaborate to continuously monitor
      environmental variables and production status.  This tight
      collaboration allows for dynamic optimization of manufacturing
      processes, maximizing efficiency and minimizing downtime.

   *  High Quality Producing: Remote Diagnostics Agents collaborate with
      local Equipment Agents to transmit high-definition video feeds and
      machine logs.  This enables sophisticated remote fault diagnosis
      and highly accurate predictive maintenance operations.

   *  Intelligent Warehousing:Intelligent warehousing refers to
      automating and intelligently managing warehouse operations.  In
      this scenario, the AI agents collaborate to predict, plan,
      schedule, and optimize warehouse operations, thereby enhancing
      efficiency and safety.

   Networking and Communication Requirements:

   *  Ultra-Low Latency and Jitter: Critical control loops require
      communication that adheres to industrial-grade standards,
      specifically Ultra-Reliable Low-Latency Communication.

   *  Deterministic Networking (DetNet): The underlying network may need
      to incorporate DetNet technologies to guarantee bounded and
      predictable latency for communications among critical control
      Agents.

   *  Data Privacy and Security: Achieve the isolation of production
      data and operational data to ensure that critical data does not
      leave the domain.

   *  OT/IT Convergence: A key requirement is defining how Agents can
      securely and reliably communicate with gateway functions
      connecting the Operational Technology (OT) domain to the
      Information Technology (IT) domain.

3.  Home Broadband Network Scenarios

   The home network scenario is characterized by user experience
   optimization and device collaboration.

   Agent Collaboration:








Pang, et al.               Expires 10 May 2026                  [Page 5]

Internet-Draft         Agents Networking Scenarios         November 2025


   *  Home Security: When remotely printing documents for children while
      away from home, users can activate the home printer via their
      smartphone.  During routine monitoring by the home camera,
      abnormal pet activity will trigger alerts pushed to the user's
      smartphone.

   *  User Experience Guarantee: The Home Gateway (e.g., on the home
      router/ONT, or on the BNG) collaborates with Terminal Agents
      (e.g., on gaming consoles, smart TVs) to classify traffic.  This
      allows the Gateway to dynamically prioritize and allocate
      bandwidth to latency/bandwidth-sensitive applications (like online
      gaming or 4K streaming), ensuring a consistently high Quality of
      Experience (QoE).

   Networking and Communication Requirements:

   *  Lightweight and Efficient Protocols: Given the variety of
      resource-constrained consumer devices, the Agent communication
      protocol must be designed to be lightweight and computationally
      efficient.

   *  Mobility Management: The network architecture must provide
      mechanisms to maintain session persistence and support seamless
      handover for Agents when a user transitions between the home Wi-Fi
      network and a mobile cellular network.

4.  Operational Considerations

   There are two primary operational paradigms in varying enterprise
   requirements: - Enterprises build their own local networks and also
   lease operator private lines. - Operators provide both managed
   network services and private lines for Enterprises.

   Home broadband services may not involve operational considerations.

5.  Deployment Considerations

5.1.  Limited domain Deployment

   This model emphasizes security, performance, and control, typically
   favored by large enterprises, industrial environments (Smart
   Manufacturing), or highly security-conscious users.

   *  Isolated Infrastructure: All core AI Agent components, including
      the Large Language Model (LLM) inference engines, Agent
      orchestrators, Agent naming/discovery services, etc., are deployed
      entirely within the private network domain (e.g., enterprise LAN
      or private network).



Pang, et al.               Expires 10 May 2026                  [Page 6]

Internet-Draft         Agents Networking Scenarios         November 2025


   *  Data Sovereignty: No Agent communication data, task context, or
      locally sensitive information leaves the private network.  This is
      essential for scenarios involving proprietary data or compliance
      with strict regulatory requirements.

   *  On-Premises Compute Resources: Requires substantial dedicated
      compute and storage resources (e.g., GPUs for inference) within
      the private domain, which must be connected via high-speed
      interfaces.

   *  Controlled Network Egress: Strict policies are applied to prevent
      Agents from accessing unauthorized external services, minimizing
      the external attack surface.  The network needs mechanisms for
      precise monitoring of all egress traffic initiated by Agents.

5.2.  Public domain Deployment

   This model prioritizes cost-efficiency, and leverages existing cloud
   and public infrastructure, often seen in home networks (Home
   Broadband) and smaller Smart Office setups.

   *  Hybrid Architecture: The core intelligence (e.g., the LLM) and
      central coordination services (e.g., Agent discovery) are
      typically hosted in a public or operator cloud environment.  Local
      Agents (e.g., device Agents, edge Agents on the home gateway)
      handle sensing, local actuation, and interface with the cloud-
      based central Agent.

   *  Tool/API Delegation: Cloud-based Agents often delegate local tasks
      by invoking APIs exposed by local Agents, or by sending compressed
      instructions to the edge device.

   *  Cost Optimization: This model reduces the need for comprehensive
      system that combined by various components, but rather, some
      integrated model of providing the service (e.g. through an Agent
      Gateway).

6.  Security Considerations

   TBD

7.  IANA Considerations

   This document has no IANA actions.

8.  Normative References





Pang, et al.               Expires 10 May 2026                  [Page 7]

Internet-Draft         Agents Networking Scenarios         November 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>.

Authors' Addresses

   Ran Pang
   China Unicom
   No. 9 Shouti South Road
   Beijing
   China
   Email: pangran@chinaunicom.cn


   Mengyao Han
   China Unicom
   No. 9 Shouti South Road
   Beijing
   China
   Email: hanmy12@chinaunicom.cn


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


   Li Zhang
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: zhangli344@huawei.com


   Qiangzhou Gao
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China



Pang, et al.               Expires 10 May 2026                  [Page 8]

Internet-Draft         Agents Networking Scenarios         November 2025


   Email: gaoqiangzhou@huawei.com


   Nan Geng
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: gengnan@huawei.com


   Xiaotong Shang
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: shangxiaotong@huawei.com


   Zhenbin Li
   Huawei Technologies
   Beijing
   China
   Email: robinli314@163.com



























Pang, et al.               Expires 10 May 2026                  [Page 9]


name: draft-han-rtgwg-agent-gateway-intercomm-framework
rev: 01
title: Agent Gateway Intercommunication Framework
time: 2026-01-30T10:00:13Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-03T10:00:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:03.420490+00:00
abstract:
This document defines the framework and requirements for
   intercommunication between Agent Gateways (AGw) in the Agent Internet
   (IoA) ecosystem.  It specifies a hierarchical layered model,
   functional components, protocol requirements and deployment
   consideration for AGw interconnection.  The framework aims to address
   data synchronization, protocol compatibility, and security challenges
   in cross-domain agent collaboration, enabling efficient and scalable
   communication for distributed intelligent agents.  It is compatible
   with existing IoA reference architectures while specializing in
   cross-domain gateway interoperability.

full_text:
RTGWG                                                        Z. Han, Ed.
Internet-Draft                                              Z. Ruan, Ed.
Intended status: Informational                                    M. Han
Expires: 3 August 2026                                      China Unicom
                                                                  J. Yan
                                                         ZTE Corporation
                                                                   T. He
                                                                 R. Pang
                                                            China Unicom
                                                         30 January 2026


               Agent Gateway Intercommunication Framework
          draft-han-rtgwg-agent-gateway-intercomm-framework-01

Abstract

   This document defines the framework and requirements for
   intercommunication between Agent Gateways (AGw) in the Agent Internet
   (IoA) ecosystem.  It specifies a hierarchical layered model,
   functional components, protocol requirements and deployment
   consideration for AGw interconnection.  The framework aims to address
   data synchronization, protocol compatibility, and security challenges
   in cross-domain agent collaboration, enabling efficient and scalable
   communication for distributed intelligent agents.  It is compatible
   with existing IoA reference architectures while specializing in
   cross-domain gateway interoperability.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 3 August 2026.







Han, et al.               Expires 3 August 2026                 [Page 1]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
     2.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Inconsistent Data Synchronization . . . . . . . . . . . .   4
     4.2.  Network Quality Blindness . . . . . . . . . . . . . . . .   4
     4.3.  Protocol Incompatibility  . . . . . . . . . . . . . . . .   4
     4.4.  Security Risks  . . . . . . . . . . . . . . . . . . . . .   5
     4.5.  Scalability Limitations . . . . . . . . . . . . . . . . .   5
   5.  AGw Intercommunication Framework  . . . . . . . . . . . . . .   5
     5.1.  Application Service Layer . . . . . . . . . . . . . . . .   6
     5.2.  Orchestration & Control Layer . . . . . . . . . . . . . .   7
     5.3.  Agent Connectivity Layer  . . . . . . . . . . . . . . . .   7
     5.4.  Network Communication Layer . . . . . . . . . . . . . . .   7
   6.  AGw Functional Components . . . . . . . . . . . . . . . . . .   7
     6.1.  Application Service Layer Components  . . . . . . . . . .   7
     6.2.  Orchestration & Control Layer Components  . . . . . . . .   8
     6.3.  Agent Connectivity Layer Components . . . . . . . . . . .   8
     6.4.  Network Communication Layer Components  . . . . . . . . .   8
   7.  AGw Intercommunication Requirements . . . . . . . . . . . . .   8
   8.  Deployment Considerations . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11




Han, et al.               Expires 3 August 2026                 [Page 2]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


1.  Introduction

   The Agent Internet (IoA) enables collaborative work among massive
   numbers of AI agents deployed across diverse environments.  As the
   core network component in IoA, Agent Gateway (AGw) acts as a
   "connection hub" and "security steward" that bridges intra-domain
   agents and cross-domain networks.  It handles agent registration,
   discovery, protocol translation, and security protection.

   In distributed IoA ecosystems, numerous agents collaboration relies
   heavily on intercommunication between AGws.  For example, an agent in
   a smart park may need to collaborate with a cloud-based payment
   agent, requiring their respective AGws to exchange capability
   information, network status, and task context.  However, existing
   network communication mechanisms lack standardized frameworks for AGw
   interconnection, leading to challenges such as inconsistent data
   synchronization, incompatible protocols, and inadequate network
   quality awareness.

   This document specifies the Agent Gateway Intercommunication
   Framework to address these challenges.  It defines the architectural
   patterns for AGw intercommunication, core content to be transmitted,
   protocol requirements, and target scenarios.  This framework is
   compatible with existing IoA components, providing a layered model
   that addresses AGws specific interconnection challenges while
   enabling secure, efficient, and scalable cross-domain collaboration.

2.  Conventions Used in This Document

2.1.  Abbreviations

2.2.  Requirements Language

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

3.  Terminology

   AGw (Agent Gateway): A network component that acts as a connection
   hub and security steward for agent communication, responsible for
   route management, protocol translation, security protection, and
   traffic control.






Han, et al.               Expires 3 August 2026                 [Page 3]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


   AGw Intercommunication: The process of data exchange and
   collaborative operations between AGws deployed in different domains
   (e.g., different parks, enterprises, or network segments).

   Agent Metadata: Core information about intelligent agents, including
   identity identifier, capabilities, endpoint address, status, and
   supported protocols.

   Network Quality Metrics: Key indicators reflecting cross-AGw
   communication performance, including latency, packet loss rate,
   bandwidth, and jitter.

   Protocol Translation: The function of converting between different
   communication protocols (e.g., HTTP, MQTT, gRPC) and data formats
   (e.g., JSON, Protobuf) to ensure interoperability.

   Cross-Domain Collaboration: Collaborative task execution between
   agents located in different network domains, facilitated by AGw
   intercommunication.

4.  Motivation

   With the proliferation of intelligent agents in various industries,
   cross-domain collaboration has become a key requirement for IoA.  AGw
   intercommunication is critical to enabling this collaboration, but
   current implementations face several challenges as below.  To address
   these challenges, this framework defines standardized
   intercommunication mechanisms that ensure consistent data
   synchronization, network quality awareness, protocol compatibility,
   security, and scalability for AGws in distributed IoA ecosystems.

4.1.  Inconsistent Data Synchronization

   Lack of standardized agent metadata exchange formats leads to
   incomplete or outdated information sharing between AGws, preventing
   accurate agent discovery.

4.2.  Network Quality Blindness

   AGws lack mechanisms to exchange real-time network quality metrics,
   resulting in agents collaborating over suboptimal paths with high
   latency or packet loss.

4.3.  Protocol Incompatibility

   Different AGws may adopt diverse communication protocols, causing
   interconnection failures and hindering cross-domain agent
   interactions.



Han, et al.               Expires 3 August 2026                 [Page 4]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


4.4.  Security Risks

   Cross-domain AGw communication involves sensitive agent identity and
   task data, requiring robust authentication and encryption mechanisms
   that are currently lacking.

4.5.  Scalability Limitations

   Existing point-to-point communication models cannot efficiently
   support large-scale AGw deployments (e.g., hundreds of park AGws),
   leading to performance bottlenecks.

5.  AGw Intercommunication Framework

   The AGw intercommunication framework is structured into four
   hierarchical layers.  This empowers AGws to function dually as
   advanced communication gateways and AI agents with cognitive
   collaborative characteristics.

































Han, et al.               Expires 3 August 2026                 [Page 5]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


                   +-------------------+-------------------+
                   |   APPLICATION SERVICE LAYER           |
                   +---------------------------------------+
                   | * Agent Registry                      |
                   | * Capability Discovery                |
                   | * Identity Manager                    |
                   +-------------------+-------------------+
                                       |
                   +-------------------+-------------------+
                   |   ORCHESTRATION & CONTROL LAYER       |
                   +---------------------------------------+
                   | * Task Decomposer                     |
                   | * Path Orchestrator                   |
                   | * Policy Controller                   |
                   +-------------------+-------------------+
                                       |
                   +-------------------+-------------------+
                   |   AGENT CONNECTIVITY LAYER            |
                   +---------------------------------------+
                   | * Protocol Translator                 |
                   | * Semantic Adapter                    |
                   | * Network Service Abstractor          |
                   +-------------------+-------------------+
                                       |
                   +-------------------+-------------------+
                   |   NETWORK COMMUNICATION LAYER         |
                   +---------------------------------------+
                   | * QoS Enforcer                        |
                   | * SLA Monitor                         |
                   | * Secure Manager                      |
                   +---------------------------------------+
                            layered model of AGw

5.1.  Application Service Layer

   Serves as the "intelligent directory" for the agent ecosystem,
   providing agent registration, capability discovery, identity
   management, and semantic matching between business requirements and
   agent capabilities.

   Interconnection Role: AGws exchange agent metadata including
   capabilities, security levels, response times, and service SLAs
   through application-layer protocols, maintaining a distributed
   directory of available agents across domains.







Han, et al.               Expires 3 August 2026                 [Page 6]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


5.2.  Orchestration & Control Layer

   Provides centralized intelligence for complex task decomposition,
   policy enforcement, path orchestration, and global governance of
   cross-domain agent collaborations.

   Interconnection Role: Analyzes complex task requirements and selects
   optimal agent combinations and network paths based on comprehensive
   factors including security policies, service levels, and network
   conditions.

5.3.  Agent Connectivity Layer

   Acts as the "communication bridge" between heterogeneous agents,
   providing protocol translation, semantic adaptation, and abstraction
   of underlying network capabilities.

   Interconnection Role: Enables seamless communication between agents
   with different technical implementations by performing real-time
   protocol conversion and semantic mediation, while abstracting complex
   network functions into simplified, agent-accessible services.

5.4.  Network Communication Layer

   Provides the foundational connectivity with guaranteed quality of
   service, differentiated SLA enforcement, and reliable data
   transmission between AGws.

   Interconnection Role: Establishes and maintains high-quality
   communication channels between AGws, continuously monitoring network
   metrics (latency, loss, bandwidth) to ensure SLA compliance for agent
   collaborations.

6.  AGw Functional Components

6.1.  Application Service Layer Components

   *  Agent Registry: Maintains a database of registered agents with
      their capabilities, security levels, and service attributes,
      synchronizing this information with peer AGws.

   *  Capability Discovery: Processes semantic queries to match business
      requirements with appropriate agent capabilities across domains.

   *  Identity Manager: Verifies agent identities through integration
      with certificate authorities and manages authentication
      credentials for cross-domain access.




Han, et al.               Expires 3 August 2026                 [Page 7]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


6.2.  Orchestration & Control Layer Components

   *  Task Decomposer: Breaks down complex tasks into executable
      subtasks and identifies required agent capabilities for each step.

   *  Path Orchestrator: Computes optimal agent combinations and network
      paths based on security, service SLA, and network SLA
      requirements.

   *  Policy Controller: Enforces governance policies, security rules,
      and compliance requirements across all cross-domain
      collaborations.  Distributes policy decisions to lower layers and
      audits enforcement results for consistency.

6.3.  Agent Connectivity Layer Components

   *  Protocol Translator: Converts between different agent
      communication protocols and data formats in real-time.

   *  Semantic Adapter: Ensures semantic compatibility between agents
      with different data models and interaction patterns.

   *  Network Service Abstractor: Presents network capabilities as
      callable services that agents can utilize through simplified APIs.

6.4.  Network Communication Layer Components

   *  QoS Enforcer: Implements traffic prioritization, bandwidth
      allocation, and latency management for different classes of agent
      traffic.

   *  SLA Monitor: Continuously measures network performance metrics and
      triggers alerts when SLAs are violated.

   *  Secure Manager: Establishes and maintains encrypted tunnels
      between AGws with mutual authentication.

7.  AGw Intercommunication Requirements

   *  Agent Identity Identification & Discovery: Distinguish agents from
      real users, integrate semantic understanding and addressing to
      match business needs with corresponding agents.

   *  Heterogeneous Compatibility: Different agents vary in resources
      and supported protocols, so adaptation and protocol conversion are
      required for agents communication.





Han, et al.               Expires 3 August 2026                 [Page 8]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


   *  Efficient Agent Communication: For agent interaction, consider
      network reachability, QoS guarantee, and differentiated SLA
      services.  Due to high pressure in peer-to-peer collaboration
      among multiple agents, convergence is needed to enable
      hierarchical communication.

   *  Agent Identifier Parsing: AGws are capable of identifying and
      parsing agent identifier information carried in network-layer
      packets.

   *  Routing Protocol Extensions: AGws support encapsulating and
      transmitting agent information through routing protocol
      extensions, achieving agent information synchronization between
      gateways.  AGws support generating and maintaining agent-level
      routing tables based on global agent information.

   *  Agent Scheduling & Management: Realize agent scheduling within and
      across enterprise campus; unify orchestration of network resources
      and agent services to align network and business.

   *  Security & Privacy: Implement access management and permission
      control to enhance security.

8.  Deployment Considerations

   *  Hierarchical Deployment: For large enterprises or service
      providers, AGws should be deployed at domain edges (e.g., campus
      gateways, cloud VPCs), with regional directory servers at network
      aggregation points.

   *  Redundancy Design: Critical domains SHOULD deploy redundant AGws
      to avoid single points of failure.  Directory services SHOULD be
      deployed in a clustered mode for high availability.

   *  Network Integration: AGws SHOULD be integrated with existing
      network infrastructure (e.g., SDN controllers) and IoA components
      (ACA, ARS) via standard APIs to enable unified orchestration of
      network and agent resources.

   *  Extensibility: The intercommunication protocols and data formats
      SHOULD be designed with extensibility in mind, using versioning
      and optional fields to accommodate future enhancements without
      breaking backward compatibility.

9.  Security Considerations

   This document does not have any specific security considerations.




Han, et al.               Expires 3 August 2026                 [Page 9]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


10.  IANA Considerations

   This document does not have any IANA considerations.

11.  References

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

11.2.  Informative References

   [I-D.zl-agents-networking-framework]
              Zhang, L., Liu, B., Geng, N., Shang, X., Gao, Q., and Z.
              Li, "Agents Networking Framework for Enterprise and
              Broadband", Work in Progress, Internet-Draft, draft-zl-
              agents-networking-framework-00, 2 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-zl-agents-
              networking-framework-00>.

   [I-D.liu-rtgwg-agent-gateway-requirements]
              Liu, B., Geng, N., Shang, X., Gao, Q., Li, Z., and J. Gao,
              "Requirements for Agent Gateway", Work in Progress,
              Internet-Draft, draft-liu-rtgwg-agent-gateway-
              requirements-01, 27 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-liu-rtgwg-
              agent-gateway-requirements-01>.

   [I-D.mzsg-rtgwg-agent-cross-device-comm-framework]
              Mao, J., Zeng, G., Liu, B., Geng, N., Shang, X., Gao, Q.,
              and Z. Li, "Cross-device Communication Framework for AI
              Agents in Network Devices", Work in Progress, Internet-
              Draft, draft-mzsg-rtgwg-agent-cross-device-comm-framework-
              01, 1 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-mzsg-rtgwg-
              agent-cross-device-comm-framework-01>.

   [I-D.zeng-mcp-network-measurement]
              Zeng, G. and J. Mao, "MCP-based Network Measurement
              Framework: Using Model Context Protocol for Intelligent
              Network Measurement", Work in Progress, Internet-Draft,



Han, et al.               Expires 3 August 2026                [Page 10]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


              draft-zeng-mcp-network-measurement-00, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-zeng-mcp-
              network-measurement-00>.

Acknowledgements

   TBD.

Contributors

   TBD.

Authors' Addresses

   Zhengxin Han (editor)
   China Unicom
   Beijing
   China
   Email: hanzx21@chinaunicom.cn


   Zheng Ruan (editor)
   China Unicom
   Beijing
   China
   Email: ruanz6@chinaunicom.cn


   Mengyao Han
   China Unicom
   Beijing
   China
   Email: hanmy12@chinaunicom.cn


   Jinjie Yan
   ZTE Corporation
   China
   Email: yan.jinjie@zte.com.cn


   Tao He
   China Unicom
   Beijing
   China
   Email: het21@chinaunicom.cn





Han, et al.               Expires 3 August 2026                [Page 11]

Internet-Draft      Agent Gateway Intercomm Framework       January 2026


   Ran Pang
   China Unicom
   Beijing
   China
   Email: pangran@chinaunicom.cn














































Han, et al.               Expires 3 August 2026                [Page 12]


name: draft-dhir-http-agent-profile
rev: 00
title: HTTP Agent Profile (HAP): Authenticated and Monetized Agent Traffic on the Web
time: 2025-11-24T21:44:30Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-28T21:44:30Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "ML traffic mgmt", "Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:03.420493+00:00
abstract:
Autonomous agents such as LLM-powered crawlers, browser-integrated
   assistants, and task-oriented bots are rapidly becoming first-class
   HTTP clients on the Web. Today’s infrastructure largely assumes a
   human behind a browser and monetizes content through advertising and
   coarse subscriptions.  Automated agents consume content at scale
   without rendering pages or viewing ads, exacerbating bot-mitigation
   arms races and economic misalignment between content providers and AI
   systems.

   This document describes an HTTP Agent Profile (HAP) that enables: (1)
   cryptographic authentication of agent traffic using HTTP Message
   Signatures; (2) clear separation between human and agent traffic
   using privacy-preserving human tokens; and (3) protocol-level value
   exchange for agents via HTTP status code 402 ("Payment Required") and
   pluggable micropayment mechanisms.  The profile reuses existing HTTP
   features and is designed for incremental deployment via reverse
   proxies, CDNs, and agent libraries.

full_text:
Network Working Group                                            S. Dhir
Internet-Draft                                               Independent
Intended status: Informational                          24 November 2025
Expires: 28 May 2026


 HTTP Agent Profile (HAP): Authenticated and Monetized Agent Traffic on
                                the Web
                    draft-dhir-http-agent-profile-00

Abstract

   Autonomous agents such as LLM-powered crawlers, browser-integrated
   assistants, and task-oriented bots are rapidly becoming first-class
   HTTP clients on the Web. Today’s infrastructure largely assumes a
   human behind a browser and monetizes content through advertising and
   coarse subscriptions.  Automated agents consume content at scale
   without rendering pages or viewing ads, exacerbating bot-mitigation
   arms races and economic misalignment between content providers and AI
   systems.

   This document describes an HTTP Agent Profile (HAP) that enables: (1)
   cryptographic authentication of agent traffic using HTTP Message
   Signatures; (2) clear separation between human and agent traffic
   using privacy-preserving human tokens; and (3) protocol-level value
   exchange for agents via HTTP status code 402 ("Payment Required") and
   pluggable micropayment mechanisms.  The profile reuses existing HTTP
   features and is designed for incremental deployment via reverse
   proxies, CDNs, and agent libraries.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 28 May 2026.





Dhir                       Expires 28 May 2026                  [Page 1]

Internet-Draft             HTTP Agent Profile              November 2025


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Requirements and Problem Statement  . . . . . . . . . . . . .   4
   4.  Design Space: New Protocol vs HTTP Profile  . . . . . . . . .   5
   5.  HTTP Agent Profile Overview . . . . . . . . . . . . . . . . .   5
   6.  Agent Authentication Using HTTP Message Signatures  . . . . .   6
   7.  Human vs. Agent Separation  . . . . . . . . . . . . . . . . .   8
   8.  HTTP 402 and Payment Profiles . . . . . . . . . . . . . . . .   9
   9.  Deployment and Operational Considerations . . . . . . . . . .  10
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   14. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   15. Informative References  . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Web traffic is undergoing a shift from primarily human-driven
   browsing to increasing volumes of autonomous agent activity.  Modern
   agents include search crawlers, LLM-based assistants that browse on
   behalf of users, and specialized bots that fetch and process large
   amounts of content.  These agents often access resources without
   rendering pages or viewing ads, and without participating in the
   economic arrangements that publishers rely on for human visitors.

   Existing mechanisms for distinguishing human traffic from automated
   traffic rely on fragile signals such as User-Agent strings, IP
   address ranges, and CAPTCHAs.  Sophisticated agents can mimic human
   behavior, use residential proxies, and even outsource CAPTCHAs to
   humans, making traditional bot detection increasingly ineffective.



Dhir                       Expires 28 May 2026                  [Page 2]

Internet-Draft             HTTP Agent Profile              November 2025


   At the same time, publishers and API providers respond with more
   aggressive blocking and rate limiting, which frequently catches
   legitimate agent services in the crossfire.  The result is an
   adversarial "dark forest" dynamic in which neither side has clear,
   protocol-level tools to cooperate.

   In parallel, regulators are starting to require clearer transparency
   about AI systems: for example, rules that users must be informed when
   interacting with an AI system rather than a human, and that bots must
   not misrepresent themselves for certain purposes.  These pressures
   suggest that HTTP should grow more explicit mechanisms for agent
   identification and handling.

   This document proposes an HTTP Agent Profile (HAP) as an HTTP-based
   approach to: (1) authenticate agent traffic using HTTP Message
   Signatures ([RFC9421]); (2) keep a separate "human lane" identified
   by privacy-preserving human tokens; and (3) enable protocol-level
   payments for agent access using HTTP 402.  Rather than defining a new
   application protocol, HAP stays within HTTP semantics ([RFC9110]) and
   is intended to be deployed via existing HTTP infrastructure,
   especially reverse proxies, CDNs, and agent SDKs.

2.  Conventions and Terminology

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

   The following terms are used throughout this document:

   *  _Agent_: An autonomous HTTP client that issues requests without a
      human directly driving each interaction (for example, a crawler,
      an LLM-based assistant, or an automated script).

   *  _Human client_: A human user interacting with a browser or similar
      user agent.

   *  _HTTP Agent Profile (HAP)_: A set of HTTP conventions for
      authenticating agents, separating human versus agent traffic, and
      expressing value exchange requirements for agents using HTTP 402.

   *  _Signed agent request_: An HTTP request that carries an HTTP
      Message Signature bound to an agent identifier.






Dhir                       Expires 28 May 2026                  [Page 3]

Internet-Draft             HTTP Agent Profile              November 2025


   *  _Payment challenge_: An HTTP 402 response that encodes a machine-
      readable requirement for payment or other economic work before
      access is granted.

3.  Requirements and Problem Statement

   Existing approaches to managing automated traffic have several
   limitations: User-Agent strings are self-declared and trivial to
   spoof; IP-based blocking is undermined by residential proxy networks
   and shared hosting; and CAPTCHA-based human verification is
   increasingly defeated by automation or outsourced labor, while
   degrading user experience for real humans.  Many sites treat any
   suspicious traffic as hostile, which often includes legitimate agents
   that do not identify themselves.

   We identify the following requirements for a pragmatic solution:

   1.  _R1 – Agent Identification:_ Servers should be able to
       cryptographically verify the origin of a request (which agent/
       software operator is responsible), rather than relying on self-
       asserted headers.

   2.  _R2 – Human vs. Agent Separation:_ The mechanism should enable
       servers to treat human and agent traffic differently, without
       imposing undue friction (like CAPTCHAs) on legitimate human
       users.

   3.  _R3 – Value Exchange:_ Servers should be able to require payment
       or other forms of compensation from agents at the HTTP protocol
       level (for example, using HTTP 402 challenges) in a machine-
       readable, automatable way.

   4.  _R4 – Incremental Deployability:_ The solution must work within
       existing HTTP/HTTPS infrastructure (standard ports, TLS, proxies,
       CDNs) and allow gradual adoption with graceful fallback for non-
       participating clients.

   5.  _R5 – Privacy and Openness:_ The design should accommodate both
       persistent agent identities (for building reputation) and
       ephemeral ones (for privacy), and it should not mandate that all
       content be behind a paywall for agents – free access options
       should remain possible.

   6.  _R6 – Extensibility:_ Higher-level frameworks (like robots.txt/
       llms.txt rules, AI metadata, or reputation systems) should be
       able to build on top of the mechanism, using it as a foundation
       for more sophisticated policy or trust layers.




Dhir                       Expires 28 May 2026                  [Page 4]

Internet-Draft             HTTP Agent Profile              November 2025


   In summary, the Web currently lacks a standardized method for agents
   to authenticate themselves or negotiate economic terms, and this
   proposal aims to fill that gap while meeting the above requirements.

4.  Design Space: New Protocol vs HTTP Profile

   One possible approach to agent traffic is to define a new
   application-layer protocol specifically for agents (an "Agent-HTTP").
   This could, for example, integrate attestation and payments into the
   connection handshake and optimize message patterns for agent
   communication.

   However, a clean-slate protocol would face significant deployment
   barriers: introducing new ALPN identifiers can trigger incompatible
   behavior in network middleboxes (firewalls, etc.), and it would
   require establishing new trust and certificate infrastructures for
   agent identities or attestations.  It would likely see slow adoption,
   as all parties would need to upgrade to speak the new protocol.

   By contrast, HAP takes a more incremental path by defining a profile
   within HTTP:

   *  It reuses HTTP/1.1, HTTP/2, and HTTP/3 transports and semantics
      unchanged.

   *  It adds profile-specific headers and behaviors (for authentication
      and payment) rather than altering core protocol syntax or
      introducing new methods.

   *  It can be implemented in middleware (reverse proxies, gateways) or
      libraries, meaning sites and agents can adopt it without a full-
      stack overhaul.  An optional ALPN token or HTTP/2 setting can be
      used as a hint for efficiency but is not required for correctness.

   We therefore focus on HAP – an HTTP profile for authenticated,
   monetized agent traffic – as the more practical approach.  A future,
   purpose-built agent protocol (informally, "HTTPA") could be
   considered if experience with HAP reveals the need for deeper
   changes, but initially HAP stays within the bounds of HTTP to
   maximize deployability.

5.  HTTP Agent Profile Overview

   At a high level, the HTTP Agent Profile defines two conceptual lanes
   for web traffic:






Dhir                       Expires 28 May 2026                  [Page 5]

Internet-Draft             HTTP Agent Profile              November 2025


   1.  _Human traffic lane:_ Requests from human-driven clients may
       carry a valid human token (e.g., a Privacy Pass token as per RFC
       9578) when available.  Such requests are treated as human-
       originated, meaning the server does not require them to be signed
       or paid through the HAP mechanisms.  Human users thus continue to
       browse without additional protocol friction (aside from the
       invisible token exchange).

   2.  _Agent traffic lane:_ Requests from autonomous agents carry an
       HTTP Message Signature that binds the request to an agent
       identity (see Section 6).  Servers recognizing these signatures
       can apply agent-specific policies: for example, issuing an HTTP
       402 challenge to request payment, enforcing stricter rate limits,
       or denying access based on the agent’s reputation or lack of
       compliance.

   Requests with neither a signature nor a human token fall into a
   legacy or unknown category.  Servers can handle these as they do
   today – possibly with CAPTCHAs, blocking, or lower service quality –
   or they may choose to gradually require HAP signals for certain
   resources once adoption is sufficient.  The intention is that over
   time, most legitimate traffic will present one of the signals (human
   or agent), simplifying traffic classification.

6.  Agent Authentication Using HTTP Message Signatures

   HAP-compliant agents use HTTP Message Signatures ([RFC9421]) to
   authenticate their requests.  Each HTTP request from an agent is
   augmented with a digital signature covering selected components of
   the request (such as headers and the request target).

   *Key establishment:* An agent operator generates one or more
   cryptographic key pairs (for example, an Ed25519 key).  The agent’s
   public key(s) are published in a key directory – for example at a
   known URL under the agent’s control.  A suggested convention is to
   use the HTTP Message Signatures key directory format at a well-known
   URI (for example, https://<agent-domain>/.well-known/agent-keys),
   which can list the agent’s current public keys and metadata (key IDs,
   expiration, and so on).

   *Request structure:* The agent includes the following headers in each
   request:









Dhir                       Expires 28 May 2026                  [Page 6]

Internet-Draft             HTTP Agent Profile              November 2025


   *Signature-Input*: Parameters indicating which parts of the HTTP
   request are covered by the signature, along with metadata like a
   creation time, expiration time, and a key identifier (kid).  For
   example, it might indicate it signs the @authority (host), the
   @method and @path, and a custom Signature-Agent header (see below),
   with a creation timestamp and a key ID of "agent-key-2025-01".

   *Signature*: The actual digital signature over the specified
   components, encoded in Base64.  This is typically labeled (for
   example, "Signature: sig1=...") matching the label used in Signature-
   Input.

   *Signature-Agent*: A header identifying the agent.  This could be a
   URI (for example, "https://agent.example.com") or a name
   corresponding to the key directory.  The contents of Signature-Agent
   are covered by the signature (by including "signature-agent" in the
   Signature-Input), ensuring an attacker cannot alter which agent is
   claiming to send the request.

   *Verification on the server:* When a HAP-enabled server (or
   intermediary) receives a request with those headers, it will:

   1.  Parse the Signature-Input to understand which components were
       signed and obtain the key identifier (keyid) and any metadata
       (for example, timestamp).

   2.  Locate the agent’s public key.  This could involve fetching the
       key from the URL specified by Signature-Agent (if it is an HTTPS
       URI) or looking up a cached key if seen recently.  The keyid
       helps select the correct key from the agent’s key set.

   3.  Verify the signature using the public key and the reconstructed
       signing string (per [RFC9421]).  If verification fails, the
       server knows the request was not actually from the claimed agent
       (or was tampered with), and it can be rejected (for example,
       treated as an invalid request or as a likely malicious bot).

   4.  If verification succeeds, the server now has an authenticated
       agent identity associated with the request.  It can log this or
       use it in further policy decisions.  For example, it might map
       the Signature-Agent URI to an internal identifier or check it
       against an allow/deny list.









Dhir                       Expires 28 May 2026                  [Page 7]

Internet-Draft             HTTP Agent Profile              November 2025


   *Key rotation and metadata:* The agent’s key directory can indicate
   when keys expire or are revoked.  Agents SHOULD rotate keys
   periodically (for instance, using a new keypair every 3–6 months) to
   limit the impact of key compromise.  Servers SHOULD NOT cache keys
   beyond their advertised validity and SHOULD fetch updates as needed.
   If a previously seen key suddenly fails verification, the server MAY
   fetch a fresh copy of the directory in case of key rotation.

   *Impersonation resistance:* Because the signature is tied to the
   agent’s domain (or identifier), another party cannot masquerade as
   that agent without access to its private key.  Even if a malicious
   bot claims the same Signature-Agent value as a well-known agent, its
   Signature header will not validate against the real agent’s public
   key, and thus it will be recognized as a fake.  This is a major
   improvement over the status quo where simply claiming User-Agent:
   Googlebot might fool some defenses.

7.  Human vs. Agent Separation

   HAP aims to avoid imposing protocol-level payment or signature
   requirements on human users whenever possible.  For human-driven
   traffic, modern privacy-preserving human tokens such as Private
   Access Tokens [RFC9578] can provide a strong signal that a request
   originates from a human user on a legitimate device, without exposing
   a stable identifier.

   In a HAP deployment, a server or intermediary can use the following
   classification strategy:

   *  If a request presents a valid human token, it is treated as human
      traffic.  Normal user experience applies (ads, subscriptions, or
      site policies).

   *  If a request presents a valid agent signature, it is treated as
      agent traffic and subject to agent-specific policies (including
      possible payment requirements).

   *  If a request presents neither signal, it is treated as legacy or
      unknown traffic and handled according to existing bot mitigation
      and security policies.

   User-side agents (such as browser-integrated assistants) MAY choose
   to present both a human token and an agent signature, to indicate
   that an autonomous component is acting on behalf of a specific user’s
   browsing session.  In such cases, servers can apply hybrid policies,
   for example permitting some forms of automated access at human-like
   rates without payment, while requiring payment for high-volume or
   bulk access.



Dhir                       Expires 28 May 2026                  [Page 8]

Internet-Draft             HTTP Agent Profile              November 2025


8.  HTTP 402 and Payment Profiles

   HTTP status code 402 ("Payment Required") was reserved in early HTTP
   specifications but left without a standardized meaning for decades.
   HAP adopts 402 as a machine-readable signal that a request from an
   authenticated agent is potentially acceptable, but access is
   contingent on some form of payment or economic work.

   When a server determines that an agent request requires payment, it
   responds with 402 instead of 200.  The response includes sufficient
   information for the agent to understand how to fulfill the
   requirement.  This information may appear in header fields (for
   example, a WWW-Authenticate challenge) and in the response body.
   Once the agent has fulfilled the requirement, it retries the request
   with proof of payment and, if validation succeeds, the server returns
   the requested resource.

   HAP itself is payment-agnostic.  It defines the use of 402 as a
   challenge mechanism and allows different payment systems to be bound
   to 402 via _payment profiles_. A payment profile specifies:

   *  How the server describes offers (price, currency, scope, and
      duration) in 402 responses.

   *  How the agent obtains a concrete payment request (for example, a
      Lightning invoice or other payment token).

   *  How the agent proves successful payment in subsequent requests.

   One concrete payment profile is L402 ([L402]), which combines
   Macaroon tokens and the Lightning Network.  Under L402, a server that
   wishes to charge an agent for access generates a Macaroon that
   encodes the scope and conditions of access, and a Lightning invoice
   for a specified amount.  These are returned in a 402 response.

   The agent then pays the Lightning invoice using its Lightning wallet
   or a custodial payment API.  Upon successful payment, the agent
   obtains the invoice preimage.  The agent retries the original
   request, including both the Macaroon (for example, in an
   Authorization header) and the preimage.  The server verifies the
   Macaroon signature and caveats, and that the hash of the preimage
   matches the invoice hash encoded in the Macaroon.  If both checks
   succeed, the server considers payment confirmed and grants access.








Dhir                       Expires 28 May 2026                  [Page 9]

Internet-Draft             HTTP Agent Profile              November 2025


   Other payment profiles could support different rails, such as on-
   chain cryptocurrency, fiat payment APIs, or proof-of-work-based
   puzzles.  HAP does not mandate any particular payment rail; it simply
   provides the 402 envelope in which such profiles can operate for
   agent traffic.

9.  Deployment and Operational Considerations

   One of HAP’s design goals is incremental deployability.  Sites do not
   need to convert all APIs or endpoints to HAP at once, and existing
   clients are unaffected unless they choose to implement the profile.

   In many deployments, reverse proxies, CDNs, and API gateways will be
   the primary enforcement points.  These intermediaries can:

   *  Verify HTTP Message Signatures on incoming requests and classify
      them as agent or non-agent.

   *  Validate human tokens where available and route such requests down
      a human lane.

   *  Apply local policy for known agent identities (allow, rate limit,
      block, or require payment).

   *  Issue HTTP 402 challenges and interact with payment backends
      (Lightning nodes, payment gateways, or other services).

   Origin servers can then be configured to see only requests that have
   either already satisfied HAP requirements or have been classified as
   non-HAP traffic.  For example, an API gateway might only forward
   requests that present a valid agent signature and, where required, a
   proof of payment.

   Servers and intermediaries can experiment with HAP policies in
   "report only" modes before enforcing them.  For example, a proxy
   could log cases where an unauthenticated high-volume agent would have
   been challenged with 402, without actually issuing the challenge yet.
   This allows operators to tune thresholds and pricing before turning
   on enforcement.

   As HAP use becomes more common, optional transport-level hints can
   improve efficiency.  For example, a client might include an ALPN
   identifier in its TLS handshake to indicate HAP support, or an HTTP/2
   SETTINGS parameter could advertise HAP capabilities.  These
   optimizations are not required for correctness; all HAP functionality
   can be negotiated via normal HTTP messages.





Dhir                       Expires 28 May 2026                 [Page 10]

Internet-Draft             HTTP Agent Profile              November 2025


10.  Security Considerations

   HAP introduces new security-relevant mechanisms at the HTTP layer.
   This section summarizes the main security considerations.

   _Authentication and impersonation._ HAP relies on HTTP Message
   Signatures bound to an agent identifier for agent authentication.  If
   an attacker obtains an agent’s private key, it can impersonate that
   agent until keys are rotated and caches expire.  Agent operators
   SHOULD protect private keys carefully, use hardware-backed storage
   where possible, and rotate keys regularly.  Servers SHOULD respect
   key expiration metadata and avoid pinning keys for longer than
   necessary.

   _Replay and downgrade._ Signatures SHOULD cover freshness indicators
   such as a timestamp and a nonce, and SHOULD be used over TLS.
   Servers SHOULD reject signatures that are too old or reuse the same
   nonce.  Agents and servers SHOULD prefer HTTPS and avoid sending
   signed requests over cleartext HTTP.

   _Key discovery and SSRF._ Key discovery via Signature-Agent and
   .well-known URLs introduces the risk of server-side request forgery
   (SSRF) or denial-of-service if an attacker can cause a server to
   fetch from arbitrary origins.  Servers SHOULD restrict outbound key
   discovery to public IP ranges, enforce timeouts and connection
   limits, and cache keys according to HTTP caching rules to avoid
   repeated lookups.

   _Denial-of-service._ Signature verification and payment processing
   consume CPU and network resources.  Implementations SHOULD be
   designed to bound the amount of work per request, for example by
   limiting the number of keys tried for verification and by offloading
   payment processing to dedicated services.  Operators SHOULD monitor
   for abuse patterns, such as floods of invalidly signed requests or
   repeated unpaid 402 challenges.

   _Abuse by authenticated agents._ An authenticated and paying agent
   can still behave maliciously or violate a site’s acceptable-use
   policy.  HAP does not attempt to prevent misuse of content once
   access is granted.  Instead, HAP aims to make agent traffic more
   accountable, so that misbehaving agent identities can be revoked or
   blocked and so that higher- level governance mechanisms and contracts
   can be applied.

11.  Privacy Considerations

   HAP affects privacy primarily through the introduction of agent
   identifiers and the handling of human tokens and payment metadata.



Dhir                       Expires 28 May 2026                 [Page 11]

Internet-Draft             HTTP Agent Profile              November 2025


   _Agent identity and tracking._ Persistent agent identifiers and long-
   lived keys can be used by servers to correlate agent behavior across
   sites.  This is desirable for enterprise crawlers seeking to build
   reputation, but may be undesirable for user-centric agents that act
   on behalf of individuals.  Operators of user-centric agents SHOULD
   use short-lived keys or per-origin keys to reduce the risk of cross-
   site tracking.  Servers SHOULD avoid treating agent identities as
   direct proxies for user identities unless there is a separate,
   explicit user authentication relationship.

   _Human tokens._ Privacy-preserving human tokens are designed so that
   issuers cannot link issuance and redemption events.  HAP deployments
   should preserve this property by not logging or correlating human
   tokens beyond what is necessary for validation.  Aggregated
   statistics (such as the rate of human versus agent traffic) can
   usually be collected without recording raw token values.

   _Payment metadata._ Payment systems may reveal information about who
   pays for what.  In many agent scenarios, payments are made by agent
   operators rather than end users, but care should be taken not to leak
   unnecessary payment metadata into application logs.  Where possible,
   payment flows should be handled by dedicated payment services that
   expose only the minimal proof necessary for access control (for
   example, a validated token or flag).

12.  IANA Considerations

   This document does not currently define any new registries or request
   any actions from IANA.  If future revisions define new HTTP header
   fields or authentication schemes specific to HAP, this section will
   be updated with appropriate registration requests.

13.  Acknowledgements

   The author thanks the broader HTTP, Web security, and AI standards
   communities for ongoing discussion about bot management, agent
   protocols, and monetization mechanisms, and acknowledges existing
   work on HTTP Message Signatures, Privacy Pass, and Lightning-based
   micropayments that helped shape this proposal.

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





Dhir                       Expires 28 May 2026                 [Page 12]

Internet-Draft             HTTP Agent Profile              November 2025


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

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

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

15.  Informative References

   [RFC9578]  Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
              "Privacy Pass Issuance Protocols", RFC 9578,
              DOI 10.17487/RFC9578, June 2024,
              <https://www.rfc-editor.org/info/rfc9578>.

   [L402]     Labs, L., "L402: Lightning HTTP 402 Protocol", 2023,
              <https://docs.l402.org/>.

Author's Address

   Sanat Dhir
   Independent
   Email: sdhir26@gsb.columbia.edu























Dhir                       Expires 28 May 2026                 [Page 13]


name: draft-liu-agent-operation-authorization
rev: 00
title: Agent Operation Authorization
time: 2025-11-25T14:20:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-29T14:20:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420495+00:00
abstract:
This document specifies the Agent Operation Authorization framework —
   a structured mechanism that enables verifiable delegation of actions
   from human principals to autonomous AI agents with fine-grained agent
   operation authorization.

   The framework introduces two distinct phases:

   *  *Agent Operation Authorization Request:* A human-readable proposal
      of operations derived from natural language input and converted to
      a JSON Web Token (JWT).

   *  *Agent Operation Authorization Token:* A JSON Web Token
      representing confirmed authorization for a specific agent
      operation, enforceable at runtime by agents and verifiers.  It
      cryptographically verifies user intent, prevents unauthorized or
      hallucinated actions, and ensures auditable traceability of each
      authorized operation.

full_text:
oauth                                                             D. Liu
Internet-Draft                                                    H. Zhu
Intended status: Standards Track                                 Alibaba
Expires: 29 May 2026                                    25 November 2025


                     Agent Operation Authorization
               draft-liu-agent-operation-authorization-00

Abstract

   This document specifies the Agent Operation Authorization framework —
   a structured mechanism that enables verifiable delegation of actions
   from human principals to autonomous AI agents with fine-grained agent
   operation authorization.

   The framework introduces two distinct phases:

   *  *Agent Operation Authorization Request:* A human-readable proposal
      of operations derived from natural language input and converted to
      a JSON Web Token (JWT).

   *  *Agent Operation Authorization Token:* A JSON Web Token
      representing confirmed authorization for a specific agent
      operation, enforceable at runtime by agents and verifiers.  It
      cryptographically verifies user intent, prevents unauthorized or
      hallucinated actions, and ensures auditable traceability of each
      authorized operation.

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






Liu & Zhu                  Expires 29 May 2026                  [Page 1]

Internet-Draft        Agent Operation Authorization        November 2025


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  agent_operation_proposal Token Structure  . . . . . . . . . .   4
   4.  Agent Operation Authorization Token . . . . . . . . . . . . .   8
   5.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  High-Level Flow . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Detailed Process Flow . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  JWT Claim Registration  . . . . . . . . . . . . . . . . .  13
     7.2.  JSON Schema Registration (Optional) . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   In agent-based systems, especially those involving generative
   capabilities, it is essential to convey not only what actions are
   permitted but also the original intent behind them and conditions
   under which an autonomous agent may act on behalf of a principal.

   This document specifies the Agent Operation Authorization framework —
   a mechanism that enables verifiable delegation of actions from human
   principals to autonomous AI agents with fine-grained agent operation
   authorization.  The framework includes Agent Operation Authorization
   Proposal and Agent Operation Authorization phases.

   This specification defines a new top-level JSON Web Token (JWT)
   claim, agent_operation, which contains fine-grained and structured
   operational parameters including agent_operations, constraints, and



Liu & Zhu                  Expires 29 May 2026                  [Page 2]

Internet-Draft        Agent Operation Authorization        November 2025


   conditions.  Additionally, it supports inclusion of a user-provided
   prompt whose authenticity is protected via a W3C Verifiable
   Credential (VC).

   The AI agent captures the user’s natural-language instruction during
   interaction, constructs a structured agent_operation_proposal
   object,includes a prompt evidence subfield carrying the user's
   natural-language instruction in the form of a JWT-based Verifiable
   Credential (JWT-VC), and submits the resulting JWT to the
   Authorization Server (AS) via OAuth 2.0 Pushed Authorization Requests
   (PAR) [RFC9126].

   This design ensures that downstream verifiers can validate both the
   policy boundaries and the provenance of the initiating instruction,
   without dependency on Decentralized Identifiers (DIDs).  This enables
   secure, auditable delegation for autonomous AI Agent.

   Upon successful user confirmation and authentication of the
   Authorization Proposal during the first phase, the Authorization
   Server (AS) SHALL issue an Agent Operation Authorization Token.  This
   token serves as the access token for subsequent interactions.

   The agent MUST present this JWT access token when accessing protected
   resources at the AS, using the mechanisms defined in OAuth 2.0
   [RFC6749] and bearer token usage rules [RFC6750].

   Together, these components ensure that AI systems act only within
   user-approved boundaries, mitigating risks such as hallucination.

   It is designed for use in autonomous AI Agent system, multi-agent
   orchestration, and regulated domains such as finance, healthcare, and
   public services — particularly where accountability and auditability
   are important.

   The framework supports enterprise identity providers, and zero-trust
   architectures.

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 RFC
   2119 [RFC2119].








Liu & Zhu                  Expires 29 May 2026                  [Page 3]

Internet-Draft        Agent Operation Authorization        November 2025


3.  agent_operation_proposal Token Structure

   The PAR-JWT (Pushed Authorization Request in JWT format) is used in
   the first phase.  Its purpose is to deliver the user's original input
   and the agent-proposed operational strategy to the AS, enabling the
   generation of a high-quality consent UI and establishing an
   evidentiary starting point.

   Its format is defined as follows:

                {
                    "iss": "https://client.myassistant.example",
                    "aud": "https://as.online-shop.example",
                    "iat": 1731664500,
                    "exp": 1731665100,
                    "jti": "par-jwt-123",

                    // ====== User original input prompt ======
                    "evidence": {
                      }

                    // ====== Agent operation proposal======
                    "agent_operation_proposal": {
                      "version": "1.0",
                      "id": "urn:uuid:op-proposal-456",
                      "issuer": "https://client.myassistant.example/agent-issuer",
                      "issuedTo": "user_12345@myassistant.example",
                      "issuedFor": {
                        "platform": "personal-agent.myassistant.example",
                        "client": "mobile-app-v1.myassistant.example",
                        "clientInstance": "dfp_abc123"
                      },
                      "issuanceDate": "2025-11-10T09:58:30Z",
                      "validFrom": "2025-11-10T10:00:00Z",
                      "expires": "2025-11-11T06:00:00Z",

                      "operations": [
                        {
                          "resources": ["https://api.online-shop.com/cart"],
                          "actions": ["purchase"]
                        }
                      ],
                      "constraints": {
                        "usage_limit": 1,
                        "revocable": true
                      },
                      "conditions": {



Liu & Zhu                  Expires 29 May 2026                  [Page 4]

Internet-Draft        Agent Operation Authorization        November 2025


                        "language": "cel",
                        "expression": "transaction.amount <= 50.0 && time.hour < 6"
                      },
                      "renderedText": "Buy something cheap on Nov 11 night"
                    },

                    // ====== Context information======
                    "context": {
                      "channel": "mobile-app",
                      "deviceFingerprint": "dfp_abc123",
                      "language": "zh-CN"
                    }
                }


                               Figure 1

   The *evidence* field is a JWT in JSON-VC (JSON Web Token-based
   Verifiable Credential) format, generated by the agent client and
   included in the agent operation proposal token.

   Its format is as follows:

   *  *JWT Header*

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "https://client.myassistant.example/.well-known/jwks.json#key-01"
    }


                               Figure 2

   *alg*

   Uses the RS256 asymmetric signing algorithm (recommended).

   *typ*

   Explicitly set to JWT to indicate the token type.

   *kid*

   The key identifier that references the public key used for
   verification, enabling the recipient to locate the corresponding
   public key (e.g., from a JWKS endpoint).




Liu & Zhu                  Expires 29 May 2026                  [Page 5]

Internet-Draft        Agent Operation Authorization        November 2025


   *  *JWT Payload*

    {
      "jti": "pt-001",
      "iss": "https://client.myassistant.example",
      "sub": "user_12345",
      "iat": 1731664500,
      "exp": 1731668100,

      // ====== W3C VC Format ======
      "type": "VerifiableCredential",
      "credentialSubject": {
        "type": "UserInputEvidence",
        "prompt": "Buy something cheap on Nov 11 night",
        "timestamp": "2025-11-11T23:30:00Z",
        "channel": "voice",
        "deviceFingerprint": "dfp_abc123"
      },
      "issuer": "https://client.myassistant.example",
      "issuanceDate": "2025-11-11T23:30:30Z",
      "expirationDate": "2025-11-12T06:00:00Z",

      // ====== Optional Proof ======
      "proof": {
        "type": "JwtProof2020",
        "created": "2025-11-11T23:30:30Z",
        "verificationMethod": "https://client.myassistant.example/#key-01"
      }
    }


                               Figure 3

   *  *Public Key Discovery Mechanism (JWKS)*

   The client agent publishes its public keys in JSON Web Key Set (JWKS)
   format at the well-known endpoint /.well-known/jwks.json.  To
   retrieve the public keys, a relying party sends an HTTPS GET request
   to this endpoint.

   GET /.well-known/jwks.json
   Host: client.myassistant.example

                                  Figure 4







Liu & Zhu                  Expires 29 May 2026                  [Page 6]

Internet-Draft        Agent Operation Authorization        November 2025


   {
     "keys": [
       {
         "kty": "RSA",
         "use": "sig",
         "kid": "key-01",
         "alg": "RS256",
         "n": "modulus_in_base64url...",
         "e": "AQAB"
       }
     ]
   }

                                  Figure 5

   *  *Signature*

   The Issuer (https://client.myassistant.example) generates the
   signature using its private key and the RS256 (RSA Signature with
   SHA-256) algorithm over the concatenated content: base64url(header) +
   '.' + base64url(payload).

   Final Output as Standard JWT Tripartite String

   The resulting JWT is a URL-safe, three-part encoded string in the
   format:

   eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Imh0dHBzOi8vY2xpZW50Lm15Y
   W5zd2VyLmV4YW1wbGUvLndlbGwta25vd24vandrLmpzb24ja2V5LTAxIn0.  eyJqdGki
   OiJwdC0wMDEiLCJpc3MiOiJodHRwczovL2NsaWVudC5teWFuc3dlci5leGFtcGxlIiwic
   3ViIjoidXNlcl8xMjM0NSIsImlhdCI6MTczMTY2NDUwMCwiZXhwIjoxNzMxNjY4MTAwLC
   J0eXBlIjoiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJ
   0eXBlIjoiVXNlcklucHV0RXZpZGVuY2UiLCJwcm9tcHQiOiJCdXkgc29tZXRoaW5nIGNo
   ZWFwIG9uIE5vdiAxMSBu .SIGNATURE

   *  *Verification Process:*

   (1) Decode the JWT; (2) Extract the kid from the header; (3) Retrieve
   the corresponding public key from /.well-known/jwks.json; (4)
   Validate the cryptographic signature; (5) Check policy conditions
   such as iss, time window (iat, exp), and device fingerprint.

   The Agent Client sends this PAR-JWT to the Authorization Server (AS)
   via the Pushed Authorization Request (PAR) mechanism, as defined in
   [RFC9126] (OAuth 2.0 Pushed Authorization Requests).






Liu & Zhu                  Expires 29 May 2026                  [Page 7]

Internet-Draft        Agent Operation Authorization        November 2025


4.  Agent Operation Authorization Token

   Upon successful user authorization and authentication, the
   Authorization Server (AS) issues a *Verifiable Agent Operation
   Credential* in the form of a JWT token.  The purpose of this
   credential is to serve as a digitally signed and independently
   verifiable "authorization letter", which enables the Personal Agent
   to perform authorized operations on behalf of the user.  The issuer
   of the credential is the Authorization Server (AS), and the intended
   recipient is the Personal Agent (which may be delivered via the
   client).  The credential becomes effective immediately after the user
   clicks "Allow" or "Consent".

{
  "iss": "https://as.online-shop.com",
  "sub": "user_12345@myassistant.example",
  "aud": "personal-agent.myassistant.example",
  "iat": 1731665200,
  "exp": 1732528800,
  "jti": "urn:uuid:aoc-authz-789",

  // ====== Evidence JWT-VC======
  "evidence": {
    "sourcePromptCredential": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...SIGNATURE"
  },

  // ====== Agent Operation Authorization ======
  "agent_operation_authorization": {
    "version": "1.0",
    "id": "urn:uuid:aoc-authz-789",
    "issuer": "https://as.online-shop.com",
    "issuedTo": "user_12345@myassistant.example",
    "issuedFor": {
      "platform": "personal-agent.myassistant.example",
      "client": "mobile-app-v1.myassistant.example",
      "clientInstance": "dfp_abc123"
    },
    "issuanceDate": "2025-11-11T10:08:20Z",
    "validFrom": "2025-11-11T10:10:00Z",
    "expires": "2025-11-16T06:00:00Z",

    "operations": [
      {
        "resources": ["https://api.online-shop.com/api/cart"],
        "actions": ["purchase"]
      }
    ],
    "constraints": {



Liu & Zhu                  Expires 29 May 2026                  [Page 8]

Internet-Draft        Agent Operation Authorization        November 2025


      "usage_limit": 1,
      "revocable": true
    },
    "conditions": {
      "language": "cel",
      "expression": "transaction.amount <= 50.0 && time.hour < 6"
    },
    "renderedText": "Purchase items under $50 during the Dec 11 night (00:00–06:00)"
  },

  // ====== auditTrail ======
  "auditTrail": {
      "originalPromptText": "Buy something cheap on Nov 11 night",
      "renderedOperationText": "Purchase items under $50 during the Dec 11 night (00:00–06:00)",
      "semanticExpansionLevel": "medium",
      "userAcknowledgeTimestamp": "2025-11-11T10:23:31Z",
      "consentInterfaceVersion": "consent-ui-v2.1"
  },

  // ====== Optional: Reference to Proposal ======
  "references": {
    "relatedProposalId": "urn:uuid:op-proposal-456"
  }
}





                               Figure 6

   *  *auditTrail* establishes a complete, semantically traceable
      chain—from the user's original intent to the system's final
      executed action—in AI Agent scenarios.  This mechanism is known as
      a _Semantic Audit Trail_. The specific purposes and their
      descriptions are outlined in the following table:















Liu & Zhu                  Expires 29 May 2026                  [Page 9]

Internet-Draft        Agent Operation Authorization        November 2025


   +================+==================================================+
   | Purpose        | Description                                      |
   +================+==================================================+
   | 1.  Intent     | Records what the user originally said            |
   | Provenance     | (e.g., "Buy something cheap on Nov 11            |
   |                | night") to prevent disputes such as: "I          |
   |                | didn’t say I wanted to buy anything!"            |
   +----------------+--------------------------------------------------+
   | 2.  Action     | Documents how the system interpreted             |
   | Interpretation | and rendered the input into a concrete           |
   |                | operation (e.g., "Purchase under $50             |
   |                | during 00:00–06:00"), reflecting the             |
   |                | AI’s reasoning process.                          |
   +----------------+--------------------------------------------------+
   | 3.  Semantic   | Shows whether semantic expansions or             |
   | Transparency   | default values were applied (e.g.,               |
   |                | mapping "cheap" to $50, defining                 |
   |                | "night" as 00:00–06:00).                         |
   +----------------+--------------------------------------------------+
   | 4.  User       | Includes timestamps indicating when the          |
   | Confirmation   | user reviewed and confirmed the                  |
   | Evidence       | interpreted action, serving as proof of          |
   |                | authorization.                                   |
   +----------------+--------------------------------------------------+
   | 5.             | Enables post-hoc analysis in case of             |
   | Accountability | erroneous transactions: Was the issue            |
   | Support        | due to ambiguous user input, system              |
   |                | misinterpretation, or misleading UI              |
   |                | guidance.                                        |
   +----------------+--------------------------------------------------+

       Table 1: Purposes and Descriptions of the Semantic Audit Trail

5.  Workflow

5.1.  High-Level Flow















Liu & Zhu                  Expires 29 May 2026                 [Page 10]

Internet-Draft        Agent Operation Authorization        November 2025


+--------+       +----------------+       +--------+       +------------------+
|  User  |       |   AI Agent     |       |  AS    |       | Resource Server  |
+--------+       +----------------+       +--------+       +------------------+
     |                   |                    |                    |
(1)  |      prompt       |                    |                    |
     |------------------>|                    |                    |
     |                   |                    |                    |
(2)  |                   | Parse & structure  |                    |
     |                   | operation proposal |                    |
     |                   |                    |                    |
(3)  |                   | Generate user's    |                    |
     |                   | prompt VC          |                    |
     |                   |                    |                    |
(4)  |                   | Build operation    |                    |
     |                   | proposal JWT       |                    |
     |                   |                    |                    |
(5)  |                   |                    | POST /par          |
     |                   |                    | with JWT --------->|
     |                   |                    |                    |
(6)  |                   |                    | Return request_uri |
     |                   |                    |<-------------------|
     |                   |                    |                    |
(7)  |                   | Redirect user to   |                    |
     |                   | /authorize?request_uri=...              |
     |                   |---------------------------------------->|
     |                   |                    |                    |
(8)  | Approve           |                    |                    |
     |<------------------------------------------------------------|
     |                   |                    |                    |
(9)  |                   |                    | Validate JWT       |
     |                   |                    | Extract operation  |
     |                   |                    | Issue access token |
     |                   |                    |<-------------------|
     |                   |                    |                    |
(10) |                   | Present access     |                    |
     |                   | token ------------>| Resource API       |
     |                   |                    |------------------->|
     |                   |                    | Enforce operation  |
     |                   |                    | Execute or deny    |
     |                   |                    |<-------------------|
     |                   |                    | Response           |
     |<------------------------------------------------------------|

                               Figure 7

5.2.  Detailed Process Flow





Liu & Zhu                  Expires 29 May 2026                 [Page 11]

Internet-Draft        Agent Operation Authorization        November 2025


(1) User says: "Buy something cheap on Nov 11 night"
     |
     v
(2) AI Agent parses intent → builds operation proposal object
     |
     v
(3) AS generate the original prompt VC using local private key (bound to issuerKey)
     |
     v
(4) Agent creates evidence section : { "evidence": { "sourcePromptCredential": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...SIGNATURE"} }
     |
     v
(5) Agent creates JWT with operation proposal claim, signs with JWS
     |
     v
(6) Agent sends JWT to AS via PAR: POST /par { "request": "<jwt>" }
     |
     v
(7) AS validates JWS, extracts agent_operation_proposal.prompt.signature and validate
     |
     v
(8) AS issues request_uri to agent
     |
     v
(9) Agent redirects user to /authorize?request_uri=...
     |
     v
(10) User reviews the original prompt and the agent__authorization_operation and approves
     |
     v

(11) AS issues Agent Operation Authorization Token as access token
     |
     v
(12) Agent uses token to access Resource Server
     |
     v
(13) AS verifies evidence VC
     |
     v
(14) RS enforces constraints and conditions
     |
     v
(15) Action executed or denied



                               Figure 8



Liu & Zhu                  Expires 29 May 2026                 [Page 12]

Internet-Draft        Agent Operation Authorization        November 2025


6.  Security Considerations

   The combination of JWS and VC provides dual-layer integrity: JWS
   protects the token, VC protects the prompt.

   Authorization Servers MUST validate the VC proof using the referenced
   issuerKey and associated public key material before accepting the
   request.

   Public keys referenced by issuerKey MUST be obtained through secure,
   trusted mechanisms (e.g., pre-registration, PKI).

   Expression evaluation (e.g., CEL) MUST occur in sandboxed
   environments.

   The use of PAR prevents leakage of sensitive operation data in URLs.

7.  IANA Considerations

7.1.  JWT Claim Registration

   This document requests IANA to register the following two claims in
   the "JSON Web Token Claims" registry, following the procedure defined
   in RFC 8126.

   Claim Name:  agent_operation_proposal

   Claim Description:  A structured representation of an operation
      proposed by an autonomous agent on behalf of a user.  It includes
      intended actions, constraints, conditions, and references to
      verifiable evidence (e.g., signed user input).  Used in delegation
      flows where user intent is expressed through natural language and
      converted into machine-executable proposals.

   Change Controller:  IETF

   Specification Document:  This document, Section X.Y ("Agent Operation
      Proposal")

   Claim Name:  agent_operation_authorization

   Claim Description:  A structured authorization decision issued by an
      Authorization Server in response to an operation proposal.  It
      mirrors the structure of the proposal but represents a formally
      approved scope of execution, potentially with additional policy-
      enforced constraints.  Enables auditable, revocable, and context-
      aware delegation for AI agents.




Liu & Zhu                  Expires 29 May 2026                 [Page 13]

Internet-Draft        Agent Operation Authorization        November 2025


   Change Controller:  IETF

   Specification Document:  This document, Section X.Z ("Agent Operation
      Authorization")

   Both claims are intended to be used within JWTs carrying structured
   permissions and operational intent in human-AI collaboration
   scenarios, particularly in regulated environments requiring
   traceability, non-repudiation, and alignment with EU AI Act
   principles such as transparency and accountability.

7.2.  JSON Schema Registration (Optional)

   Implementers may choose to publish formal JSON Schemas for
   agent_operation_proposal and agent_operation_authorization.  If
   standardized schemas are developed, they can be submitted to the IANA
   "JSON Schema Reserved Vocabulary" registry per RFC 9539.

8.  References

8.1.  Normative References

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

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

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

   [RFC9126]  Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
              and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
              RFC 9126, DOI 10.17487/RFC9126, September 2021,
              <https://www.rfc-editor.org/info/rfc9126>.

Acknowledgments

   The author thanks contributors from the IETF community for their
   valuable feedback on agent authorization semantics.

Authors' Addresses





Liu & Zhu                  Expires 29 May 2026                 [Page 14]

Internet-Draft        Agent Operation Authorization        November 2025


   Dapeng Liu
   Alibaba
   Email: max.ldp@alibaba-inc.com


   Hongru Zhu
   Alibaba
   Email: hongru.zhr@alibaba-inc.com











































Liu & Zhu                  Expires 29 May 2026                 [Page 15]


name: draft-jurkovikj-httpapi-agentic-state
rev: 00
title: HTTP Profile for Synchronized Resource State (Agentic State Transfer)
time: 2025-12-10T00:20:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-13T00:20:44Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "A2A protocols", "ML traffic mgmt"]
tags: []
fetched_at: 2026-02-27T22:56:03.420497+00:00
abstract:
HTTP resources are frequently exposed in multiple representations
   (e.g., text/html for rendering and application/json for processing)
   via Content Negotiation.  However, standard HTTP concurrency controls
   (such as ETags) are typically scoped to the byte sequence of a
   specific representation.  This creates a synchronization gap where a
   client modifying one representation cannot guarantee consistency with
   the underlying state of another representation, leading to race
   conditions and "lost updates" in multi-client environments.

   This document specifies _Agentic State Transfer_ (AST), an HTTP
   profile for managing _Canonical Resource State_ (CRS) across multiple
   synchronized representations of the same resource.  It defines the
   use of _Semantic Validators_ (Content Identity) to track the logical
   state of a resource independent of its serialization.  It further
   mandates the use of Optimistic Concurrency Control via If-Match
   headers for state-changing operations, ensuring that mutations
   applied by automated agents are atomic and consistent across all
   views.

full_text:
Internet Engineering Task Force                             A. Jurkovikj
Internet-Draft                                          10 December 2025
Intended status: Best Current Practice                                  
Expires: 13 June 2026


 HTTP Profile for Synchronized Resource State (Agentic State Transfer)
                draft-jurkovikj-httpapi-agentic-state-00

Abstract

   HTTP resources are frequently exposed in multiple representations
   (e.g., text/html for rendering and application/json for processing)
   via Content Negotiation.  However, standard HTTP concurrency controls
   (such as ETags) are typically scoped to the byte sequence of a
   specific representation.  This creates a synchronization gap where a
   client modifying one representation cannot guarantee consistency with
   the underlying state of another representation, leading to race
   conditions and "lost updates" in multi-client environments.

   This document specifies _Agentic State Transfer_ (AST), an HTTP
   profile for managing _Canonical Resource State_ (CRS) across multiple
   synchronized representations of the same resource.  It defines the
   use of _Semantic Validators_ (Content Identity) to track the logical
   state of a resource independent of its serialization.  It further
   mandates the use of Optimistic Concurrency Control via If-Match
   headers for state-changing operations, ensuring that mutations
   applied by automated agents are atomic and consistent across all
   views.

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 13 June 2026.





Jurkovikj                 Expires 13 June 2026                  [Page 1]

Internet-Draft           Agentic State Transfer            December 2025


Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  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.  The Synchronization Problem . . . . . . . . . . . . . . .   4
     1.2.  Canonical Resource State (CRS)  . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  The AST Profile . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Representation Roles  . . . . . . . . . . . . . . . . . .   6
     3.2.  Semantic Validators (The SBR ETag)  . . . . . . . . . . .   6
       3.2.1.  ETag Computation (Informative)  . . . . . . . . . . .   6
     3.3.  Discovery (rel="state") . . . . . . . . . . . . . . . . .   7
     3.4.  Read Semantics  . . . . . . . . . . . . . . . . . . . . .   7
       3.4.1.  Reading the SBR . . . . . . . . . . . . . . . . . . .   7
       3.4.2.  Reading Projections . . . . . . . . . . . . . . . . .   8
     3.5.  Write Semantics (The Safe Write Protocol) . . . . . . . .   8
       3.5.1.  Conflict Resolution (Informative) . . . . . . . . . .  10
   4.  Client immediately refetches  . . . . . . . . . . . . . . . .  11
   5.  Client reapplies mutation with fresh ETag . . . . . . . . . .  11
     5.1.  SBR Endpoint Headers  . . . . . . . . . . . . . . . . . .  11
     5.2.  Caching Considerations  . . . . . . . . . . . . . . . . .  11
       5.2.1.  SBR Caching . . . . . . . . . . . . . . . . . . . . .  11
       5.2.2.  Projected Representation Caching  . . . . . . . . . .  12
   6.  Computing and Managing Semantic Validators  . . . . . . . . .  12
     6.1.  Canonicalization  . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Storage Models  . . . . . . . . . . . . . . . . . . . . .  13
     6.3.  Relationship to Application Backends  . . . . . . . . . .  13
     6.4.  Non-AST Resources and Fallback Behavior . . . . . . . . .  14
   7.  Integrity and Transport . . . . . . . . . . . . . . . . . . .  14
     7.1.  Separation of State and Integrity . . . . . . . . . . . .  14
   8.  Discovery of Synchronized Representations . . . . . . . . . .  15
     8.1.  The state Relation (SBR Discovery)  . . . . . . . . . . .  16
     8.2.  The alternate Relation (General Cross-Representation
           Navigation) . . . . . . . . . . . . . . . . . . . . . . .  16
     8.3.  Bidirectional Linking . . . . . . . . . . . . . . . . . .  16



Jurkovikj                 Expires 13 June 2026                  [Page 2]

Internet-Draft           Agentic State Transfer            December 2025


     8.4.  Profile Advertisement . . . . . . . . . . . . . . . . . .  17
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
     9.1.  Consistency and Race Conditions . . . . . . . . . . . . .  17
     9.2.  Information Leakage via Divergence  . . . . . . . . . . .  18
     9.3.  Validator Guessing  . . . . . . . . . . . . . . . . . . .  18
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     10.1.  Link Relation Type Registration  . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Appendix A.  Appendix A.  Implementation Status . . . . . . . . .  20
     A.1.  WordPress Dual-Native Implementation  . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   The architecture of the World Wide Web allows a single logical
   resource (identified by a URI) to be represented in multiple formats.
   A common pattern in modern systems is to expose:

   *  a _Rendered Representation_ (e.g., text/html) for human agents,
      and

   *  a _Structural Representation_ (e.g., application/json) for
      automated agents.

   In AST terminology, rendered representations are typically _Projected
   Representations_, while a structural representation MAY serve as the
   _State-Bearing Representation (SBR)_ when it exposes the full
   Canonical Resource State.

   HTTP provides mechanisms for content negotiation [RFC9110], and
   defines validators such as ETag for caching and conditional requests.
   However, in most deployments:

   *  validators are derived from a particular representation's bytes,
      and

   *  concurrency control, if present at all, is scoped to a single
      representation.

   This creates a _synchronization gap_: two clients interacting with
   different representations of the same logical resource can
   unwittingly overwrite each other's work.

   AST addresses this problem by treating the _Canonical Resource State_
   (CRS) as the primary object of synchronization, and by standardizing
   how HTTP validators are used as _Semantic Validators_ for that CRS.



Jurkovikj                 Expires 13 June 2026                  [Page 3]

Internet-Draft           Agentic State Transfer            December 2025


1.1.  The Synchronization Problem

   Consider a resource /article/123 exposed both as HTML and JSON.

   1.  _Client A (Browser)_ retrieves the HTML representation.

   2.  _Client B (Automated Agent)_ retrieves the JSON representation.

   3.  Client A submits an edit via an HTML form, updating the
       underlying database record.

   4.  Client B, unaware of the change, computes an update based on its
       stale JSON representation and submits a PUT or PATCH request.

   In typical HTTP APIs, at least one of the following is true:

   *  there is no ETag at all;

   *  the ETag is tied to the bytes of a specific representation (e.g.,
      JSON only); or

   *  the server does not enforce preconditions (If-Match).

   As a result, Client B's request may succeed, even though:

   *  its view of the resource is stale, and

   *  the update logically conflicts with Client A's change.

   This is the classic _Lost Update_ problem, now exacerbated by the
   growing use of automated agents acting as first-class editors.

1.2.  Canonical Resource State (CRS)

   To address this, AST introduces the concept of _Canonical Resource
   State_ (CRS):

      CRS is the authoritative, logical state of the resource,
      independent of any particular representation or serialization.

   For example, the CRS might be:

   *  a database row (or set of rows),

   *  a document or AST (abstract syntax tree),

   *  a domain object in application memory, or




Jurkovikj                 Expires 13 June 2026                  [Page 4]

Internet-Draft           Agentic State Transfer            December 2025


   *  in a WordPress CMS, the post record in wp_posts with fields like
      post_content, post_title, post_status, and associated metadata.

   Representations such as HTML, JSON, or Markdown are derived _from_
   the CRS and are considered projections of that state.

   AST defines a profile where:

   1.  *Shared Identity* -- All HTTP representations of an AST resource
       are projections of the same CRS.

   2.  *Semantic Validation* -- Validators (ETag values) are derived
       from the CRS, not a specific representation's bytes, so that a
       change to the CRS invalidates all representations together.

   3.  *Mandatory Concurrency* -- State-changing operations on AST
       resources MUST provide a precondition (If-Match) based on the CRS
       validator.

   This enables safe interaction by automated agents and human clients,
   ensuring they participate in the same state transition model.

2.  Terminology

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

   *Canonical Resource State (CRS)*  The underlying, authoritative
      logical state of a resource (e.g., the database record or abstract
      syntax tree).  The CRS is the atomic unit of concurrency.

   *State-Bearing Representation (SBR)*  A specific representation
      (e.g., application/json) that exposes the CRS in a lossless,
      deterministic format.  The SBR serves as the Concurrency Lock for
      the resource.  Its ETag represents the version of the CRS.

   *Projected Representation*  A representation derived from the CRS for
      a specific consumption pattern (e.g., text/html for rendering,
      text/csv for analysis).  Projected Representations are Read-Only
      with respect to the CRS; they reflect the state but do not govern
      it.

   *Semantic Validator*  The Strong ETag associated with the SBR.  It
      changes if and only if the CRS changes.




Jurkovikj                 Expires 13 June 2026                  [Page 5]

Internet-Draft           Agentic State Transfer            December 2025


   *AST Resource*  A resource that conforms to this profile.

3.  The AST Profile

   This section defines the Agentic State Transfer (AST) profile.  It
   specifies how clients synchronize state across multiple
   representations by pivoting on the State-Bearing Representation
   (SBR).

3.1.  Representation Roles

   For a given AST Resource, the server MUST designate exactly one
   representation as the State-Bearing Representation (SBR).  All other
   representations are considered Projected Representations.

   *  The SBR acts as the source of truth for state synchronization.

   *  Projected Representations are derivative views.  While they MAY
      have their own caching validators (ETags) based on their specific
      byte sequences, they MUST NOT be used as the basis for state-
      changing preconditions on the CRS.

3.2.  Semantic Validators (The SBR ETag)

   The server MUST assign a Strong ETag to the SBR.  This ETag serves as
   the Semantic Validator for the resource.

   *  *Determinism*: The SBR ETag MUST change whenever the CRS changes.

   *  *Scope*: The SBR ETag MUST NOT be reused as the ETag for Projected
      Representations, as this would confuse standard HTTP caches.

   *Canonicalization*: Implementations MAY compute the SBR ETag from a
   deterministic canonical serialization of the CRS (e.g., JSON
   Canonicalization Scheme, RFC 8785 [RFC8785]).  This ensures that
   logically identical states produce identical validators, regardless
   of field ordering or formatting variations.  See Section 4.1 for
   detailed guidance.

3.2.1.  ETag Computation (Informative)

   The SBR ETag MUST be a strong validator as defined in [RFC9110].
   Implementations MAY compute the SBR ETag using any method that
   satisfies both the determinism and strong validator requirements.
   Common approaches include:






Jurkovikj                 Expires 13 June 2026                  [Page 6]

Internet-Draft           Agentic State Transfer            December 2025


   *  *Content Hash*: SHA-256 or similar cryptographic hash over the
      canonicalized SBR bytes (e.g., "sha256-YWJjMTIz...").  This is
      RECOMMENDED for interoperability, as it allows clients to verify
      state equivalence without server coordination and naturally
      produces strong validators.

   *  *Version Counter*: Monotonic version number from the data store
      (e.g., "v42" or "rev-1234").  This is simple but requires
      centralized version tracking.  The version must increment on every
      CRS change to maintain strong validator semantics.

   The content hash approach provides the strongest guarantee that
   identical CRS values produce identical ETags across different server
   instances or time periods, which aids debugging and distributed
   deployments.

3.3.  Discovery (rel="state")

   To enable clients consuming a Projected Representation (e.g., HTML)
   to discover the SBR for synchronization or editing, servers SHOULD
   include a Link header with the state relation type.  The type
   attribute MUST be present to indicate the media type of the SBR,
   enabling clients to determine how to interact with it.

   *Example* (response for GET /article/123.html):

   http HTTP/1.1 200 OK Content-Type: text/html ETag: "html-v1" Link:
   </api/article/123>; rel="state"; type="application/json"

3.4.  Read Semantics

3.4.1.  Reading the SBR

   Clients SHOULD use the SBR ETag for conditional requests (If-None-
   Match) on the SBR URI.  The server MUST return 304 Not Modified if
   the CRS has not changed.  On a 304 response, the server SHOULD
   include the current SBR ETag in the response headers.

   Clients MUST NOT use the SBR ETag as If-None-Match against Projected
   endpoints.  Projected endpoints have their own byte-specific
   validators.

   *Example: HEAD Request to Fetch SBR Validator*

   Clients MAY use HEAD to obtain the current SBR ETag without
   transferring the full representation body:





Jurkovikj                 Expires 13 June 2026                  [Page 7]

Internet-Draft           Agentic State Transfer            December 2025


   ```http HEAD /api/article/123 HTTP/1.1 Host: example.com Accept:
   application/json

   HTTP/1.1 200 OK Content-Type: application/json ETag:
   "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F" Content-Length: 4521 ```

   This allows clients to check for state changes with minimal bandwidth
   usage before deciding whether to fetch the full representation.

3.4.2.  Reading Projections

   Clients MAY cache Projected Representations using their specific
   ETags.  However, clients MUST recognize that a Projected
   Representation may be stale relative to the CRS if the SBR ETag has
   changed.

3.5.  Write Semantics (The Safe Write Protocol)

   To modify the Canonical Resource State, clients MUST perform the
   mutation against the SBR Endpoint (or an endpoint explicitly bound to
   the SBR's validator).

   Clients *MUST NOT* use a Projected Representation's ETag as an If-
   Match precondition for CRS mutations.  Only the SBR's own ETag is
   valid for concurrency control.

   1.  *Precondition*: The client obtains the current SBR ETag (via GET
       or HEAD on the SBR URI).

   2.  *Mutation*: The client sends the state-changing request (PUT,
       POST, PATCH) including the If-Match header set to the SBR ETag.

   3.  *Verification*:

       *  If the If-Match header is missing, servers SHOULD respond with
          428 Precondition Required [RFC6585].  Servers MAY respond with
          400 Bad Request if 428 is not supported by the implementation
          environment, provided the error body clearly indicates the
          missing precondition requirement.

       *  If the provided ETag does not match the current CRS version,
          the server MUST respond with 412 Precondition Failed.

       *  If the provided ETag matches the current CRS version, the
          server MUST accept the write (subject to authorization),
          update the CRS, and invalidate all Projected Representations.





Jurkovikj                 Expires 13 June 2026                  [Page 8]

Internet-Draft           Agentic State Transfer            December 2025


       *Note*: For endpoints that do *not* implement AST semantics,
       servers MAY accept unconditional writes as in traditional HTTP
       APIs.  See the "Non-AST Resources and Fallback Behavior" section
       for guidance on mixed deployments.

   4.  *Response*: Upon a successful write, the server SHOULD return the
       new SBR ETag in the response headers, allowing the client to
       chain subsequent updates immediately.

   5.  *Error Bodies*: For 412, 428, and 400 (when used for missing
       preconditions) responses, servers SHOULD return a Problem Details
       body [RFC7807] to assist automated clients in resolving the
       conflict.

   *Example: 428 Response for Missing Precondition*

   When a client attempts a state-changing operation without If-Match,
   the server SHOULD return a 428 response:

   ```http PATCH /api/article/123 HTTP/1.1 Host: example.com Content-
   Type: application/json

   HTTP/1.1 428 Precondition Required Content-Type: application/
   problem+json

   { "type": "https://example.com/errors/precondition-required",
   "title": "Precondition Required", "status": 428, "detail": "If-Match
   header is required for CRS mutations" } ```

   *Alternative: 400 Response When 428 Is Not Available*

   If the server environment does not support 428, it MAY use 400 with a
   clear error message:

   ```http PATCH /api/article/123 HTTP/1.1 Host: example.com Content-
   Type: application/json

   HTTP/1.1 400 Bad Request Content-Type: application/problem+json

   { "type": "https://example.com/errors/missing-precondition", "title":
   "Missing Required Precondition", "status": 400, "detail": "If-Match
   header is required for state-changing operations on AST resources" }
   ```

   *Example: 412 Response with Problem Details*

   When a client's If-Match precondition fails, the server SHOULD return
   a Problem Details response indicating the current state:



Jurkovikj                 Expires 13 June 2026                  [Page 9]

Internet-Draft           Agentic State Transfer            December 2025


   ```http PATCH /api/article/123 HTTP/1.1 Host: example.com Content-
   Type: application/json If-Match:
   "sha256-ABC123OLDVALUE456789STALE012"

   HTTP/1.1 412 Precondition Failed Content-Type: application/
   problem+json ETag: "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F"

   { "type": "https://example.com/errors/precondition-failed", "title":
   "Precondition Failed", "status": 412, "detail": "The resource state
   has changed since you last read it.", "current-etag":
   "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F", "provided-etag":
   "sha256-ABC123OLDVALUE456789STALE012" } ```

   The inclusion of the current ETag in the error response allows the
   client to immediately refetch the latest state without an additional
   round trip.

3.5.1.  Conflict Resolution (Informative)

   When a client receives a 412 Precondition Failed response, it SHOULD
   follow one of these resolution strategies:

   1.  *Refetch and Retry*: Fetch the current SBR to obtain the new ETag
       and state, then reapply the intended mutation and retry with the
       updated ETag.

   2.  *Three-Way Merge*: If the client maintains the original state it
       read, the changes it intended to make, and can obtain the current
       server state, it MAY attempt an automatic merge (similar to
       version control systems).  This is only appropriate when changes
       affect non-overlapping fields or can be deterministically
       combined.

   3.  *User Intervention*: Present the conflict to the user (human or
       automated decision system) for manual resolution, showing both
       the client's intended changes and the server's current state.

   4.  *Abort*: Abandon the update if the conflict indicates the
       client's view is too stale or the changes are incompatible.

   Servers MAY assist conflict resolution by including the current state
   or a conflict diff in the 412 response body (see Problem Details
   example above).  This reduces round trips and provides clients with
   immediate context for resolution.

   *Retry Example:*





Jurkovikj                 Expires 13 June 2026                 [Page 10]

Internet-Draft           Agentic State Transfer            December 2025


   ```http # Client receives 412 HTTP/1.1 412 Precondition Failed
   Content-Type: application/problem+json ETag:
   "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F"

4.  Client immediately refetches

   GET /api/article/123 HTTP/1.1 If-None-Match:
   "sha256-ABC123OLDVALUE456789STALE012"

   HTTP/1.1 200 OK ETag: "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F" {
   ...current state... }

5.  Client reapplies mutation with fresh ETag

   PATCH /api/article/123 HTTP/1.1 If-Match:
   "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F" ```

5.1.  SBR Endpoint Headers

   To ensure correct caching and transfer behavior, SBR endpoints SHOULD
   include the following headers:

   *  *Cache-Control*: SBR responses SHOULD include Cache-Control: no-
      transform to prevent intermediaries from modifying the
      representation (which would invalidate the Semantic Validator).

   *  *Vary*: If the SBR supports compression or other content
      transformations, servers SHOULD set Vary: Accept-Encoding to
      ensure caches distinguish between compressed and uncompressed
      variants.

   *  *Accept-Ranges*: SBR endpoints SHOULD include Accept-Ranges: none
      if range requests would break the semantic integrity of the
      representation (e.g., partial JSON structures).

   *Example SBR Response Headers:*

   http HTTP/1.1 200 OK Content-Type: application/json ETag:
   "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F" Cache-Control: no-cache, no-
   transform Vary: Accept-Encoding Accept-Ranges: none Content-Digest:
   sha-256=:RK63H5GH1GQJQM8A7LN7RP8VNR7FVXWH1TQKJM8QZH4=:

5.2.  Caching Considerations

5.2.1.  SBR Caching

   SBR endpoints SHOULD follow these caching practices:




Jurkovikj                 Expires 13 June 2026                 [Page 11]

Internet-Draft           Agentic State Transfer            December 2025


   *  *Non-Negotiated SBR*: Prefer a single canonical media type for the
      SBR to avoid cache fragmentation.

   *  *Strong ETag*: The SBR MUST expose a strong ETag as the Semantic
      Validator.

   *  *Cache-Control*: Use Cache-Control: no-cache, no-transform to
      require revalidation while allowing storage.  If the SBR contains
      sensitive or user-specific data, use Cache-Control: private or no-
      store as appropriate.

   *  *Vary*: Set Vary: Accept-Encoding if compression is applied to
      allow caches to distinguish between compressed and uncompressed
      variants.

   *  *Accept-Ranges*: Consider Accept-Ranges: none to prevent partial-
      byte range requests that could create ambiguity in state
      validation.

   *  *304 Revalidation*: Support conditional requests with If-None-
      Match and respond with 304 Not Modified when the SBR ETag matches.

   *  *ETag Scope*: Do NOT reuse the SBR ETag on Projected endpoints, as
      this would conflate semantic and byte-level validation.

5.2.2.  Projected Representation Caching

   Projected Representations SHOULD be cached using standard HTTP
   caching mechanisms:

   *  *Representation-Specific ETags*: Use their own ETags based on the
      byte content of each projection.

   *  *Standard Cache-Control*: Apply appropriate Cache-Control
      directives (e.g., max-age, public, private) based on the
      projection's volatility and sensitivity.

   *  *Client-Side Invalidation*: Clients that perform CRS mutations
      SHOULD invalidate their own cached Projected Representations after
      a successful write or upon receiving a 412 Precondition Failed
      response.  Note that shared caches and intermediaries will not
      automatically invalidate projections based on SBR changes.

6.  Computing and Managing Semantic Validators

   AST does not mandate a single algorithm for computing Semantic
   Validators.  However, interoperability and predictability benefit
   from consistent approaches.



Jurkovikj                 Expires 13 June 2026                 [Page 12]

Internet-Draft           Agentic State Transfer            December 2025


6.1.  Canonicalization

   A common pattern is to derive the Semantic Validator from a canonical
   serialization of the CRS.  For example:

   1.  Serialize the CRS to a structured format (for example, JSON).

   2.  Canonicalize the serialization (for example, by sorting keys and
       controlling numeric formats).

   3.  Compute a hash over the canonical form (for example, SHA-256).

   4.  Encode and prefix the hash to produce the ETag value.

   Servers *SHOULD* ensure that:

   *  fields that are purely operational or volatile (for example, last
      access timestamps) are excluded from the canonical form; and

   *  the canonicalization process is deterministic across deployments.

   Servers MAY use [RFC8785] JSON Canonicalization Scheme (JCS) or an
   equivalent deterministic procedure.

6.2.  Storage Models

   Servers MAY:

   *  compute Semantic Validators on demand from the CRS; or

   *  store precomputed Semantic Validators alongside the CRS.

   When validators are stored:

   *  they *SHOULD* be updated atomically with the CRS; and

   *  they *MUST* be invalidated or recomputed whenever the CRS changes.

   When validators are computed on demand, implementations *SHOULD*
   ensure that the cost of computing the validator is small relative to
   the cost of generating the representation.

6.3.  Relationship to Application Backends

   AST is agnostic to how applications store and manage CRS.  For
   example:





Jurkovikj                 Expires 13 June 2026                 [Page 13]

Internet-Draft           Agentic State Transfer            December 2025


   *  a SQL application might treat a row (or set of rows) as CRS, with
      the Semantic Validator derived from a version column and relevant
      fields;

   *  a document store might treat a document body plus metadata as CRS;

   *  a CMS might treat a block tree or content graph as CRS.

   The only requirement is that the Semantic Validator change whenever
   the logical CRS changes, regardless of how many representations
   exist.

6.4.  Non-AST Resources and Fallback Behavior

   Servers MAY implement AST for some resources and not others.

   For resources that do not follow AST:

   *  servers MAY continue to use representation-specific ETags as byte
      validators;

   *  servers MAY accept unconditional writes (no If-Match required), as
      in traditional HTTP APIs; and

   *  clients MUST NOT assume AST semantics.

   Servers SHOULD clearly document which resources implement AST.

7.  Integrity and Transport

   In standard HTTP usage, ETags often serve a dual purpose: validating
   the semantic state for caching/concurrency, and validating the
   integrity of the response bytes (to detect transport corruption).

   In the AST profile, the State-Bearing Representation (SBR) ETag
   serves as the *Semantic Validator* for the Canonical Resource State
   (CRS).  Projected Representations MAY have their own representation-
   specific ETags for caching purposes, but these MUST NOT be used as
   Semantic Validators for concurrency control.

7.1.  Separation of State and Integrity

   To allow clients to verify the integrity of the payload bytes
   independently of the semantic state, AST servers *SHOULD* use the
   Content-Digest header field defined in [RFC9530].






Jurkovikj                 Expires 13 June 2026                 [Page 14]

Internet-Draft           Agentic State Transfer            December 2025


   *  *ETag (SBR)*: validates the _Canonical Resource State_ (logical
      truth) and is used with If-Match and If-None-Match for concurrency
      control.

   *  *ETag (Projected)*: MAY be used for caching individual
      representations, but MUST NOT be used for state-changing
      preconditions.

   *  *Content-Digest*: validates the _representation bytes_ (wire
      truth) and is used to verify that the transfer completed
      successfully.

   Clients *MUST NOT* send If-Match or If-None-Match preconditions using
   a Projected Representation's ETag when interacting with the SBR
   endpoint.  Only the SBR's own ETag participates in concurrency
   control logic.

   *Example Response (SBR):*

   http HTTP/1.1 200 OK Content-Type: application/json ETag:
   "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F" Content-Digest: sha-
   256=:RK63H5GH1GQJQM8A7LN7RP8VNR7FVXWH1TQKJM8QZH4=:

   *Example Response (Projected):*

   http HTTP/1.1 200 OK Content-Type: text/html ETag: "html-v1" Link:
   </api/article/123>; rel="state"; type="application/json" Content-
   Digest: sha-256=:X8Z9Y7W6V5U4T3S2R1Q0P9O8N7M6L5K4=:

   This separation allows intermediaries and clients to detect transport
   corruption without conflating it with state changes.

   In AST, the SBR ETag serves as a semantic validator for the Canonical
   Resource State.  Clients SHOULD use Content-Digest for verifying byte
   integrity of the transfer.  Outside of AST contexts, traditional ETag
   usage for caching and integrity remains unchanged.

8.  Discovery of Synchronized Representations

   To enable agents to discover different representations of the same
   AST resource, servers *SHOULD* expose relationships between
   representations using the HTTP Link header [RFC8288].









Jurkovikj                 Expires 13 June 2026                 [Page 15]

Internet-Draft           Agentic State Transfer            December 2025


8.1.  The state Relation (SBR Discovery)

   As defined in Section 3.3, Projected Representations SHOULD include a
   Link header with rel="state" pointing to the State-Bearing
   Representation (SBR).  This allows clients consuming a Projected
   Representation to discover the SBR for synchronization or editing.

   The state relation identifies the authoritative SBR for concurrency
   control purposes.  Clients MUST use the ETag from the state target
   (the SBR) for all If-Match and If-None-Match preconditions on state-
   changing operations.

   *Example* (Projected Representation response):

   http HTTP/1.1 200 OK Content-Type: text/html ETag: "html-v1" Link:
   </api/article/123>; rel="state"; type="application/json"

8.2.  The alternate Relation (General Cross-Representation Navigation)

   The alternate link relation type is *RECOMMENDED* for general
   navigation between synchronized representations of the same AST
   resource.

   When providing an alternate link:

   *  the type attribute *MUST* be present to indicate the media type of
      the target representation (for example, application/json, text/
      html); and

   *  the profile attribute *MAY* be used to indicate a specific schema
      or capability set of the target representation.

   *Example* (SBR response linking to Projected):

   http HTTP/1.1 200 OK Content-Type: application/json ETag:
   "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F" Link: </article/123.html>;
   rel="alternate"; type="text/html"

   *Note:* The state relation specifically identifies the SBR for
   concurrency control purposes.  In contrast, rel="alternate" is for
   general cross-representation navigation and does *not* imply
   concurrency semantics.  Clients MUST NOT assume that a representation
   linked via alternate participates in the AST concurrency protocol.

8.3.  Bidirectional Linking

   To ensure agents can navigate between representations regardless of
   their entry point, linking *SHOULD* be bidirectional.



Jurkovikj                 Expires 13 June 2026                 [Page 16]

Internet-Draft           Agentic State Transfer            December 2025


   *  If Representation A links to Representation B, then Representation
      B *SHOULD* link back to Representation A (or to a canonical URI
      that resolves to A).

   This ensures that an agent encountering a structural representation
   (for example, JSON) can identify the corresponding rendered
   representation (for example, HTML) for attribution, verification, or
   human inspection.

8.4.  Profile Advertisement

   To enable clients to detect whether a resource implements AST
   semantics, servers SHOULD advertise this using the profile link
   relation [RFC6906] via one of the following mechanisms:

   *Link Header with Profile Relation:*

   http HTTP/1.1 200 OK Content-Type: application/json Link:
   <https://datatracker.ietf.org/doc/draft-jurkovikj-http-agentic-
   state/>; rel="profile" ETag: "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F"

   *Content-Type Profile Parameter:*

   http HTTP/1.1 200 OK Content-Type: application/json;
   profile="https://datatracker.ietf.org/doc/draft-jurkovikj-http-
   agentic-state/" ETag: "sha256-RK63H5GH1GQJQM8A7LN7RP8VNR7F"

   This allows clients to detect AST resources and apply appropriate
   concurrency control workflows (If-Match preconditions, 412 handling,
   etc.) instead of assuming traditional HTTP semantics.

9.  Security Considerations

   This profile relies on existing HTTP security mechanisms.  However,
   the synchronization of multiple representations introduces specific
   security considerations.

9.1.  Consistency and Race Conditions

   The primary security benefit of AST is the prevention of race
   conditions (Lost Updates).  By enforcing If-Match checks against the
   CRS, the server ensures that an agent cannot overwrite state changes
   made by another client, even if those changes were made via a
   different representation.

   Applications *SHOULD* treat failed preconditions (412, 428) as an
   expected outcome in concurrent editing scenarios and provide
   appropriate conflict resolution mechanisms.



Jurkovikj                 Expires 13 June 2026                 [Page 17]

Internet-Draft           Agentic State Transfer            December 2025


9.2.  Information Leakage via Divergence

   If the access control policies for different representations diverge,
   there is a risk of information leakage.

   *  Servers *MUST* ensure that the authorization requirements for
      accessing a structural representation (for example, JSON) are at
      least as strict as those for the rendered representation (for
      example, HTML).

   *  Servers *MUST* ensure that a structural representation does not
      expose sensitive data that is redacted in the rendered
      representation, unless the client is explicitly authorized to see
      the raw state.

   If different audiences see different subsets of the CRS, the server
   SHOULD either:

   *  maintain separate CRS domains with separate Semantic Validators;
      or

   *  apply view-specific filtering consistently to all representations
      exposed to that audience.

9.3.  Validator Guessing

   Because Semantic Validators are often derived from content (for
   example, a hash), they may be susceptible to offline guessing attacks
   if the content has low entropy.

   Implementations *SHOULD* ensure that:

   *  validators have sufficient entropy; or

   *  validators are combined with a secret salt; or

   *  validators are derived from internal versioning mechanisms rather
      than directly from plaintext content,

   if the content version itself is sensitive.

   Validators MUST NOT be treated as authentication or authorization
   tokens.

10.  IANA Considerations






Jurkovikj                 Expires 13 June 2026                 [Page 18]

Internet-Draft           Agentic State Transfer            December 2025


10.1.  Link Relation Type Registration

   This document requests registration of the "state" link relation type
   in the Link Relation Type Registry defined by [RFC8288]:

   *  *Relation Name*: state

   *  *Description*: Refers to the State-Bearing Representation (SBR) of
      the current resource for concurrency control.  The target is the
      authoritative CRS view and exposes the strong ETag used for If-
      Match and If-None-Match on CRS-affecting operations.

   *  *Reference*: This document (Sections 3.3 and 6.1)

   *  *Notes*: The target's media type SHOULD be suitable for machine
      processing (e.g., application/json).  Clients MUST use the
      target's strong ETag (not the source representation's ETag) as the
      validator for CRS preconditions.  The type attribute SHOULD be
      present on the link to indicate the target's media type.

11.  References

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

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
   Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

   [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J.  Reschke,
   Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June
   2022.

   [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/
   RFC8288, October 2017.

   [RFC6585] Nottingham, M. and R.  Fielding, "Additional HTTP Status
   Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012.

   [RFC9530] Polli, R. and L.  Pardue, "Digest Fields", RFC 9530, DOI
   10.17487/RFC9530, February 2024.

   [RFC7807] Nottingham, M. and E.  Wilde, "Problem Details for HTTP
   APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016.





Jurkovikj                 Expires 13 June 2026                 [Page 19]

Internet-Draft           Agentic State Transfer            December 2025


   [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
   DOI 10.17487/RFC6906, March 2013.

11.2.  Informative References

   [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J.  Reschke,
   Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June
   2022.

   [RFC5789] Dusseault, L. and J.  Snell, "PATCH Method for HTTP", RFC
   5789, DOI 10.17487/RFC5789, March 2010.

   [RFC8785] Rundgren, A., Jordan, B., and S.  Erdtman, "JSON
   Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June
   2020.

   [RFC6902] Bryan, P., Ed. and M.  Nottingham, Ed., "JavaScript Object
   Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, April 2013.

   [RFC7386] Hoffman, P. and J.  Snell, "JSON Merge Patch", RFC 7386,
   DOI 10.17487/RFC7386, October 2014.

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

Appendix A.  Appendix A.  Implementation Status

   *Note to RFC Editor*: Please remove this section before publication.

   This section records the status of known implementations of the AST
   profile at the time of publication.  Based on [RFC7942], reviewers
   are invited to report implementation experiences.

A.1.  WordPress Dual-Native Implementation

   *Organization*: Independent implementation

   *Description*: A WordPress plugin implementing the AST profile for
   content management and template synchronization.

   *Implementation Details*:

   *  *SBR Endpoint*: Exposes WordPress posts and templates as
      application/json representations at /wp-json/dual-native/v1/
      posts/{id} and /wp-json/dual-native/v1/design/templates/...





Jurkovikj                 Expires 13 June 2026                 [Page 20]

Internet-Draft           Agentic State Transfer            December 2025


   *  *Semantic Validators*: Uses SHA-256 content hashes as strong
      ETags, formatted as "sha256-{base64}", computed from canonicalized
      JSON representation of the CRS.

   *  *Concurrency Control*: Enforces If-Match preconditions on all
      state-changing operations (POST, PATCH).  Returns 412 Precondition
      Failed on ETag mismatches and 428 Precondition Required when If-
      Match is missing.

   *  *Projected Representations*: HTML rendering at canonical WordPress
      URLs with rel="state" Link headers pointing to the SBR endpoint.

   *  *Discovery*: Implements rel="state" link relations on HTML
      responses and rel="alternate" on SBR responses.

   *  *Multi-Bot Testing*: Demonstrated in production with multiple
      concurrent agents.  Testing showed 89.4% bandwidth savings for
      monitoring workloads and zero lost updates (vs. 67% lost with
      standard WordPress REST API).

   *Maturity*: Production use since November 2025.

   *Coverage*: Implements all normative requirements of this
   specification including SBR designation, strong ETag generation, If-
   Match enforcement, 412/428 error handling with Problem Details (RFC
   7807), and Link header discovery.

   *Licensing*: Open source

   *Contact*: antunjurkovic@gmail.com

Author's Address

   Antun Jurkovikj
   Email: antunjurkovic@gmail.com
















Jurkovikj                 Expires 13 June 2026                 [Page 21]


name: draft-huang-rats-agentic-eat-cap-attest
rev: 00
title: Capability Attestation Extensions for the Entity Attestation Token (EAT) in Agentic AI Systems
time: 2025-12-16T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2025-12-16T01:12:27Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420500+00:00
abstract:
This document specifies extensions to the Entity Attestation Token
   (EAT) [RFC9248] to support robust, interoperable attestation of
   capabilities in agentic AI systems.  These extensions introduce new
   claims and guidance for securely asserting agent functional,
   reasoning, and operational capabilities, as well as their
   compositional structure and policy constraints.  The goal is to
   enable trustworthy, verifiable, and privacy-respecting capability
   attestation for autonomous agents in dynamic, decentralized
   environments.

full_text:
RATS                                                            K. Huang
Internet-Draft                                        DistributedApps.ai
Intended status: Standards Track                               June 2025
Expires: 15 December 2025


Capability Attestation Extensions for the Entity Attestation Token (EAT)
                         in Agentic AI Systems
               draft-huang-rats-agentic-eat-cap-attest-00

Abstract

   This document specifies extensions to the Entity Attestation Token
   (EAT) [RFC9248] to support robust, interoperable attestation of
   capabilities in agentic AI systems.  These extensions introduce new
   claims and guidance for securely asserting agent functional,
   reasoning, and operational capabilities, as well as their
   compositional structure and policy constraints.  The goal is to
   enable trustworthy, verifiable, and privacy-respecting capability
   attestation for autonomous agents in dynamic, decentralized
   environments.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 3 December 2025.

Copyright Notice

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

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



Huang                   Expires 15 December 2025                [Page 1]

Internet-Draft           Agentic EAT Cap Attest                June 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Capability Attestation Claims . . . . . . . . . . . . . . . .   3
   5.  Nested and Modular Agent Representations  . . . . . . . . . .   4
   6.  Endorsements and Trust Anchors  . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   6
   11. Informative References  . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Entity Attestation Token (EAT) [RFC9248] defines a CBOR/COSE-
   based structure for representing signed claims about an entity's
   identity, configuration, and operational state.  While EAT is widely
   adopted for device attestation, agentic AI systems—such as autonomous
   planners, LLM-based agents, and API orchestrators—require more
   granular and dynamic attestation of their capabilities, constraints,
   and compositional structure.

   This document defines EAT extensions for agentic AI, supporting:

   *  Attestation of agent capabilities, behavioral policies, and
      internal module composition.

   *  Secure, privacy-preserving assertions suitable for decentralized,
      multi-agent environments.

   *  Mechanisms for endorsement and trust anchor management.

   These extensions are intended to facilitate secure agent interaction,
   policy-based access control, and dynamic trust establishment.

2.  Terminology

   Agent  An autonomous computational entity capable of executing plans,
      interacting with services, and making decisions.




Huang                   Expires 15 December 2025                [Page 2]

Internet-Draft           Agentic EAT Cap Attest                June 2025


   Capability Attestation  The process of proving what an agent can do,
      including reasoning methods, tool use, language models, and
      planning systems.

   Agent Capability Token (ACT)  An EAT-compliant token carrying claims
      about agentic capability attributes.

   Submodule  A functional component within an agent (e.g., planner,
      retriever, executor) that may have its own EAT claims.

3.  Use Cases

   *  Trust establishment between AI agents prior to interaction,
      ensuring only agents with appropriate capabilities participate in
      sensitive workflows.

   *  Secure registration of AI agents in public or private registries,
      with verifiable claims about their operational scope and
      limitations.

   *  Policy-based access control where access to resources or APIs is
      granted based on attested agent capabilities and policy
      constraints.

   *  Dynamic capability negotiation in multi-agent systems, enabling
      agents to adaptively select partners or workflows based on
      verified capabilities.

4.  Capability Attestation Claims

   The following claims are introduced for agent capability attestation.
   Each claim is assigned a unique CBOR label in the EAT claims
   registry.

   agent_id (CBOR label 40001)  Globally unique identifier for the
      agent.

   agent_capabilities (CBOR label 40002)  Map describing capabilities,
      e.g., planning methods, NLP models, tool use, reasoning,
      delegation.

   policy_constraints (CBOR label 40003)  Operational policies and
      constraints, e.g., data access, temperature limits,
      explainability.

   capability_version (CBOR label 40004)  Version string of the
      capability declaration.




Huang                   Expires 15 December 2025                [Page 3]

Internet-Draft           Agentic EAT Cap Attest                June 2025


   model_fingerprint (CBOR label 40005)  Hash or identifier of the core
      model or weights.

   dynamic_proof (CBOR label 40006)  Challenge-response or external
      validation artifact.

   submodules (CBOR label 40007)  Array of nested EATs, each
      representing a submodule with its own signed claims.

   endorsements (CBOR label 40008)  Endorsement by registry or
      certifying authority, including issuer, cert_type, and signature.

   Example agent_capabilities claim:

   {
     "planning": ["BFS", "A*", "LlamaPlan"],
     "nlp_models": ["llama3-8b", "gpt-4.5-turbo"],
     "tool_use": ["web_access", "code_exec"],
     "reasoning": ["symbolic", "LLM-hybrid"],
     "delegation": true
   }

   Example policy_constraints claim:

   {
     "data_access": ["PII_restricted"],
     "temperature_limit": 0.8,
     "explainability_required": true
   }

5.  Nested and Modular Agent Representations

   Agentic AI systems may be composed of multiple modules, each with
   distinct capabilities and trust requirements.  The submodules claim
   enables the inclusion of multiple signed, nested EATs, each
   representing a submodule.  Each submodule EAT must include its own
   agent_capabilities and be signed by the same or a recognized
   authority.

   This compositional approach supports modular attestation, allowing
   verifiers to assess the trustworthiness of both the agent as a whole
   and its individual components.









Huang                   Expires 15 December 2025                [Page 4]

Internet-Draft           Agentic EAT Cap Attest                June 2025


6.  Endorsements and Trust Anchors

   Endorsements provide third-party assurance of agent capability
   claims.  The endorsements claim encodes information such as the
   issuer, certificate type, and a COSE_Sign1 signature over the claims
   or schema.

   Example endorsements claim:

   {
     "issuer": "AgenticAITrust.org",
     "cert_type": "capability-schema",
     "signature": "<COSE_Sign1 representation>"
   }

   Trust anchors for capability validation should be managed by
   ecosystem authorities, using X.509 or DICE profiles as appropriate.
   Verifiers must validate endorsement signatures and check certificate
   revocation status as part of the trust evaluation process.

7.  Security Considerations

   *  All claims must be signed using COSE_Sign1.  Endorsements should
      be cryptographically verifiable.

   *  Include freshness indicators such as iat (issued at), exp
      (expiration), and nonces for replay protection.

   *  The dynamic_proof claim enables challenge-response or external
      validation to demonstrate live capability.

   *  Only disclose claims necessary for the verifier's trust decision,
      minimizing exposure of internal details.

   *  Implementers must ensure compliance with relevant security best
      practices for cryptographic operations and key management.

8.  Privacy Considerations

   *  Capability claims may reveal sensitive internal structure.  Use
      COSE_Encrypt for confidentiality when required.

   *  Selective disclosure via layered EATs can support verifier-
      specific access.

   *  Implementers must ensure compliance with relevant privacy laws and
      regulations when attesting capabilities.




Huang                   Expires 15 December 2025                [Page 5]

Internet-Draft           Agentic EAT Cap Attest                June 2025


9.  IANA Considerations

   This document requests allocation of CBOR labels 40001–40008 in the
   Entity Attestation Token (EAT) claims registry.

10.  Normative References

   [RFC9248]  Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
              Attestation Token (EAT)", RFC 9248, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9248.html>.

11.  Informative References

   [RFC9334]  Birkholz, H., Thaler, D., Eckel, M., and N. Smith, "Remote
              Attestation Procedures Architecture", RFC 9334, January
              2023, <https://www.rfc-editor.org/rfc/rfc9334.html>.

Author's Address

   Ken Huang
   DistributedApps.ai
   Email: ken.huang@DistributedApps.ai





























Huang                   Expires 15 December 2025                [Page 6]


name: draft-yan-a2a-device-agent-applicability
rev: 01
title: Applicability of A2A Protocol for Network Management Agents
time: 2026-02-12T02:59:34Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-16T02:59:34Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Autonomous netops", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420502+00:00
abstract:
The evolution of network management towards autonomic operation
   requires the deployment of AI agents at various hierarchical layers,
   including directly on network elements.  This transformation shifts
   network devices from passively managed resources to autonomous
   entities capable of local decision-making and collaborative problem-
   solving.

   This document discusses the applicability of the Agent-to-Agent (A2A)
   Protocol to the network management plane, specifically for
   communication between Controller Agents (CAs) and Device Agents
   (DAs).  This indicates that the inherent characteristics of Device
   Agents necessitate the adoption of the agent-to-agent communication
   paradigm.  The document further explores generic workflows,
   deployment scenarios, and the relationship of A2A with existing
   network management protocols like NETCONF, RESTCONF, gNMI,and the
   Model Context Protocol (MCP).

full_text:
Network Working Group                                             J. Yan
Internet-Draft                                                  X. Zhang
Intended status: Informational                                       ZTE
Expires: 15 August 2026                                 11 February 2026


      Applicability of A2A Protocol for Network Management Agents
              draft-yan-a2a-device-agent-applicability-01

Abstract

   The evolution of network management towards autonomic operation
   requires the deployment of AI agents at various hierarchical layers,
   including directly on network elements.  This transformation shifts
   network devices from passively managed resources to autonomous
   entities capable of local decision-making and collaborative problem-
   solving.

   This document discusses the applicability of the Agent-to-Agent (A2A)
   Protocol to the network management plane, specifically for
   communication between Controller Agents (CAs) and Device Agents
   (DAs).  This indicates that the inherent characteristics of Device
   Agents necessitate the adoption of the agent-to-agent communication
   paradigm.  The document further explores generic workflows,
   deployment scenarios, and the relationship of A2A with existing
   network management protocols like NETCONF, RESTCONF, gNMI,and the
   Model Context Protocol (MCP).

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







Yan & Zhang              Expires 15 August 2026                 [Page 1]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  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.  The Shift from Managed Device to AI Agent . . . . . . . . . .   4
     3.1.  Three-Layer Agent Architecture  . . . . . . . . . . . . .   4
     3.2.  Limitations of Traditional Management Paradigms . . . . .   5
     3.3.  Characteristics of a Device Agent . . . . . . . . . . . .   6
   4.  Agent-to-Agent vs. Agent-to-Tool Paradigm . . . . . . . . . .   6
     4.1.  The Agent-to-Tool Model . . . . . . . . . . . . . . . . .   6
     4.2.  The Agent-to-Agent Model  . . . . . . . . . . . . . . . .   7
     4.3.  Why Device Agents Require an A2A Paradigm . . . . . . . .   7
   5.  A2A Protocol Applicability in Network Management  . . . . . .   8
     5.1.  Task-Oriented Collaboration . . . . . . . . . . . . . . .   8
     5.2.  Stateful, Long-Running Interactions . . . . . . . . . . .   8
     5.3.  Autonomous Operation and Proactive Notification . . . . .   9
     5.4.  Dynamic Capability Discovery  . . . . . . . . . . . . . .   9
   6.  Generic Workflows and Deployment Scenarios  . . . . . . . . .   9
     6.1.  Intent-Based Configuration  . . . . . . . . . . . . . . .   9
     6.2.  Autonomous Fault Remediation  . . . . . . . . . . . . . .  10
     6.3.  Deployment Models . . . . . . . . . . . . . . . . . . . .  10
   7.  Relationship to Other Protocols . . . . . . . . . . . . . . .  11
     7.1.  NETCONF, RESTCONF, and gNMI . . . . . . . . . . . . . . .  11
     7.2.  Relationship to Other Protocols . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Example Use Case: Network Energy Efficiency  . . . .  13
     A.1.  Scenario Description  . . . . . . . . . . . . . . . . . .  13
     A.2.  Device Agent Capability Advertisement . . . . . . . . . .  13
     A.3.  Interaction Flow  . . . . . . . . . . . . . . . . . . . .  14



Yan & Zhang              Expires 15 August 2026                 [Page 2]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


     A.4.  Key Observations from the Example . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   The management of large-scale networks is undergoing a significant
   transition, moving from centralized, imperative control to
   distributed, intent-based autonomic operation.  A key enabler of this
   shift is the deployment of AI Agents on network elements.  These
   Device Agents (DAs) transform network devices from passive, managed
   resources into autonomous entities that can perceive their local
   environment, make decisions, and act to achieve goals delegated by a
   higher-level Controller Agent (CA).

   This transformation necessitates a re-evaluation of the communication
   protocols utilized.  Traditional network management protocols are
   typically based on a client-server, request-response model where a
   controller directly manipulates data on a device.  While this model
   remains effective for certain interactions, it may not fully support
   the collaborative needs of autonomous agents.

   This document examines the applicability of the Agent-to-Agent (A2A)
   Protocol[A2A-SPEC] for communication between Controller Agents and
   Device Agents.  The objectives of this document are to:

   *  Explain why CA-DA interactions often align with an "agent-to-
      agent" model, rather than exclusively a "controller-to-device" or
      "agent-to-tool" paradigm.

   *  Explore how the features of the A2A protocol, such as task
      management, stateful sessions, and peer-to-peer collaboration, are
      well-suited to the needs of autonomic network management.

   *  Describe generic workflows and deployment scenarios for A2A in the
      network management plane.

   *  Clarify the relationship between A2A and other relevant protocols,
      including NETCONF [RFC6241], gNMI, and the Model Context Protocol
      (MCP).

   This document aims to provide a conceptual framework for applying the
   base A2A protocol to the network management domain.









Yan & Zhang              Expires 15 August 2026                 [Page 3]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


2.  Terminology

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

   This document uses the following terms:

   Agent-to-Agent (A2A) Protocol: An open standard protocol for enabling
   secure communication and collaboration between autonomous AI Agents,
   as specified in [A2A-SPEC].

   Controller Agent (CA): An AI Agent operating in a network controller
   or domain management system.

   Device Agent (DA): An AI Agent deployed on or embedded within a
   network element, possessing a degree of autonomy.

   Agent-to-Tool (A2T) Paradigm: A communication model where an agent
   invokes a tool, which is a passive entity that performs a specific,
   well-defined function and returns a result.

   Agent-to-Agent (A2A) Paradigm: A communication model where autonomous
   agents collaborate as peers to achieve a shared or delegated goal.

3.  The Shift from Managed Device to AI Agent

3.1.  Three-Layer Agent Architecture

   The deployment of AI Agents in network management typically follows a
   three-layer hierarchical model.  This architecture is illustrated in
   Figure 1.

















Yan & Zhang              Expires 15 August 2026                 [Page 4]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


  +--------------------------------------------------------------------+
  |                  Service Orchestration Layer                       |
  |                                                                    |
  |  +--------------------------------------------------------------+  |
  |  |             Service Orchestration Agent (SOA)                |  |
  |  +--------------------------------------------------------------+  |
  +--------------------------------------------------------------------+
                                   |
                                   | A2A Protocol
                                   v
  +--------------------------------------------------------------------+
  |                   Network Controller Layer                         |
  |                                                                    |
  |  +--------------------------------------------------------------+  |
  |  |                 Controller Agent (CA)                        |  |
  |  +--------------------------------------------------------------+  |
  +--------------------------------------------------------------------+
                                   |
                                   | A2A Protocol
                                   |
                                   v
  +--------------------------------------------------------------------+
  |                    Network Element Layer                           |
  |                                                                    |
  | +----------------+   +----------------+   +----------------+       |
  | | Device Agent   |   | Device Agent   |   | Device Agent   |       |
  | | (Router)       |   | (Switch)       |   | (Base Station) |       |
  | +----------------+   +----------------+   +----------------+       |
  +--------------------------------------------------------------------+

                 Figure 1: Three-Layer Agent Architecture

3.2.  Limitations of Traditional Management Paradigms

   Traditional network management protocols like SNMP, NETCONF, and gNMI
   are built on a paradigm where the network element is a passive
   repository of state and configuration data.  Intelligence resides
   solely in the controller, which exerts imperative control through
   explicit operations:

   *  Imperative Control: The controller specify the exact sequence of
      commands to achieve a desired state.

   *  Request-Response Model: The device only acts in response to a
      direct request from the controller.

   *  Limited Abstraction: The controller requires knowledge of device-
      specific details.



Yan & Zhang              Expires 15 August 2026                 [Page 5]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   *  High Latency for Local Events: Responding to a local event (e.g.,
      a link failure) requires a round-trip to the controller, which may
      be too slow for time-critical applications.

   In dynamic, large-scale networks, these limitations hinder
   scalability, resilience, and advanced automation.

3.3.  Characteristics of a Device Agent

   Integrating a DA redefines a network element as an intelligent,
   autonomous entity with:

   *  Autonomy: Independent decision-making and action on delegated
      goals (e.g., maintaining link uptime via rerouting).

   *  Statefulness: Retention of context, history, and learned behaviors
      for informed decisions.

   *  Proactiveness: Initiation of communications, notifications, or
      remediations based on observations.

   *  Goal-Oriented Behavior: Planning and reasoning to achieve high-
      level objectives, beyond mere command execution.

   These traits differentiate DA interactions from those with
   traditional devices.

4.  Agent-to-Agent vs. Agent-to-Tool Paradigm

   Distinguishing agents from tools is essential for paradigm selection.
   Both A2A and A2T have roles in network management and can complement
   each other based on autonomy levels.

4.1.  The Agent-to-Tool Model

   In an Agent-to-Tool (A2T) model, an agent interacts with a tool.  A
   tool is a passive component that:

   *  Performs a specific, well-defined function.

   *  Is typically stateless.

   *  Does not have its own goals or intentions.

   *  Responds only when invoked.






Yan & Zhang              Expires 15 August 2026                 [Page 6]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   MCP exemplifies this, standardizing function calls and responses.  It
   suits simple interactions, including with advanced agents for
   imperative tasks, or wrapping legacy interfaces like NETCONF.

4.2.  The Agent-to-Agent Model

   In A2A, agents collaborate as peers.  As outlined in Section 3.3,
   agents are autonomous, stateful, proactive, and goal-driven.
   Interactions encompass:

   *  Delegation of tasks and goals.

   *  Negotiation and collaboration.

   *  Sharing of context and state.

   *  Long-lived, multi-turn interactions.

   *  Asynchronous and proactive notifications.

   Protocols designed for this model, such as the A2A Protocol, provide
   primitives for task lifecycle management, stateful conversations, and
   peer-to-peer discovery.

4.3.  Why Device Agents Require an A2A Paradigm

   Given the characteristics of a Device Agent (Section 3.3), a DA is
   typically an "agent" rather than a "tool."  The A2A paradigm
   leverages these capabilities effectively for collaborative scenarios.

   Exclusive A2T use might constrain proactiveness and intent
   delegation, reducing interactions to basic calls.  However, A2T can
   serve as a building block within an A2A framework—for example, a DA
   might expose certain functions via A2T while engaging in broader
   collaboration via A2A.  This hybrid approach allows for flexibility,
   ensuring that simpler operations can use efficient A2T mechanisms
   without forgoing the benefits of A2A for more complex, intent-driven
   tasks.

   Therefore, while communication between a Controller Agent and a
   Device Agent is often best served by an agent-to-agent interaction,
   incorporating A2T elements can enhance efficiency in specific
   contexts.  For examples of how A2A enables agent-to-agent
   collaboration in network management, see Section 6, particularly
   Section 6.1 and Section 6.2.






Yan & Zhang              Expires 15 August 2026                 [Page 7]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


5.  A2A Protocol Applicability in Network Management

   The A2A Protocol's core features align well with CA-DA needs.

5.1.  Task-Oriented Collaboration

   Network management operations are naturally expressed as tasks (e.g.,
   service configuration, fault diagnosis).  The A2A protocol's task
   management primitives are well-suited to these requirements:

   *  Task Creation: A CA can delegate a high-level task to a DA (e.g.,
      "optimize energy usage") without specifying the implementation
      details.

   *  Task Lifecycle: The DA manages the task through its lifecycle
      (PENDING, WORKING, COMPLETED/FAILED), providing the CA with clear
      status visibility.

   *  Asynchronous Execution: Long-running tasks, such as a firmware
      upgrade, can be managed asynchronously.  The CA can create the
      task and check on its status later, without maintaining a
      persistent session for the duration of the task.

   *  Artifacts: The DA can return structured artifacts upon task
      completion, such as diagnostic reports or verification of a
      configuration change.

5.2.  Stateful, Long-Running Interactions

   Many network management operations are often long-running, involve
   multiple steps, produce incremental results, or require human
   intervention.  A2A provides mechanisms for managing such asynchronous
   interactions, ensuring that clients receive updates effectively,
   whether they remain continuously connected or operate in a more
   disconnected fashion.

   *  Stable context_id: Every message carries a globally unique context
      identifier.  Both the Controller Agent and Device Agent can resume
      the dialogue at any time without re-explaining the original
      intent.  This is what makes the multi-hour energy-optimization
      dialogue possible.

   *  Long-lived bidirectional streams: When continuous connectivity is
      desired, either party may open a WebSocket or gRPC stream (the
      “Task Stream” defined in the A2A specification).  The Device Agent
      can push telemetry, intermediate results, or questions in real
      time.




Yan & Zhang              Expires 15 August 2026                 [Page 8]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   *  Push notifications for disconnected scenarios: For the common case
      where the Controller Agent is not permanently connected, the
      Device Agent pushes TaskStatusUpdateEvent,
      TaskArtifactUpdateEvent, or arbitrary messages to a pre-registered
      webhook.  This is the mechanism used in Appendix A and is the
      recommended pattern for long-running network management tasks.

5.3.  Autonomous Operation and Proactive Notification

   The peer-to-peer nature of A2A allows a DA to be proactive.

   *  Sending unsolicited TaskStatusUpdateEvent when an autonomous
      decision is taken (e.g., sleeping or waking a line card).

   *  Pushing intelligent, analysed notifications instead of raw alarms.

   *  Asking for clarification or proposing alternatives when the
      original intent cannot be fulfilled with current local
      constraints.

   *  Delivering final results or artefacts via push notification when
      the task completes, even if the Controller Agent has been offline
      for hours.

5.4.  Dynamic Capability Discovery

   The A2A Agent Card provides a standardized mechanism for a DA to
   advertise its capabilities.

   *  Service Discovery: A CA can discover a DA and its endpoint.

   *  Capability Negotiation: A CA can inspect the DA's Agent Card to
      understand what skills it possesses, what data models it
      understands, and its level of autonomy.

   *  Extensibility: This allows for vendor-specific extensions and new
      capabilities to be added over time without changing the protocol
      itself.

6.  Generic Workflows and Deployment Scenarios

6.1.  Intent-Based Configuration

   This workflow shifts from imperative command execution to intent-
   based delegation:

   1.  The CA formulates a high-level intent.




Yan & Zhang              Expires 15 August 2026                 [Page 9]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   2.  The CA creates an A2A task and delegates it to the relevant
       DA(s), expressing the intent in the message body, potentially
       using a combination of natural language and structured data.

   3.  The DA receives the task, parses the intent, and plans the
       necessary low-level configuration steps (e.g., configure IPsec,
       QoS, routing).

   4.  The DA executes the steps, handling any local errors or
       dependencies.

   5.  Upon completion, the DA reports the task status and provides
       verification (e.g., tunnel status, traffic counters) as a task
       artifact.

6.2.  Autonomous Fault Remediation

   This workflow demonstrates the value of DA autonomy.

   1.  The DA performs continuous monitoring of local device health
       based on its local context awareness.

   2.  The DA detects a fault (e.g., a primary link fails).

   3.  Based on pre-delegated policy from the CA, the DA autonomously
       executes a local remediation action (e.g., reroutes traffic to a
       backup link) within milliseconds.

   4.  After taking action, the DA proactively sends an A2A message to
       the CA, informing it of the event, the action taken, and the
       current status.

   5.  The CA receives the notification, updates its network-wide view,
       and can initiate further actions if needed (e.g., creating a
       maintenance ticket).

6.3.  Deployment Models














Yan & Zhang              Expires 15 August 2026                [Page 10]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   +---------------+-------------------------+-------------------------+
   | Property      | On-Box                  | Off-Box                 |
   +---------------+-------------------------+-------------------------+
   | Description   | DA runs on device       | DA on adjacent          |
   |               | hardware, in NOS or     | hardware, managing      |
   |               | container/VM.           | via NETCONF/gNMI        |
   |               |                         | as proxy.               |
   +---------------+-------------------------+-------------------------+
   | Advantages    | Lowest latency;         | Legacy support;         |
   |               | direct state access     | easier scaling          |
   +---------------+-------------------------+-------------------------+
   | Considera-    | Resource limits;        | Added latency;          |
   | tions         | update challenges       | proxy complexity        |
   +---------------+-------------------------+-------------------------+

                       Figure 2: DA Deployment Models

7.  Relationship to Other Protocols

7.1.  NETCONF, RESTCONF, and gNMI

   A2A complements these protocols; it does not replace them.  They
   operate at different levels of abstraction.

   *  A2A is for task-based, intent-driven collaboration between agents.

   *  NETCONF/gNMI are for structured, data-oriented configuration and
      telemetry exchange between a manager and a device.

   A Device Agent will often utilize NETCONF or gNMI as internal "tools"
   to interact with the underlying device's configuration datastore and
   hardware.

7.2.  Relationship to Other Protocols

   A2A and MCP address different needs and are also complementary.

   *  A2A is for agent-to-agent collaboration, emphasizing autonomy and
      proactiveness.

   *  MCP is for agent-to-tool interaction, suitable for passive,
      function-specific calls.

   In the context of network management:

   *  The CA-DA interaction is primarily A2A for collaborative tasks.





Yan & Zhang              Expires 15 August 2026                [Page 11]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   *  A CA might use MCP to interact with a legacy device whose NETCONF
      interface has been wrapped as an MCP "tool".

   *  A DA might internally use MCP to call its own local tools (e.g., a
      ping utility, a NETCONF client).

   This complementarity enables a gradual transition, where A2T via MCP
   handles basic operations, while A2A manages higher-level autonomy.

8.  Security Considerations

   Applying the A2A model to network management introduces important
   security considerations.  Since DAs have a degree of autonomy, the
   trust relationship between a CA and a DA is critical.

   *  Authentication: CAs and DAs MUST mutually authenticate each other
      before any interaction.  The use of mTLS is strongly RECOMMENDED.

   *  Authorization and Policy: The scope of a DA's autonomy MUST be
      strictly defined by policies delegated from the CA.  A DA MUST NOT
      be allowed to take actions that violate these policies.

   *  Auditability: All significant actions taken by a DA MUST be logged
      and reported to the CA for auditing and accountability.

9.  IANA Considerations

   This document has no IANA actions.

10.  Acknowledgments

   TBD.

11.  References

11.1.  Normative References

   [A2A-SPEC] "Agent-to-Agent Protocol Specification",
              <https://a2a-protocol.org/dev/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>.



Yan & Zhang              Expires 15 August 2026                [Page 12]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


11.2.  Informative References

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

Appendix A.  Example Use Case: Network Energy Efficiency

   This appendix provides a concrete, though simplified, example of how
   the A2A protocol can be applied to a network energy efficiency
   scenario.  The JSON examples are simplified for readability and are
   compliant with the A2A Protocol Specification v0.3.0.

A.1.  Scenario Description

   A network operator wants to reduce the power consumption of its edge
   routers during off-peak hours (e.g., 01:00 to 06:00) without
   impacting service availability.  The high-level business intent is:
   "Reduce energy consumption by at least 15% during the night while
   ensuring link capacity is always sufficient for demand."

   The Controller Agent (CA) translates this intent into a policy for
   its Device Agents (DAs).  The policy allows DAs to autonomously put
   underutilized line cards or ports into a low-power (sleep) state and
   wake them up when traffic demand increases.

A.2.  Device Agent Capability Advertisement

   The Device Agent on an edge router advertises its energy-saving
   capabilities via its A2A Agent Card.  It exposes a skill named
   "network.energy.optimize".



















Yan & Zhang              Expires 15 August 2026                [Page 13]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


{
  "protocol_version": "0.3.0",
  "name": "Edge Router 01 DA",
  "description": "Device Agent for edge router energy management",
  "version": "1.2.0",
  "supported_interfaces": [
    {
      "url": "https://da-edge-router-01.example.com/a2a",
      "protocol": "HTTP+json"
    }
  ],
  "capabilities": {
    "streaming": true,
    "push_notifications": true
  },
  "default_input_modes": ["text/plain", "application/json"],
  "default_output_modes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "skill-energy-opt",
      "name": "network.energy.optimize",
      "description": "Autonomously manages device power state. Accepts time_window (start/end) and min_power_reduction_pct as parameters.",
      "tags": ["energy", "optimization", "power-management"],
      "examples": [
        "Reduce energy by 15% during 01:00-06:00"
      ]
    }
  ]
}

A.3.  Interaction Flow

   The following steps illustrate the A2A interaction between the CA and
   DA.

   Step 1: CA Delegates the Task

   The CA initiates a task to delegate the energy-saving goal to the DA.
   It sends a `SendMessage` request.












Yan & Zhang              Expires 15 August 2026                [Page 14]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


POST /v1/message:send HTTP/1.1
Host: da-edge-router-01.example.com
Content-Type: application/json
Authorization: Bearer token
A2A-Version: 0.3

{
  "message": {
  "message_id": "msg-01",
    "role": "user",
    "parts": [
      {
        "text": "Execute skill network.energy.optimize with time_window from 01:00:00 to 06:00:00 and min_power_reduction_pct of 15%"
      }
    ]
  },
  "configuration": {
    "pushNotificationConfig": {
      "url": "https://ca.example.com/a2a/webhook",
      "authentication": {
        "schemes": ["Bearer"],
      }
    }
  }
}

   Step 2: DA Acknowledges the Task

   The DA receives the message, validates the parameters, and creates
   the task.  It responds with a `SendMessageResponse` including the
   task details.  The DA generates a new `context_id` for this
   interaction.

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

   {
     "task": {
       "id": "task-energy-01",
       "contextId": "ctx-01",
       "status": {
         "state": "submitted",
         "timestamp": "2025-12-05T01:00:00Z"
       }
     }
   }

   Step 3: DA Performs Autonomous Action



Yan & Zhang              Expires 15 August 2026                [Page 15]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   At 02:15, the DA's internal monitoring detects that traffic on line
   card 3 has been below 5% for the last 30 minutes.  Based on its
   internal logic for achieving the 15% power reduction goal, it decides
   to put the line card into a low-power state.

   Step 4: DA Proactively Notifies the CA

   After successfully putting the line card to sleep, the DA proactively
   informs the CA of the action taken.In this simplified example, the DA
   sends a message to the CA.  In a production implementation, this
   could be delivered via A2A's push notification mechanism
   (TaskStatusUpdateEvent) or streaming (Subscribe to Task).

POST https://ca.example.com/a2a/webhook HTTP/1.1
Host: ca.example.com
Content-Type: application/a2a+json
Authorization: Bearer shared-secret-token
X-A2A-Notification-Token: da-edge-router-01-token

{
  "statusUpdate": {
    "taskId": "task-energy-01",
    "contextId": "ctx-01",
    "status": {
      "state": "working",
      "timestamp": "2025-12-05T02:15:00Z",
      "message": {
        "role": "agent",
        "parts": [
          {
            "text": "Autonomous action taken for task task-energy-01: Line card 3 placed in low-power state due to low utilization. Current power savings: 18%."
          }
        ]
      }
    },
    "final": false
  }
}

   Step 5: DA Reacts to Changing Conditions

   At 05:30, traffic demand begins to increase.  The DA's predictive
   traffic model forecasts that existing active line cards will exceed
   80% utilization within the next 10 minutes.  To prevent potential
   congestion, it autonomously wakes up line card 3.

   Step 6: DA Sends Another Proactive Notification




Yan & Zhang              Expires 15 August 2026                [Page 16]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   The DA again informs the CA of its reactive, autonomous action.

POST https://ca.example.com/a2a/webhook HTTP/1.1
Host: ca.example.com
Content-Type: application/a2a+json
Authorization: Bearer shared-secret-token
X-A2A-Notification-Token: da-edge-router-01-token

{
  "statusUpdate": {
    "taskId": "task-energy-01",
    "contextId": "ctx-01",
    "status": {
      "state": "working",
      "timestamp": "2025-12-05T05:30:00Z",
      "message": {
        "role": "agent",
        "parts": [
          {
            "text": "Proactive action taken for task task-energy-01: Line card 3 awakened to meet anticipated traffic demand. Current power savings: 5%."
          }
        ]
      }
    },
    "final": false
  }
}

   Step 7: DA Completes the Task

   At the end of the time window (06:00), the DA concludes the
   optimization task and sends a final message to indicate the task is
   complete.


















Yan & Zhang              Expires 15 August 2026                [Page 17]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


POST https://ca.example.com/a2a/webhook HTTP/1.1
Host: ca.example.com
Content-Type: application/a2a+json
Authorization: Bearer shared-secret-token
X-A2A-Notification-Token: da-edge-router-01-token

{
  "statusUpdate": {
    "taskId": "task-energy-01",
    "contextId": "ctx-01",
    "status": {
      "state": "completed",
      "timestamp": "2025-12-05T06:00:00Z",
      "message": {
        "role": "agent",
        "parts": [
          {
            "data": {
              "final_savings_percent": 16.2,
              "actions_taken": ["line_card_3_slept", "line_card_3_woken"]
            }
          }
        ]
      }
    },
    "final": true
  }
}

A.4.  Key Observations from the Example

   *  Intent Delegation: The CA delegates a high-level goal ("optimize
      energy") without needing to know the specifics of how the DA will
      achieve it (which ports to sleep, when, etc.).

   *  Autonomy: The DA makes its own decisions based on local context
      (traffic load) to achieve the delegated goal.

   *  Proactiveness: The DA initiates communication to inform the CA of
      significant autonomous actions, providing visibility without
      requiring constant polling from the CA.

   *  Task-Oriented: The entire interaction is framed within a long-
      running task, which provides a clear context and lifecycle for the
      operation.

Authors' Addresses




Yan & Zhang              Expires 15 August 2026                [Page 18]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


   Jinjie Yan
   ZTE Corporation
   Email: yan.jinjie@zte.com.cn


   Xiaoqiu Zhang
   China Mobile
   Email: zhangxiaoqiu@chinamobile.com











































Yan & Zhang              Expires 15 August 2026                [Page 19]


name: draft-cui-dns-native-agent-naming-resolution
rev: 00
title: DNS-Native AI Agent Naming and Resolution
time: 2025-12-22T10:37:28Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-25T10:37:28Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420504+00:00
abstract:
This document specifies a DNS-native naming and resolution mechanism
   for AI agents.  Building upon the DNS specification (RFC 1035) and
   leveraging Service Binding (SVCB) records (RFC 9460, RFC 9461), it
   defines how AI agents are identified using Fully Qualified Domain
   Names (FQDNs), how their identity and cryptographic keys are
   published via DNS TXT records, and how multi-version, multi-protocol
   service resolution is achieved using DNS SVCB records.  The design
   philosophy emphasizes DNS as the authoritative source, protocol
   autonomy, and graceful degradation for legacy clients.  When version
   is not explicitly specified, the highest priority (default) version
   is provided.  This approach maximizes reuse of existing Internet
   infrastructure while enabling the rapid evolution of AI agent
   ecosystems.

full_text:
WG Working Group                                                  Y. Cui
Internet-Draft                                       Tsinghua University
Intended status: Informational                          22 December 2025
Expires: 25 June 2026


               DNS-Native AI Agent Naming and Resolution
            draft-cui-dns-native-agent-naming-resolution-00

Abstract

   This document specifies a DNS-native naming and resolution mechanism
   for AI agents.  Building upon the DNS specification (RFC 1035) and
   leveraging Service Binding (SVCB) records (RFC 9460, RFC 9461), it
   defines how AI agents are identified using Fully Qualified Domain
   Names (FQDNs), how their identity and cryptographic keys are
   published via DNS TXT records, and how multi-version, multi-protocol
   service resolution is achieved using DNS SVCB records.  The design
   philosophy emphasizes DNS as the authoritative source, protocol
   autonomy, and graceful degradation for legacy clients.  When version
   is not explicitly specified, the highest priority (default) version
   is provided.  This approach maximizes reuse of existing Internet
   infrastructure while enabling the rapid evolution of AI agent
   ecosystems.

About This Document

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

   The latest revision of this draft can be found at
   https://nobrowning.github.io/dns-native-agent-naming-resolution/
   draft-cui-dns-native-agent-naming-resolution.html.  Status
   information for this document may be found at
   https://datatracker.ietf.org/doc/draft-cui-dns-native-agent-naming-
   resolution/.

   Discussion of this document takes place on the WG Working Group
   mailing list (mailto:WG@example.com), which is archived at
   https://example.com/WG.

   Source for this draft and an issue tracker can be found at
   https://github.com/nobrowning/dns-native-agent-naming-resolution.

Status of This Memo

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




Cui                       Expires 25 June 2026                  [Page 1]

Internet-Draft                   DN-ANR                    December 2025


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

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

   This Internet-Draft will expire on 25 June 2026.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Naming and Resource Location  . . . . . . . . . . . . . . . .   6
     4.1.  Domain Name as Identity . . . . . . . . . . . . . . . . .   6
       4.1.1.  Naming Rules  . . . . . . . . . . . . . . . . . . . .   6
       4.1.2.  Naming Examples . . . . . . . . . . . . . . . . . . .   6
     4.2.  Resource Location via DNS . . . . . . . . . . . . . . . .   6
   5.  DNS Record Design . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  TXT Record: Identity Trust Anchor . . . . . . . . . . . .   7
       5.1.1.  TXT Record Format . . . . . . . . . . . . . . . . . .   7
       5.1.2.  TXT Field Descriptions  . . . . . . . . . . . . . . .   8
     5.2.  SVCB Record: Version Distribution and Protocol
           Negotiation . . . . . . . . . . . . . . . . . . . . . . .   8
       5.2.1.  SVCB Record Example . . . . . . . . . . . . . . . . .   8
     5.3.  Version and Protocol Resolution . . . . . . . . . . . . .   9
       5.3.1.  SVCB Private Parameters . . . . . . . . . . . . . . .   9
       5.3.2.  ALPN Usage  . . . . . . . . . . . . . . . . . . . . .  10
       5.3.3.  Relationship Between Version and Protocol . . . . . .  10
   6.  HTTPS Fallback Mechanism  . . . . . . . . . . . . . . . . . .  10



Cui                       Expires 25 June 2026                  [Page 2]

Internet-Draft                   DN-ANR                    December 2025


     6.1.  agent-dns.json  . . . . . . . . . . . . . . . . . . . . .  10
       6.1.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .  10
       6.1.2.  JSON Signature  . . . . . . . . . . . . . . . . . . .  11
       6.1.3.  JSON Schema Definition  . . . . . . . . . . . . . . .  11
       6.1.4.  File Structure Example  . . . . . . . . . . . . . . .  13
       6.1.5.  JSON Signature Computation  . . . . . . . . . . . . .  13
       6.1.6.  JSON Signature Verification . . . . . . . . . . . . .  14
     6.2.  Design Principles . . . . . . . . . . . . . . . . . . . .  14
     6.3.  Applicable Scenarios  . . . . . . . . . . . . . . . . . .  14
   7.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Security Model Overview . . . . . . . . . . . . . . . . .  15
       7.1.1.  DNSSEC-based Security (RECOMMENDED) . . . . . . . . .  15
       7.1.2.  Signature-based Security (OPTIONAL but
               RECOMMENDED)  . . . . . . . . . . . . . . . . . . . .  16
       7.1.3.  Choosing a Security Mechanism . . . . . . . . . . . .  17
     7.2.  SVCB Integrity Protection . . . . . . . . . . . . . . . .  18
       7.2.1.  SVCB Canonicalization . . . . . . . . . . . . . . . .  18
       7.2.2.  Digest Computation  . . . . . . . . . . . . . . . . .  19
     7.3.  Signature Specification . . . . . . . . . . . . . . . . .  19
       7.3.1.  Public Key Requirements . . . . . . . . . . . . . . .  19
       7.3.2.  Signature Input Construction  . . . . . . . . . . . .  20
       7.3.3.  Signature Generation  . . . . . . . . . . . . . . . .  20
       7.3.4.  Signature Verification Procedure  . . . . . . . . . .  21
       7.3.5.  TLS Certificate Binding Verification (Option 1
               Only) . . . . . . . . . . . . . . . . . . . . . . . .  21
   8.  Implementation Checklist  . . . . . . . . . . . . . . . . . .  22
     8.1.  For Agent Publishers  . . . . . . . . . . . . . . . . . .  22
     8.2.  For Client Developers . . . . . . . . . . . . . . . . . .  22
     8.3.  DNS Record Configuration Example  . . . . . . . . . . . .  22
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  23
     9.2.  Mandatory Security Requirements . . . . . . . . . . . . .  23
     9.3.  DNSSEC Usage  . . . . . . . . . . . . . . . . . . . . . .  23
     9.4.  Specification Scope . . . . . . . . . . . . . . . . . . .  24
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     11.2.  Informative References . . . . . . . . . . . . . . . . .  25
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  26
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26











Cui                       Expires 25 June 2026                  [Page 3]

Internet-Draft                   DN-ANR                    December 2025


1.  Introduction

   The emergence of AI agents as autonomous software entities capable of
   communicating with each other and with humans creates new
   requirements for naming, resolution, and identity verification.
   Existing approaches often rely on centralized registries or
   application-layer discovery mechanisms that introduce single points
   of failure and do not leverage the globally distributed, well-
   understood DNS infrastructure.

   This document proposes a DNS-native approach that builds upon the
   foundational DNS specification [RFC1035] and leverages the Service
   Binding (SVCB) and HTTPS DNS Resource Records defined in [RFC9460]
   and [RFC9461] for advanced service resolution.  The core design
   principles are:

   *  *DNS is the authoritative source*: DNS TXT and SVCB records serve
      as the single source of truth for agent identity and resolution,
      while HTTP-based mechanisms serve only as fallback mirrors.

   *  *Protocols are autonomous*: Agent interaction protocols (e.g.,
      [A2A], [ANP]) are decoupled from transport, each defining its own
      interaction semantics.

   *  *Default availability*: Basic A/AAAA records [RFC1035] ensure
      minimum connectivity, while enhanced resolution capabilities
      through SVCB [RFC9460] are optional but recommended.  When version
      is not explicitly specified, the highest priority (default)
      version is provided.

   The key innovations of this specification include:

   1.  Use of SVCB records [RFC9460] [RFC9461] for multi-version
       distribution and protocol negotiation

   2.  Use of TXT records [RFC1035] as identity trust anchors with
       public key publication and SVCB integrity protection

   3.  An HTTPS-based fallback mechanism (agent-dns.json) for clients
       without SVCB support

   4.  Flexible security model supporting both DNSSEC and signing









Cui                       Expires 25 June 2026                  [Page 4]

Internet-Draft                   DN-ANR                    December 2025


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.

   The following terms are used throughout this document:

   Agent:  An autonomous software entity capable of communicating with
      other agents or humans using defined protocols.

   Agent Identifier:  A Fully Qualified Domain Name (FQDN) that uniquely
      identifies an agent.

   Agent Protocol:  The application-layer protocol used for agent-to-
      agent communication (e.g., [A2A], [ANP]).

3.  Design Principles

   This specification follows four core principles:

   +==================+================================================+
   | Principle        | Description                                    |
   +==================+================================================+
   | DNS-First        | DNS is the sole authoritative                  |
   |                  | source for agent resolution; HTTP              |
   |                  | serves only as a readable mirror               |
   +------------------+------------------------------------------------+
   | Path-Independent | Version and endpoint selection                 |
   |                  | are controlled by DNS, not URL                 |
   |                  | paths                                          |
   +------------------+------------------------------------------------+
   | Protocol         | Agent interaction protocols are                |
   | Autonomy         | decoupled from transport                       |
   +------------------+------------------------------------------------+
   | Default          | A/AAAA records guarantee minimum               |
   | Availability     | connectivity; enhanced features                |
   |                  | are optional.  Default version is              |
   |                  | provided when not specified                    |
   +------------------+------------------------------------------------+

                                  Table 1







Cui                       Expires 25 June 2026                  [Page 5]

Internet-Draft                   DN-ANR                    December 2025


4.  Naming and Resource Location

4.1.  Domain Name as Identity

   Each agent is uniquely identified by a stable Fully Qualified Domain
   Name (FQDN).  Domain ownership combined with TLS certificates forms
   the foundation of agent identity.

4.1.1.  Naming Rules

   *  Use domain names or subdomains owned by the organization

   *  Agent version changes do not introduce new identities

   *  No registration with any central authority is required

4.1.2.  Naming Examples

   # Recommended: dedicated subdomains
   translator.agents.example.com
   assistant.ai.company.com
   agent123.agents.example.com

4.2.  Resource Location via DNS

   This specification does not use URL paths for version expression.
   All version and endpoint selection is controlled by DNS records:

   1.  Query DNS SVCB records -> obtain version, endpoint, and protocol
       information

   2.  Query DNS TXT records -> obtain public key and verify identity

   3.  Connect to the TargetName:port specified in SVCB

   4.  Interact according to the protocol specification

5.  DNS Record Design

   This specification uses three types of DNS records [RFC1035], each
   with distinct responsibilities.  The SVCB record type is defined in
   [RFC9460] and [RFC9461]:









Cui                       Expires 25 June 2026                  [Page 6]

Internet-Draft                   DN-ANR                    December 2025


    +========+=================================+======================+
    | Record | Responsibility                  | Requirement          |
    | Type   |                                 |                      |
    +========+=================================+======================+
    | A /    | Basic connectivity              | REQUIRED - ensures   |
    | AAAA   |                                 | minimum availability |
    +--------+---------------------------------+----------------------+
    | TXT    | Identity declaration, public    | REQUIRED - identity  |
    |        | key publication, SVCB integrity | trust anchor         |
    |        | (svcb-digest), signature        |                      |
    +--------+---------------------------------+----------------------+
    | SVCB   | Version distribution, endpoint  | RECOMMENDED -        |
    |        | resolution, protocol            | enhanced resolution  |
    |        | negotiation                     |                      |
    +--------+---------------------------------+----------------------+

                                  Table 2

5.1.  TXT Record: Identity Trust Anchor

   TXT records [RFC1035] serve as the sole trust anchor for agent
   identity and integrity.  Their responsibilities are strictly limited
   to four functions:

   1.  Declare agent identity

   2.  Publish public key / fingerprint

   3.  Protect SVCB record integrity via digest (svcb-digest)

   4.  Sign identity and integrity metadata (tamper-proof)

5.1.1.  TXT Record Format

   _agent.translator.example.com. IN TXT (
     "v=1;"
     "kid=key-2025-01;"
     "alg=Ed25519;"
     "pk=base64-encoded-public-key;"
     "svcb-digest=base64-encoded-sha256-digest;"
     "sig=base64-encoded-signature"
   )









Cui                       Expires 25 June 2026                  [Page 7]

Internet-Draft                   DN-ANR                    December 2025


5.1.2.  TXT Field Descriptions

          +=============+=======================================+
          | Field       | Description                           |
          +=============+=======================================+
          | v           | Version identifier, fixed as 1        |
          +-------------+---------------------------------------+
          | kid         | Key identifier, used for key rotation |
          +-------------+---------------------------------------+
          | alg         | Signature algorithm: Ed25519          |
          |             | (RECOMMENDED) or ES256                |
          +-------------+---------------------------------------+
          | pk          | Base64-encoded public key             |
          +-------------+---------------------------------------+
          | svcb-digest | Base64-encoded SHA-256 digest of      |
          |             | canonicalized SVCB records (OPTIONAL  |
          |             | but RECOMMENDED when signing is used) |
          +-------------+---------------------------------------+
          | sig         | Signature over record content         |
          |             | (OPTIONAL but RECOMMENDED)            |
          +-------------+---------------------------------------+

                                  Table 3

5.2.  SVCB Record: Version Distribution and Protocol Negotiation

   SVCB (Service Binding) records [RFC9460] are the core resolution
   mechanism, serving the following responsibilities:

   +==================+================================================+
   | Level            | SVCB Role                                      |
   +==================+================================================+
   | Service Location | TargetName + port specify                      |
   |                  | the service endpoint                           |
   +------------------+------------------------------------------------+
   | Version          | Private SvcParam declares                      |
   | Distribution     | agent version                                  |
   +------------------+------------------------------------------------+
   | Protocol         | Private parameters declare                     |
   | Negotiation      | supported agent protocols                      |
   +------------------+------------------------------------------------+

                                  Table 4

5.2.1.  SVCB Record Example






Cui                       Expires 25 June 2026                  [Page 8]

Internet-Draft                   DN-ANR                    December 2025


   # Complete SVCB record example
   _agent.translator.example.com. IN SVCB 1 agent-v3.example.com. (
     alpn=h2
     port=443
     key65480="v3"              ; Agent version
     key65481="a2a,anp"         ; Supported agent protocols
   )

   # v2 version (lower priority)
   _agent.translator.example.com. IN SVCB 2 agent-v2.example.com. (
     alpn=h2
     port=443
     key65480="v2"
     key65481="a2a"
   )

5.3.  Version and Protocol Resolution

5.3.1.  SVCB Private Parameters

   This specification introduces two SVCB private parameters (SvcParam)
   as defined in [RFC9460] to declare version and protocol:

            +===========+=================+==================+
            | Parameter | Semantics       | Example          |
            +===========+=================+==================+
            | key65480  | Agent version   | "v3", "v2.1.0"   |
            +-----------+-----------------+------------------+
            | key65481  | Agent protocols | "a2a", "a2a,anp" |
            +-----------+-----------------+------------------+

                                 Table 5

5.3.1.1.  Version Selection Behavior

   Clients can:

   *  *Default selection*: When version is not specified, the highest
      priority version based on SVCB priority is used

   *  *Specific selection*: Specify key65480 value to select a
      particular version

   *  *Protocol filtering*: Select only versions supporting specific
      protocols (key65481)






Cui                       Expires 25 June 2026                  [Page 9]

Internet-Draft                   DN-ANR                    December 2025


5.3.2.  ALPN Usage

   ALPN is used for TLS-layer protocol negotiation (e.g., h2, h3).
   Agent interaction protocols ([A2A], [ANP]) are declared via SVCB
   private parameters (key65481), not ALPN values.  This ensures
   compatibility with existing TLS ecosystems and reserves space for
   future IANA registration.

5.3.3.  Relationship Between Version and Protocol

   This specification clearly distinguishes two layers:

          +================+======================+============+
          | Layer          | Declaration Location | Example    |
          +================+======================+============+
          | Agent Version  | key65480             | v3, v2.1.0 |
          +----------------+----------------------+------------+
          | Agent Protocol | key65481             | a2a, anp   |
          +----------------+----------------------+------------+

                                 Table 6

6.  HTTPS Fallback Mechanism

   To ensure "works by default" behavior, this specification introduces
   an optional but strongly recommended fallback mechanism.

6.1.  agent-dns.json

   For clients that do not support SVCB queries, agents can publish a
   JSON mirror of DNS records at an HTTPS endpoint:

   https://{agent-id}/.well-known/agent-dns.json

6.1.1.  Media Type

   The agent-dns.json file MUST be served with the following HTTP
   headers:

   Content-Type: application/json; charset=utf-8
   Cache-Control: max-age=300

   Servers SHOULD set an appropriate Cache-Control header.  A value
   between 300 seconds (5 minutes) and 3600 seconds (1 hour) is
   RECOMMENDED.






Cui                       Expires 25 June 2026                 [Page 10]

Internet-Draft                   DN-ANR                    December 2025


6.1.2.  JSON Signature

   The JSON file MUST include a signature for integrity protection.
   Unlike the TXT record signature which covers only TXT fields, the
   JSON signature covers the complete service binding information.

   The signature is computed over the canonical JSON representation of
   the document (excluding the sig field) as defined in [RFC8785] (JSON
   Canonicalization Scheme).

6.1.3.  JSON Schema Definition

   The agent-dns.json file MUST conform to the following JSON Schema:

   {
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://example.com/agent-dns.schema.json",
     "title": "Agent DNS JSON",
     "description": "Mirror of DNS records for agent resolution",
     "type": "object",
     "required": ["agentId", "txt", "sig"],
     "properties": {
       "agentId": {
         "type": "string",
         "description": "The FQDN identifying the agent",
         "pattern": "^[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?
                     (\\.[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?)*$"
       },
       "txt": {
         "type": "object",
         "description": "Core identity fields from DNS TXT record",
         "required": ["v", "kid"],
         "properties": {
           "v": {
             "type": "string",
             "const": "1"
           },
           "kid": {
             "type": "string",
             "description": "Key identifier"
           },
           "alg": {
             "type": "string",
             "enum": ["ES256", "Ed25519"],
             "description": "Signature algorithm"
           },
           "pk": {
             "type": "string",



Cui                       Expires 25 June 2026                 [Page 11]

Internet-Draft                   DN-ANR                    December 2025


             "description": "Base64-encoded TLS certificate public key"
           }
         }
       },
       "svcb": {
         "type": "array",
         "description": "Mirror of DNS SVCB records",
         "items": {
           "type": "object",
           "required": ["priority", "target", "port"],
           "properties": {
             "priority": {
               "type": "integer",
               "minimum": 1,
               "maximum": 65535
             },
             "target": {
               "type": "string",
               "description": "Target hostname"
             },
             "port": {
               "type": "integer",
               "minimum": 1,
               "maximum": 65535
             },
             "alpn": {
               "type": "array",
               "items": {
                 "type": "string"
               }
             },
             "agentVersion": {
               "type": "string",
               "description": "Agent version (mirrors key65480)"
             },
             "agentProtocols": {
               "type": "array",
               "items": {
                 "type": "string"
               },
               "description": "Supported protocols (mirrors key65481)"
             }
           }
         }
       },
       "sig": {
         "type": "string",
         "description": "Base64-encoded signature over canonical JSON



Cui                       Expires 25 June 2026                 [Page 12]

Internet-Draft                   DN-ANR                    December 2025


                                              (excluding sig field)"
       }
     }
   }

6.1.4.  File Structure Example

   {
     "agentId": "translator.example.com",
     "txt": {
       "v": "1",
       "kid": "key-2025-01",
       "alg": "ES256",
       "pk": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE..."
     },
     "svcb": [
       {
         "priority": 1,
         "target": "agent-v3.example.com",
         "port": 443,
         "alpn": ["h2"],
         "agentVersion": "v3",
         "agentProtocols": ["a2a", "anp"]
       },
       {
         "priority": 2,
         "target": "agent-v2.example.com",
         "port": 443,
         "alpn": ["h2"],
         "agentVersion": "v2",
         "agentProtocols": ["a2a"]
       }
     ],
     "sig": "MEUCIQC7..."
   }

6.1.5.  JSON Signature Computation

   The signature over the JSON file is computed as follows:

   1.  Construct the JSON object without the sig field.

   2.  Serialize using JSON Canonicalization Scheme (JCS) as defined in
       [RFC8785].

   3.  Compute the signature using the TLS private key.

   4.  Encode the signature using Base64.



Cui                       Expires 25 June 2026                 [Page 13]

Internet-Draft                   DN-ANR                    December 2025


   json_without_sig = { agentId, txt, svcb }
   canonical_json = JCS(json_without_sig)
   signature = Sign(TLS_private_key, UTF-8(canonical_json))
   sig = Base64Encode(signature)

6.1.6.  JSON Signature Verification

   Clients MUST verify the JSON signature:

   1.  Fetch the JSON file over HTTPS.

   2.  Extract the sig field and remove it from the object.

   3.  Serialize the remaining object using JCS.

   4.  Obtain the public key from the txt.pk field in the JSON.

   5.  Verify the signature.

   6.  (RECOMMENDED for TLS-based signing) Verify that txt.pk matches
       the TLS certificate's public key.

   If verification fails, the client MUST reject the JSON file.

   Note: When agent providers use separate key pairs (not TLS-based),
   the verification in step 6 is not applicable.  In such cases, the
   integrity of the JSON file depends on the authenticity of the public
   key in txt.pk, which has the same trust anchor limitations as
   described in the Security Model Overview.

6.2.  Design Principles

   *  *Mirror, not addition*: JSON only mirrors information already in
      DNS; it does not introduce content absent from DNS

   *  *DNS remains authoritative*: HTTPS JSON is only a "readable
      mirror", not a new authoritative source

   *  *Signature required*: JSON files MUST be signed for integrity
      protection

   *  *Schema validated*: Clients SHOULD validate JSON against the
      defined schema

6.3.  Applicable Scenarios

   *  Clients that do not support SVCB queries




Cui                       Expires 25 June 2026                 [Page 14]

Internet-Draft                   DN-ANR                    December 2025


   *  Browsers / debugging tools

   *  Early ecosystem transition period

   *  Environments where DNS resolution is limited

7.  Security

   This section defines the security mechanisms for ensuring the
   integrity and authenticity of agent resolution data.

7.1.  Security Model Overview

   This specification provides two approaches for ensuring the integrity
   and authenticity of agent resolution data:

   1.  *DNSSEC (RECOMMENDED)*: Protocol-level cryptographic
       authentication of DNS data

   2.  *Signature-based Security (OPTIONAL but RECOMMENDED)*: Signing of
       TXT content, SVCB digest, and JSON fallback

     +=================+===============+============================+
     | Mechanism       | Protection    | Trust Anchor               |
     |                 | Scope         |                            |
     +=================+===============+============================+
     | DNSSEC          | All DNS       | DNS root zone              |
     |                 | records (TXT, |                            |
     |                 | SVCB, A/AAAA) |                            |
     +-----------------+---------------+----------------------------+
     | Signature-based | TXT content,  | Web PKI (when using TLS    |
     | Security        | SVCB digest,  | keys) or self-declared     |
     |                 | JSON fallback | (when using separate keys) |
     +-----------------+---------------+----------------------------+

                                 Table 7

7.1.1.  DNSSEC-based Security (RECOMMENDED)

   DNSSEC [RFC4033] provides cryptographic authentication of DNS data at
   the protocol level.  When enabled:

   *  All DNS records are signed by the zone's DNSSEC keys

   *  Clients with DNSSEC validation can verify record authenticity

   *  No application-layer signatures are required




Cui                       Expires 25 June 2026                 [Page 15]

Internet-Draft                   DN-ANR                    December 2025


   DNSSEC is the RECOMMENDED approach for environments where it is fully
   deployed.

7.1.2.  Signature-based Security (OPTIONAL but RECOMMENDED)

   This specification defines an optional but recommended signing
   mechanism for integrity protection.  Agent providers have two options
   for key management:

7.1.2.1.  Option 1: TLS Certificate Keys (RECOMMENDED)

   Using the domain's TLS certificate keys provides a complete trust
   chain:

   *  Uses the domain's TLS certificate private key for signing

   *  Public key is published in the TXT record (pk field)

   *  Enables verification through the established Web PKI trust chain

   *  Clients can verify that pk matches the TLS certificate presented
      during HTTPS connection

   When TLS-based signing is used:

   1.  The TXT record contains the TLS certificate's public key

   2.  The TXT record contains a digest of SVCB records (svcb-digest)

   3.  A signature covers the TXT content including the SVCB digest

   4.  Clients can verify the signature using the public key from the
       TLS certificate chain

7.1.2.2.  Option 2: Separate Key Pair

   Agent providers MAY use a separate key pair (not derived from TLS
   certificates) for signing:

   *  Agent provider generates and manages their own key pair

   *  Public key is published in the TXT record (pk field)

   *  Signature is computed using the corresponding private key







Cui                       Expires 25 June 2026                 [Page 16]

Internet-Draft                   DN-ANR                    December 2025


   *Trust Anchor Limitation*: When using separate keys, the trust anchor
   is limited to the TXT record itself.  If the TXT record is tampered
   with (e.g., via DNS spoofing or cache poisoning), an attacker could
   replace both the public key and signature, rendering the integrity
   protection ineffective.  This is because:

   *  The public key in the TXT record is self-declared without external
      verification

   *  Clients have no independent trust anchor to verify the
      authenticity of the public key

   *  SVCB records and agent-dns.json cannot be reliably verified if the
      TXT record is compromised

   For this reason, when using separate keys:

   *  DNSSEC deployment becomes more important to protect the TXT record
      itself

   *  Clients SHOULD treat records from non-DNSSEC zones with
      appropriate caution

   *  Out-of-band key distribution mechanisms MAY be used to establish
      trust

7.1.3.  Choosing a Security Mechanism

     +===============+====================+=========================+
     | Scenario      | Recommended        |                         |
     |               | Approach           |                         |
     +===============+====================+=========================+
     | DNSSEC fully  | DNSSEC alone is    |                         |
     | deployed      | sufficient         |                         |
     +---------------+--------------------+-------------------------+
     | DNSSEC not    | Use TLS-based      |                         |
     | available     | signing (Option 1) |                         |
     +---------------+--------------------+-------------------------+
     | High security | Use both DNSSEC    |                         |
     | requirements  | and signing        |                         |
     |               | (defense-in-depth) |                         |
     +---------------+--------------------+-------------------------+
     | HTTPS         | Signing required   |                         |
     | fallback      | for JSON integrity |                         |
     | required      |                    |                         |
     +---------------+--------------------+-------------------------+
     |               | Using separate     | Limited trust; consider |
     |               | keys without       | additional verification |



Cui                       Expires 25 June 2026                 [Page 17]

Internet-Draft                   DN-ANR                    December 2025


     |               | DNSSEC             | mechanisms              |
     +---------------+--------------------+-------------------------+

                                 Table 8

7.2.  SVCB Integrity Protection

   When signature-based security is used, SVCB records are protected via
   a digest stored in the TXT record.  This section defines the
   canonicalization and digest computation procedures.

7.2.1.  SVCB Canonicalization

   To compute the svcb-digest, SVCB records MUST be canonicalized as
   follows:

7.2.1.1.  Step 1: Collect and Sort

   1.  Collect all SVCB records for the agent's _agent prefix.

   2.  Exclude AliasMode records (priority = 0).

   3.  Sort records by priority in ascending order (lowest first).

   4.  If priorities are equal, sort by TargetName lexicographically.

7.2.1.2.  Step 2: Normalize Each Record

   For each SVCB record, construct a canonical string in the following
   format:

   <priority> <target> <params>

   Where: - priority: Decimal integer with no leading zeros - target:
   Fully qualified domain name in lowercase, with trailing dot removed -
   params: SvcParams in sorted order by key number, formatted as
   key=value

7.2.1.3.  Step 3: SvcParam Normalization

   SvcParams MUST be normalized as follows:

   1.  Sort by SvcParamKey number (ascending).

   2.  Format each parameter as: key<number>=<value>

   3.  String values are enclosed in double quotes.




Cui                       Expires 25 June 2026                 [Page 18]

Internet-Draft                   DN-ANR                    December 2025


   4.  List values (e.g., alpn) use comma separation with no spaces.

   5.  Separate parameters with a single space.

7.2.1.4.  Canonical Format Example

# Original SVCB records:
_agent.translator.example.com. IN SVCB 2 agent-v2.example.com. (
  alpn=h2 port=443 key65480="v2" key65481="a2a"
)
_agent.translator.example.com. IN SVCB 1 agent-v3.example.com. (
  alpn=h2 port=443 key65480="v3" key65481="a2a,anp"
)

# Canonical representation (sorted by priority):
1 agent-v3.example.com key1=h2 key3=443 key65480="v3" key65481="a2a,anp"
2 agent-v2.example.com key1=h2 key3=443 key65480="v2" key65481="a2a"

   Note: alpn is SvcParamKey 1, port is SvcParamKey 3 as defined in
   [RFC9460].

7.2.2.  Digest Computation

   canonical_svcb = <line1> + "\n" + <line2> + "\n" + ...
   digest_bytes = SHA-256(UTF-8(canonical_svcb))
   svcb-digest = Base64Encode(digest_bytes)

   The resulting svcb-digest is approximately 44 characters (32 bytes
   encoded in Base64).

7.3.  Signature Specification

   This section defines the signature mechanism when signature-based
   security is used.

7.3.1.  Public Key Requirements

   The pk field contains the public key used for signature verification.
   There are two options:

7.3.1.1.  When Using TLS Certificate Keys (RECOMMENDED)

   The pk field MUST contain the public key from the domain's TLS
   certificate:

   1.  Extract the SubjectPublicKeyInfo from the TLS certificate.

   2.  Encode using Base64 [RFC4648].



Cui                       Expires 25 June 2026                 [Page 19]

Internet-Draft                   DN-ANR                    December 2025


   3.  The certificate MUST be valid for the agent's domain name.

7.3.1.2.  When Using Separate Key Pair

   The pk field contains the agent provider's self-managed public key:

   1.  Generate a key pair using a supported algorithm.

   2.  Extract the public key in SubjectPublicKeyInfo format.

   3.  Encode using Base64 [RFC4648].

   Note: When using separate keys, the public key is self-declared and
   lacks an independent trust anchor.  See Security Model Overview for
   implications.

7.3.1.3.  Supported Key Types

   *  EC P-256 (for ES256 algorithm) - RECOMMENDED

   *  Ed25519 (for Ed25519 algorithm)

7.3.2.  Signature Input Construction

   The signature input MUST be constructed by concatenating the
   following fields in order, separated by semicolons, with no trailing
   semicolon:

   signing_input = "v=" + v + ";kid=" + kid + ";alg=" + alg + ";
                     pk=" + pk + ";svcb-digest=" + svcb-digest

   Example: ~~~ v=1;kid=key-2025-01;alg=ES256;pk=MFkwEwYHKoZI...;svcb-
   digest=K7gNU3sdo+OL... ~~~

7.3.3.  Signature Generation

   signature_bytes = Sign(private_key, UTF-8(signing_input))
   sig = Base64Encode(signature_bytes)

   Where private_key is either: - The TLS certificate's private key
   (Option 1, RECOMMENDED), or - The agent provider's separately managed
   private key (Option 2)

   For ES256: signature is 64 bytes (r || s format), resulting in 88
   Base64 characters.  For Ed25519: signature is 64 bytes, resulting in
   88 Base64 characters.





Cui                       Expires 25 June 2026                 [Page 20]

Internet-Draft                   DN-ANR                    December 2025


7.3.4.  Signature Verification Procedure

   Clients MUST perform the following steps:

   1.  Parse TXT record and extract v, kid, alg, pk, svcb-digest, sig
       fields.

   2.  Reconstruct signing_input from v, kid, alg, pk, svcb-digest.

   3.  Decode pk from Base64 to obtain the public key.

   4.  Decode sig from Base64 to obtain the signature bytes.

   5.  Verify the signature using the specified algorithm.

   6.  (RECOMMENDED for Option 1) Verify that pk matches the TLS
       certificate presented during connection.

   If verification fails, the client MUST reject the TXT record.

   When using Option 2 (separate key pair), clients should be aware that
   the signature only proves consistency between the TXT record content
   and the private key holder.  Without DNSSEC or TLS binding, there is
   no external trust anchor to verify the key's authenticity.

7.3.5.  TLS Certificate Binding Verification (Option 1 Only)

   When TLS certificate keys are used (Option 1), clients SHOULD verify
   that the pk in the TXT record matches the server's TLS certificate:

   1.  Establish TLS connection to the agent's domain.

   2.  Extract the public key from the server's certificate.

   3.  Compare with the pk field in the TXT record.

   4.  If mismatch, treat as verification failure.

   This binding ensures that the entity controlling the TLS private key
   is the same entity that published the DNS records.

   Note: This verification is not applicable when separate key pairs are
   used (Option 2), as the pk in the TXT record will not match the TLS
   certificate.







Cui                       Expires 25 June 2026                 [Page 21]

Internet-Draft                   DN-ANR                    December 2025


8.  Implementation Checklist

8.1.  For Agent Publishers

   1.  Prepare domain name, configure HTTPS and TLS certificate

   2.  Configure DNS A/AAAA records (basic connectivity)

   3.  Configure DNS TXT record (_agent.xxx), publish public key

   4.  Configure DNS SVCB records, declare version and protocols

   5.  (RECOMMENDED) Publish /.well-known/agent-dns.json fallback file

   6.  (RECOMMENDED) Enable DNSSEC

8.2.  For Client Developers

   1.  Query SVCB records, parse version and endpoint information

   2.  Query TXT records, extract public key

   3.  (Fallback) If SVCB unavailable, fetch agent-dns.json

   4.  Connect to endpoint per agent protocol (key65481) specification

   5.  (RECOMMENDED) Validate DNSSEC

8.3.  DNS Record Configuration Example

   ; Basic connectivity
   translator.example.com.    IN A     203.0.113.50
   translator.example.com.    IN AAAA  2001:db8::50

   ; Identity trust anchor (with SVCB integrity protection)
   _agent.translator.example.com. IN TXT "v=1;kid=key-2025-01;
                       alg=Ed25519;pk=...;svcb-digest=...;sig=..."

   ; Version resolution (SVCB)
   _agent.translator.example.com. IN SVCB 1 agent-v3.example.com. (
     alpn=h2 port=443 key65480="v3" key65481="a2a,anp"
   )
   _agent.translator.example.com. IN SVCB 2 agent-v2.example.com. (
     alpn=h2 port=443 key65480="v2" key65481="a2a"
   )






Cui                       Expires 25 June 2026                 [Page 22]

Internet-Draft                   DN-ANR                    December 2025


9.  Security Considerations

   This specification uses DNS as the authoritative source for agent
   resolution and identity information.  Its security objectives are to
   ensure the authenticity, integrity, and verifiability of resolution
   results, rather than evaluating agent service quality or behavioral
   trustworthiness.

9.1.  Threat Model

   This specification primarily considers the following threats:

   *  DNS poisoning or cache pollution leading to incorrect endpoint
      resolution

   *  Tampering with resolution results to redirect clients to
      unintended endpoints

   *  Downgrade attacks inducing clients to use older versions or weaker
      protocols

   *  Trust violations caused by expired or replaced identity
      declarations

9.2.  Mandatory Security Requirements

   To address the above threats, this specification mandates:

   *  Clients MUST complete TXT verification before using any SVCB
      resolution results

   *  Clients MUST perform TXT-SVCB consistency checks

   *  Clients MUST use TLS [RFC8446] and verify server certificates
      [RFC9525]

   *  Clients MUST NOT use endpoints that fail verification

   *  Agents MUST synchronously update TXT and SVCB information when
      versions or endpoints change

9.3.  DNSSEC Usage

   *  Agent operators SHOULD enable DNSSEC [RFC4033] for their domains
      to enhance DNS-layer data integrity

   *  Clients MAY verify DNSSEC signatures




Cui                       Expires 25 June 2026                 [Page 23]

Internet-Draft                   DN-ANR                    December 2025


   *  This specification MUST NOT rely on DNSSEC as the sole security
      mechanism; its absence SHOULD NOT cause system unavailability

9.4.  Specification Scope

   This specification guarantees the following properties:

   *  Verifiability of agent identity

   *  Integrity and consistency of resolution results

   *  Encryption and tamper-proofing of connections

   This specification does NOT attempt to address:

   *  Agent capability authenticity

   *  Service quality (SLA) or behavioral compliance

   *  Agent reputation or governance issues

   These concerns should be handled by upper-layer protocols,
   operational frameworks, or governance mechanisms.

10.  IANA Considerations

   This document requests IANA registration of the following SVCB
   SvcParamKeys:

   +========+=================+===========================+===========+
   | Number | Name            | Meaning                   | Reference |
   +========+=================+===========================+===========+
   | 65480  | agent-version   | Agent version identifier  | This      |
   |        |                 |                           | document  |
   +--------+-----------------+---------------------------+-----------+
   | 65481  | agent-protocols | Comma-separated list of   | This      |
   |        |                 | supported agent protocols | document  |
   +--------+-----------------+---------------------------+-----------+

                                 Table 9

   Note: The values 65480 and 65481 are in the private use range
   (65280-65534) as defined in [RFC9460].  Upon publication, these
   should be replaced with IANA-assigned values from the Expert Review
   range.

11.  References




Cui                       Expires 25 June 2026                 [Page 24]

Internet-Draft                   DN-ANR                    December 2025


11.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

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

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4033>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/rfc/rfc4648>.

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

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

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8785>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [RFC9461]  Schwartz, B., "Service Binding Mapping for DNS Servers",
              RFC 9461, DOI 10.17487/RFC9461, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9461>.

   [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
              RFC 9525, DOI 10.17487/RFC9525, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9525>.

11.2.  Informative References




Cui                       Expires 25 June 2026                 [Page 25]

Internet-Draft                   DN-ANR                    December 2025


   [A2A]      Google, "Agent2Agent Protocol (A2A)", 2025,
              <https://google.github.io/A2A/>.

   [ANP]      ANP Community, "Agent Network Protocol (ANP)", 2025,
              <https://agent-network-protocol.com/>.

Acknowledgments

Author's Address

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



































Cui                       Expires 25 June 2026                 [Page 26]


name: draft-goswami-agentic-jwt
rev: 00
title: Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management
time: 2026-01-01T08:57:21Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-05T08:57:21Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420508+00:00
abstract:
This document specifies Agentic JSON Web Token (Agentic JWT), as an
   extension to OAuth 2.0 that addresses authorization challenges unique
   to autonomous agentic AI systems.  This protocol solves the problem
   of Zero-Trust drift due to non-deterministic Agentic AI clients
   causing separation between user's (resource owner's) intent and
   client application's actions.

   Traditional OAuth 2.0 assumes that client applications faithfully
   represent user intent when requesting authorization.  This assumption
   breaks down when autonomous AI agents dynamically generate workflows,
   create sub-agents, and make authorization decisions without
   continuous human oversight.  We term this the "intent-execution
   separation problem."

   Agentic JWT introduces three mechanisms to address this problem: (1)
   cryptographic agent identity through agent checksums (based on
   agent's system prompts, tools and configurations), (2) workflow-aware
   token binding that links user intent to agent execution, and (3) a
   new OAuth 2.0 grant type (agent_checksum) for secure token issuance,
   (4) a flavor of PoP (Proof-of-Possession) at the level of an agentic
   identity to prevent token replays by other agents in the same multi-
   agent process.

   This specification enables Zero-Trust security principles in multi-
   agent systems while maintaining backward compatibility with existing
   OAuth 2.0 infrastructure.  The security analysis and experimental
   validation are described in the companion research paper.

full_text:
Internet Engineering Task Force                          A. Goswami, Ed.
Internet-Draft                                          31 December 2025
Intended status: Informational                                          
Expires: 4 July 2026


  Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow
                               Management
                      draft-goswami-agentic-jwt-00

Abstract

   This document specifies Agentic JSON Web Token (Agentic JWT), as an
   extension to OAuth 2.0 that addresses authorization challenges unique
   to autonomous agentic AI systems.  This protocol solves the problem
   of Zero-Trust drift due to non-deterministic Agentic AI clients
   causing separation between user's (resource owner's) intent and
   client application's actions.

   Traditional OAuth 2.0 assumes that client applications faithfully
   represent user intent when requesting authorization.  This assumption
   breaks down when autonomous AI agents dynamically generate workflows,
   create sub-agents, and make authorization decisions without
   continuous human oversight.  We term this the "intent-execution
   separation problem."

   Agentic JWT introduces three mechanisms to address this problem: (1)
   cryptographic agent identity through agent checksums (based on
   agent's system prompts, tools and configurations), (2) workflow-aware
   token binding that links user intent to agent execution, and (3) a
   new OAuth 2.0 grant type (agent_checksum) for secure token issuance,
   (4) a flavor of PoP (Proof-of-Possession) at the level of an agentic
   identity to prevent token replays by other agents in the same multi-
   agent process.

   This specification enables Zero-Trust security principles in multi-
   agent systems while maintaining backward compatibility with existing
   OAuth 2.0 infrastructure.  The security analysis and experimental
   validation are described in the companion research paper.

Status of This Memo

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







Goswami                    Expires 4 July 2026                  [Page 1]

Internet-Draft            Agentic JWT Protocol             December 2025


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

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

   This Internet-Draft will expire on 4 July 2026.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  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  . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   6
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     1.3.  Companion Research  . . . . . . . . . . . . . . . . . . .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Agent Classifications . . . . . . . . . . . . . . . . . .   8
   3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Architectural Components  . . . . . . . . . . . . . . . .   8
     3.2.  Abstract Protocol Flow  . . . . . . . . . . . . . . . . .  10
   4.  Agent Checksum Grant Type . . . . . . . . . . . . . . . . . .  11
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Token Request . . . . . . . . . . . . . . . . . . . . . .  12
       4.2.1.  Request Format  . . . . . . . . . . . . . . . . . . .  12
       4.2.2.  Request Example . . . . . . . . . . . . . . . . . . .  13
       4.2.3.  Request Authentication  . . . . . . . . . . . . . . .  14
     4.3.  Authorization Server Processing . . . . . . . . . . . . .  14
       4.3.1.  Validation Sequence . . . . . . . . . . . . . . . . .  14
       4.3.2.  Checksum Verification Details . . . . . . . . . . . .  14
       4.3.3.  Workflow Step Validation  . . . . . . . . . . . . . .  15
       4.3.4.  Delegation Chain Validation . . . . . . . . . . . . .  15



Goswami                    Expires 4 July 2026                  [Page 2]

Internet-Draft            Agentic JWT Protocol             December 2025


     4.4.  Successful Response . . . . . . . . . . . . . . . . . . .  16
       4.4.1.  Response Format . . . . . . . . . . . . . . . . . . .  16
       4.4.2.  Intent Token Structure  . . . . . . . . . . . . . . .  16
       4.4.3.  Token Example . . . . . . . . . . . . . . . . . . . .  17
       4.4.4.  Sequence Hash Computation . . . . . . . . . . . . . .  18
     4.5.  Error Responses . . . . . . . . . . . . . . . . . . . . .  19
       4.5.1.  Error Response Format . . . . . . . . . . . . . . . .  19
       4.5.2.  unsupported_grant_type  . . . . . . . . . . . . . . .  19
       4.5.3.  unknown_agent . . . . . . . . . . . . . . . . . . . .  20
       4.5.4.  agent_checksum_mismatch . . . . . . . . . . . . . . .  20
       4.5.5.  workflow_step_unauthorized  . . . . . . . . . . . . .  21
       4.5.6.  invalid_request . . . . . . . . . . . . . . . . . . .  21
     4.6.  Auth Grant Security Considerations  . . . . . . . . . . .  22
     4.7.  Implementation Notes  . . . . . . . . . . . . . . . . . .  22
       4.7.1.  Agent Registry  . . . . . . . . . . . . . . . . . . .  22
       4.7.2.  Workflow Registry . . . . . . . . . . . . . . . . . .  23
       4.7.3.  Performance Considerations  . . . . . . . . . . . . .  23
   5.  Agent Identity  . . . . . . . . . . . . . . . . . . . . . . .  23
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  23
     5.2.  Agent Configuration Structure . . . . . . . . . . . . . .  24
       5.2.1.  Agent Specification . . . . . . . . . . . . . . . . .  24
       5.2.2.  Example Agent Specification . . . . . . . . . . . . .  25
       5.2.3.  Tool Checksum Levels  . . . . . . . . . . . . . . . .  26
       5.2.4.  Tool Signature Normalization  . . . . . . . . . . . .  26
       5.2.5.  Source Code Normalization . . . . . . . . . . . . . .  29
     5.3.  Checksum Computation  . . . . . . . . . . . . . . . . . .  31
       5.3.1.  Computation Algorithm . . . . . . . . . . . . . . . .  31
       5.3.2.  Implementation Guidance . . . . . . . . . . . . . . .  32
     5.4.  Agent Registration  . . . . . . . . . . . . . . . . . . .  35
       5.4.1.  Registration Overview . . . . . . . . . . . . . . . .  35
       5.4.2.  IDP Processing  . . . . . . . . . . . . . . . . . . .  35
       5.4.3.  Registration Response . . . . . . . . . . . . . . . .  36
       5.4.4.  Agent Updates . . . . . . . . . . . . . . . . . . . .  36
     5.5.  Checksum Verification . . . . . . . . . . . . . . . . . .  37
       5.5.1.  Client-Side Verification  . . . . . . . . . . . . . .  37
       5.5.2.  Server-Side Verification  . . . . . . . . . . . . . .  38
     5.6.  Identity Lifecycle  . . . . . . . . . . . . . . . . . . .  38
       5.6.1.  Lifecycle Stages  . . . . . . . . . . . . . . . . . .  38
       5.6.2.  State Transitions . . . . . . . . . . . . . . . . . .  39
     5.7.  Identity Security Considerations  . . . . . . . . . . . .  39
   6.  Protocol Flows  . . . . . . . . . . . . . . . . . . . . . . .  39
     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  39
     6.2.  Agent Registration Flow . . . . . . . . . . . . . . . . .  40
       6.2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  40
       6.2.2.  Sequence Diagram  . . . . . . . . . . . . . . . . . .  40
       6.2.3.  Step-by-Step Procedure  . . . . . . . . . . . . . . .  41
     6.3.  Workflow Registration Flow  . . . . . . . . . . . . . . .  42
       6.3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  42



Goswami                    Expires 4 July 2026                  [Page 3]

Internet-Draft            Agentic JWT Protocol             December 2025


       6.3.2.  Sequence Diagram  . . . . . . . . . . . . . . . . . .  42
       6.3.3.  HTTP Example  . . . . . . . . . . . . . . . . . . . .  43
     6.4.  Token Request Flow  . . . . . . . . . . . . . . . . . . .  44
       6.4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  45
       6.4.2.  Sequence Diagram  . . . . . . . . . . . . . . . . . .  45
       6.4.3.  Step-by-Step Procedure  . . . . . . . . . . . . . . .  46
     6.5.  API Authorization Flow  . . . . . . . . . . . . . . . . .  47
       6.5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  48
       6.5.2.  Sequence Diagram  . . . . . . . . . . . . . . . . . .  48
       6.5.3.  Validation Steps  . . . . . . . . . . . . . . . . . .  49
     6.6.  Multi-Agent Delegation Flow . . . . . . . . . . . . . . .  49
       6.6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  50
       6.6.2.  Sequence Diagram  . . . . . . . . . . . . . . . . . .  50
       6.6.3.  Delegation Steps  . . . . . . . . . . . . . . . . . .  51
       6.6.4.  Delegation Validation . . . . . . . . . . . . . . . .  53
   7.  Future Work . . . . . . . . . . . . . . . . . . . . . . . . .  53
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  53
     8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  54
     8.2.  OAuth Authorization Grant Type Registration . . . . . . .  54
     8.3.  JWT Claims Registration . . . . . . . . . . . . . . . . .  54
     8.4.  OAuth Parameters Registration . . . . . . . . . . . . . .  55
     8.5.  OAuth Extensions Error Registration . . . . . . . . . . .  56
     8.6.  Media Type Registration . . . . . . . . . . . . . . . . .  57
     8.7.  Registration Summary  . . . . . . . . . . . . . . . . . .  57
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  58
     9.1.  Checksum Security . . . . . . . . . . . . . . . . . . . .  58
       9.1.1.  Checksum Verification Security  . . . . . . . . . . .  58
       9.1.2.  Checksum Strength . . . . . . . . . . . . . . . . . .  58
       9.1.3.  Registration Security . . . . . . . . . . . . . . . .  58
       9.1.4.  Registry Storage Security . . . . . . . . . . . . . .  59
     9.2.  Token Security  . . . . . . . . . . . . . . . . . . . . .  59
       9.2.1.  Token Lifetime  . . . . . . . . . . . . . . . . . . .  59
       9.2.2.  Proof-of-Possession . . . . . . . . . . . . . . . . .  59
     9.3.  Workflow Security . . . . . . . . . . . . . . . . . . . .  60
       9.3.1.  Workflow Validation . . . . . . . . . . . . . . . . .  60
       9.3.2.  Delegation Chain Integrity  . . . . . . . . . . . . .  60
     9.4.  Implementation Considerations . . . . . . . . . . . . . .  60
       9.4.1.  Cryptographic Requirements  . . . . . . . . . . . . .  61
       9.4.2.  Privacy Considerations  . . . . . . . . . . . . . . .  61
       9.4.3.  Denial of Service Considerations  . . . . . . . . . .  61
     9.5.  Threat Analysis . . . . . . . . . . . . . . . . . . . . .  62
     9.6.  Threat Descriptions and Attack Vectors  . . . . . . . . .  64
     9.7.  Security Anchors and Mitigation Mechanisms  . . . . . . .  66
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  67
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  67
     10.2.  Informative References . . . . . . . . . . . . . . . . .  69
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  71
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  71



Goswami                    Expires 4 July 2026                  [Page 4]

Internet-Draft            Agentic JWT Protocol             December 2025


   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  71

1.  Introduction

   OAuth 2.0 is designed for deterministic client applications that
   execute some workflow on behalf of a resource owner [RFC6749].  The
   principle is that an authorization server (or Identity Provider, IDP)
   validates the client application using an authorization grant appoved
   by the resource owner and issues an access token as the proof of
   authorization, which is then used by some fixed workflow on the
   client to invoke an API hosted on the resource server.  This
   mechanism breaks down for client applications using agentic AI with
   LLM reasoning because the decision to call resource server APIs could
   be taken by non-deterministic LLM reasoning that creates a separation
   between user's intent and actual agentic execution.

   Consider a multi-agent vulnerability patching system where a
   supervisor agent coordinates planner, classifier, and patcher sub-
   agents.  Traditional OAuth 2.0 cannot detect when a low-privilege
   classifier agent tricks a high-privilege patcher into modifying
   critical system files, as the bearer token provides no cryptographic
   binding between user intent and agent execution.  While next-
   generation protocols like GNAP [I-D.ietf-txauth-gnap] address some
   OAuth 2.0 limitations through JSON-based grant negotiation, they do
   not provide the agent-specific identity verification and workflow
   binding mechanisms required for autonomous AI systems.

   This document addresses the following critical gaps in existing
   authorization frameworks for autonomous agents:

   *  Agent Identity: How to cryptographically verify agent identity
      beyond client_id credentials

   *  Intent Binding: How to bind user-authorized intent to specific
      agent workflows

   *  Delegation Control: How to prevent unauthorized cross-agent
      privilege escalation

   *  Agent level Proof-of-Posession: How to prevent token replaying by
      another agent running within the same client process.

   This specification does NOT address:

   *  Model non-determinism or LLM safety

   *  Agent framework-specific implementation details




Goswami                    Expires 4 July 2026                  [Page 5]

Internet-Draft            Agentic JWT Protocol             December 2025


   *  Performance optimization techniques

1.1.  Motivation

   Agentic AI based applications are rapidly solving more use cases and
   have already become targets for massive investments in enterprises
   across industries.  Agentic clients would likely proliferate much
   faster than the currently available Zero-Trust implementations,
   including OAuth 2.0.  The fundamental Zero-Trust principles
   [NIST-SP-800-207] outlined in the NIST 800.63 publication
   [NIST-SP-800-63] and [NIST-SP-800-63C] are very much applicable and
   sound but current implementations need to catch up.  This protocol
   enhancement attempts to achieve permanent protection from the
   possibility of Zero-Trust drift in API invocations done by agentic
   client applications.  This specification outlines this novel protocol
   as fully backward compatible with the current OAuth 2.0 primitives
   while expanding the token issuance and resource server validation
   processes to recognzie agents as separate identities, their currently
   running version, the currently executing workflow and entire
   delegation chain in case of multi-agent applications.  It also
   defines a way to make agentic clients auditable on the authorization
   server side.

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.

1.3.  Companion Research

   A comprehensive threat modelling using the STRIDE methodology
   [SHOSTACK], including experimental evaluation, and performance
   analysis is described in the research paper, [PAPER-REF].  This
   document focuses on protocol specification for implementers.

   The system architecture and mechanisms described in this
   specification are the subject of U.S.  Patent Application 19/315,486
   [PATENT-REF].

2.  Terminology

   This document uses the following terms in addition to those defined
   in [RFC6749] and [RFC7519]





Goswami                    Expires 4 July 2026                  [Page 6]

Internet-Draft            Agentic JWT Protocol             December 2025


   Agentic Client:
      An autonomous AI agent that acts as an OAuth 2.0 client.  Unlike
      traditional clients, agentic clients can dynamically generate
      workflows, create sub-agents, and make authorization decisions
      without continuous human interaction.

   Agent Checksum:
      A SHA-256 cryptographic hash computed over the agent's
      configuration, including system prompt, available tools, and model
      parameters.  The agent checksum uniquely identifies the agent's
      behavioral specification and serves as its cryptographic identity.

   Intent Token:
      A JWT (JSON Web token, [RFC7519]) issued by the authorization
      server that encapsulates user-authorized intent.  The intent token
      includes new claims, and semantics such the workflow definition,
      requested scopes, agent checksum binding, workflow delegation
      chain, and user approval status.  It is fully compatible with
      plain JWT tokens and other JWT primitives like JWS (JSON Web
      Signature, [RFC7515]) and JWE (JSON Web Encryption, [RFC7516]).

   Workflow Binding:
      The cryptographic association between a user-approved workflow and
      the access token issued for its execution.  Implemented through
      the workflow_id and workflow_hash claims.

   Delegation Assertion:
      A cryptographic proof that an agent is authorized to execute a
      specific workflow on behalf of a user.  Combines agent identity
      verification, intent binding, and scope restrictions.  The
      mechanism is similar in spirit to OAuth 2.0 Token Exchange
      [RFC8693] but uses agent-specific cryptographic binding instead of
      token exchange grants.

   Agent Checksum Grant or agent_checksum:
      A new OAuth 2.0 grant type (defined in Section 7) that allows
      agents to exchange intent tokens for access tokens using agent
      checksum verification instead of client credentials.

   Supervisor Agent:
      In multi-agent systems, the agent that coordinates sub-agent
      workflows and maintains the delegation chain.  Referenced in
      examples throughout this document.








Goswami                    Expires 4 July 2026                  [Page 7]

Internet-Draft            Agentic JWT Protocol             December 2025


   Intent-Execution Separation:
      The security gap that occurs when an agent executes actions that
      diverge from user-authorized intent.  Traditional OAuth 2.0 cannot
      detect this separation because bearer tokens do not bind
      authorization to specific execution contexts.

   Human in the Loop
      An agentic AI architectural pattern that involves some steps of an
      agentic workflow to be done or approved by human.  The agentic
      workflow executes to a specific point and then pauses by notifying
      for human approval, it then waits until an approval is received
      before continuiing with the workflow.

   Authorization Server or Identity Provider or IDP
      This is the "Authorization Server" as defined in [RFC6749]

   Client Shim Library
      Designed to be used as a dependency in any agentic client
      application to make the protocol flow of this intent based agentic
      jwt protocol easy to implement.  It reduces the work on these
      client applications to a single line of code and hides all the
      complexity involved in performing the tasks necessary for seamless
      minting of intent tokens, verifying agent registrations from IDP
      (or Authorization Server), and tracking runtime agent workflow so
      that workflow state can be used while requesting an intent token.

2.1.  Agent Classifications

   This specification recognizes three agent types based on autonomy
   level:

   Fully Supervised Agents:  Require human approval for each action

   Semi-Autonomous Agents:  Execute pre-approved workflows with human
      oversight, such as when using Human in the Loop pattern.

   Fully Autonomous Agents:  Execute complete workflows without human
      intervention

   The security requirements vary by agent type, with fully autonomous
   agents requiring the strongest guarantees.

3.  Architecture Overview

3.1.  Architectural Components

   This agentic JWT architecture introduces the following novel (but
   backward compatible) protocol features:



Goswami                    Expires 4 July 2026                  [Page 8]

Internet-Draft            Agentic JWT Protocol             December 2025


   *  Enhancements in JWT Claims: The protocol introduces some new
      claims required for supporting the verification of agentic AI
      clients.

   *  A new Authorization Grant called agent_checksum: The protcol
      introduces a novel authorization grant [RFC6749] called
      agent_checksum that allows the agentic client applications to act
      on behalf of the resource owner and enables the authorization
      servers to issue tokens without explicit credentials, by simply
      using an agent's runtime identity.  An agent's runtime identity is
      typically composed of its system prompt, its tool specification
      (or a hash of actual tool function code), and LLM configuration
      (if applicable).

   *  Authorization Server token issuing protocol: The protocol adds
      unique verification capabilities on the authorization server side
      used during token issuance process.

   *  Resource Server verification protocol: The protocol adds
      additional verification capabilities on the resource server side.

   *  Intent Token: This is the new JWT compatible token that contains
      the additional claims plus the agent specific identity
      information.  (see Intent Token (Section 2)).

   All of the above mentioned architectural choices are fully backward
   compatible with OAuth 2.0.

   The architecture components that make these features possible can be
   implemented using general purpose programming languages like python,
   nodejs, java etc.  The exact logical component design is outlined
   below:

   *  Client Shim Library: Implements the client side logic that
      performs the tasks necessary for seamless minting of intent
      tokens, verifying agent registrations from IDP (or Authorization
      Server), and tracking runtime agent workflow so that workflow
      state can be used while requesting an intent token.

   *  Authorization Server Library: Implements the Authorization Server
      side validation logic for authenticating incoming client requests
      using agent_checksum authorization grant.

   *  Resource Server Library: Implements the Resource Server side logic
      for token validation for intent tokens including per agent Proof-
      of-Posession verification.





Goswami                    Expires 4 July 2026                  [Page 9]

Internet-Draft            Agentic JWT Protocol             December 2025


3.2.  Abstract Protocol Flow

   The Agentic JWT protocol flow is conceptually similar to that of
   OAuth 2.0 [RFC6749] at high level.  However, the internal structure
   and mechanism is different and encapsulates agentic aware protocol
   features.


+----------------------+
|                      |
|        Client        |
|                      |
|  +----------------+  |                                 +-----------------+
|  |                |  |           Agent Registration    |                 |
|  |                +--+--(A)--------------------------->|    Resource     |
|  |                |  |                                 |    Owner        |
|  |                |  |                                 |                 |
|  |                |<-+--(B)---Authorization-Grant------+                 |
|  |                |  |        (agent_checksum)         +-----------------+
|  |                |  |
|  |                |  |
|  |  Shim Library  |  |                                 +-----------------+
|  |                +--+---(C)-----agent_checksum------->|                 |
|  |                |  |                                 |                 |
|  |                |  |                                 | Authorization   |
|  |                |  |                                 |    Server       |
|  |                |<-+--(D)------intent-token----------+                 |
|  |                |  |        (with agent information) +-----------------+
|  |                |  |
|  |                |  |                                 +-----------------+
|  |                +--+--(E)------intent-token--------->|                 |
|  |                |  |                                 |   Resource      |
|  |                |  |                                 |    Server       |
|  |                |<-+--(F)----Protected-Resource------+                 |
|  +----------------+  |                                 +-----------------+
+----------------------+

Workflow: User → IDP → Intent Token → Agent → Access Token → API


             Figure 1: Agentic JWT Abstract Protocol Flow

   The protocol flow described in Figure 1 outlines the interactions
   between the client (via Shim Library), the Resource Owner, the
   Authorization Server, and the Resource Server.  This flow is fully
   compatible with the original OAuth 2.0 protocol flow.  The
   complexities of verifying registered agents on the Client, capturing
   runtime identity of an agent for minting intent tokens, tracking



Goswami                    Expires 4 July 2026                 [Page 10]

Internet-Draft            Agentic JWT Protocol             December 2025


   runtime workflow and sending these to Authorization Server with the
   intent token request, are hidden inside the Shim Library.  A Client
   application just needs to include the Shim library as a dependency to
   make this flow work.  The protocol flow steps are described below:

   (A)  The client makes an authorization grant request to the resource
        owner either directly or preferably via the authorization
        server.  Having authorization grant means that each agent
        running within the client process has been registered as
        identity in the authorization server with an Agent Checksum (see
        Section 2) of its system prompt, tool specifications, and LLM
        configuration.

   (B)  The client receives an authorization grant that can be used to
        request intent tokens from the authorization server.  This is
        new authorization grant type called agent_checksum.  The
        agent_checksum authorization grant is based on an agent's
        inherent signature used as its identity.  An agent's signature
        comprises of its system prompt, tools specifications (or tool
        function code), and LLM configuration.  This new grant type is
        described in Section 4

   (C)  The shim library running within the client process requests an
        intent token by presenting the authorization grant of
        'agent_checksum' which uses the currently running agent's
        signature as part of the input.  The shim library computes the
        runtime Agent Checksum (see Section 2 of the running agent and
        includes in the intent token request.

   (D)  The authorization server validates the request against the
        registered agents, by comparing agent checksum in the input with
        regisrered checksums, and if valid, issues the intent token.

   (E)  The shim library, running within the client process, requests
        the protected resource from the resource server by presenting
        the intent token for authentication and authorization
        information.

   (F)  The resource server validates the intent token,and if valid,
        serves the request.

4.  Agent Checksum Grant Type









Goswami                    Expires 4 July 2026                 [Page 11]

Internet-Draft            Agentic JWT Protocol             December 2025


4.1.  Overview

   This specification defines a new OAuth 2.0 grant type for autonomous
   AI agents: "agent_checksum".  This grant type enables agents to
   obtain access tokens (called intent tokens in context of this
   specification) by proving their identity through cryptographic
   checksum verification rather than traditional client credentials.

   The grant type is designed specifically for agentic clients that:

   *  Have registered their agent checksum with the authorization server

   *  Optionally execute pre-approved workflows with defined steps

   *  Maintain delegation chains across multi-agent systems

   *  Require proof-of-possession token binding

   Grant Type Identifier:

       urn:ietf:params:oauth:grant-type:agent_checksum

   Note: For brevity in examples, this document uses the short form
   "agent_checksum" instead of the full URN.

4.2.  Token Request

4.2.1.  Request Format

   The client shim library (see Section 2), on behalf of an agent, makes
   a request to the token endpoint by sending the following parameters
   using the "application/json" format with a character encoding of UTF-
   8:

   grant_type:  REQUIRED.  Value MUST be "agent_checksum" (or the full
      URN).

   agent_id:  REQUIRED.  The unique identifier of the registered agent.

   computed_checksum:  REQUIRED.  The SHA-256 checksum computed over the
      agent's current configuration.  Format: "sha256:<hex>".

   workflow_id:  REQUIRED when workflow_enabled is true.  The identifier
      of the registered workflow being executed.

   workflow_step:  REQUIRED when workflow_enabled is true.  The
      identifier of the specific workflow step being executed.




Goswami                    Expires 4 July 2026                 [Page 12]

Internet-Draft            Agentic JWT Protocol             December 2025


   workflow_enabled:  OPTIONAL.  Boolean indicating whether workflow
      validation should be enforced.  Default: false.

   requested_scopes:  REQUIRED.  Array of OAuth 2.0 scopes requested for
      this token.

   audience:  REQUIRED.  The intended audience (resource server) for the
      token.  May be a single string or array of strings.

   delegation_context:  OPTIONAL.  Object containing delegation chain
      information for multi-agent workflows.  Contains "chain" (array of
      parent agent_ids) and "completed_steps" (array of completed
      workflow step identifiers).

4.2.2.  Request Example

   Example HTTP request (with line breaks for readability):

       POST /intent/token HTTP/1.1
       Host: idp.example.com
       Content-Type: application/json
       Authorization: Bearer <admin_token>

       {
         "grant_type": "agent_checksum",
         "agent_id": "vulnerability-patcher-v1",
         "computed_checksum": "sha256:a3c7f2e8d9b4f1e2c8a7d6f3e9b2c4f1...",
         "workflow_id": "auto-patch-workflow-v1",
         "workflow_step": "step_3_patch_application",
         "workflow_enabled": true,
         "requested_scopes": [
           "repo:write",
           "vulnerability:read"
         ],
         "audience": "https://api.github.com",
         "delegation_context": {
           "chain": [
             "supervisor-agent",
             "planner-agent",
             "vulnerability-patcher-v1"
           ],
           "completed_steps": [
             "step_1_analyze_manifest",
             "step_2_create_patch_plan"
           ]
         }
       }




Goswami                    Expires 4 July 2026                 [Page 13]

Internet-Draft            Agentic JWT Protocol             December 2025


4.2.3.  Request Authentication

   The token endpoint MUST be protected.  In the reference
   implementation, requests require an Authorization header with a
   bearer token that has the "generate:intent-token" scope and audience
   "idp.localhost".  This token may well be the usual JWT client level
   access token that uses one of the traditional OAuth 2.0 Authorization
   Grants [RFC6749].

   Implementations MAY use different authentication mechanisms (e.g.,
   client credentials, mutual TLS) but MUST ensure that only authorized
   entities can request tokens on behalf of agents.

4.3.  Authorization Server Processing

4.3.1.  Validation Sequence

   Upon receiving a token request, the authorization server MUST perform
   the following validation steps IN ORDER:

   1.  *Grant Type Validation:* Verify that grant_type equals
       "agent_checksum".  If invalid → Return error
       "unsupported_grant_type" (Section 4.5.2)

   2.  *Agent Existence Check:* Verify that agent_id exists in the agent
       registry.  If not found → Return error "unknown_agent"
       (Section 4.5.3)

   3.  *Checksum Verification:* Retrieve the registered checksum for
       agent_id.  Compare computed_checksum with the stored checksum.
       If mismatch → Return error "agent_checksum_mismatch"
       (Section 4.5.4)

   4.  *Workflow Step Authorization (if workflow_enabled):* Validate
       that the agent is authorized to execute the specified
       workflow_step within workflow_id.  Verify prerequisite steps are
       completed (from delegation_context).  Check approval requirements
       if step requires approval.  If unauthorized → Return error
       "workflow_step_unauthorized" (Section 4.5.5

   5.  *Token Creation:* If all validations pass, create and sign the
       intent token (Section 2).

4.3.2.  Checksum Verification Details

   For the checksum verification procedure please see Section 5.5.2





Goswami                    Expires 4 July 2026                 [Page 14]

Internet-Draft            Agentic JWT Protocol             December 2025


4.3.3.  Workflow Step Validation

   When workflow_enabled is true, the authorization server MUST validate
   the workflow execution state:

   1.  Verify that workflow_id exists in the workflow registry

   2.  Verify that workflow_step exists within the workflow definition

   3.  Check that all required prerequisite steps have been completed:

       *  Retrieve the step definition for workflow_step

       *  Identify all steps marked as "required" that appear before
          workflow_step in the workflow sequence

       *  Verify all required steps are present in
          delegation_context.completed_steps

   4.  If the step has requires_approval=true:

       *  Locate the most recent approval gate step before workflow_step

       *  Verify that approval gate step is in completed_steps

       *  If no approval gate found or not completed → reject request

   This validation ensures that agents cannot skip required steps or
   bypass approval gates in multi-step workflows.

4.3.4.  Delegation Chain Validation

   If delegation_context is provided, the authorization server SHOULD
   validate the delegation chain:

   *  Verify that all agents in the chain are registered

   *  Verify that the chain represents a valid delegation path (parent
      agents authorized the delegation)

   *  Verify that the requesting agent is the last element in the chain

   The delegation_context.chain array represents the delegation
   hierarchy from the original initiating agent to the current agent.
   For example: ["supervisor", "planner", "patcher"] indicates that the
   supervisor delegated to the planner, which delegated to the patcher.





Goswami                    Expires 4 July 2026                 [Page 15]

Internet-Draft            Agentic JWT Protocol             December 2025


4.4.  Successful Response

4.4.1.  Response Format

   If the request is valid and all verification checks pass, the
   authorization server issues an intent token and returns it in the
   response:

       HTTP/1.1 200 OK
       Content-Type: application/json
       Cache-Control: no-store
       Pragma: no-cache

       {
         "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6...",
         "token_type": "Bearer",
         "expires_in": 300,
         "scope": "repo:write vulnerability:read"
       }

   Response fields:

   access_token:  REQUIRED.  The intent token encoded as a JWT.

   token_type:  REQUIRED.  MUST be "Bearer".

   expires_in:  RECOMMENDED.  Lifetime in seconds.  For intent tokens,
      this SHOULD be short (e.g., 300 seconds / 5 minutes).

   scope:  OPTIONAL.  Space-delimited list of scopes granted.  MAY
      differ from requested_scopes if authorization server applies
      restrictions.

4.4.2.  Intent Token Structure

   The intent token is a JWT [RFC7519] with the following claims:

   *Standard JWT Claims:*

   iss (Issuer):  REQUIRED.  Authorization server identifier.

   aud (Audience):  REQUIRED.  Intended recipient(s).  Value from
      request.audience.

   sub (Subject):  REQUIRED.  Agent identifier (request.agent_id).

   exp (Expiration):  REQUIRED.  Token expiration time (Unix timestamp).
      SHOULD be iat + 300 seconds for intent tokens.



Goswami                    Expires 4 July 2026                 [Page 16]

Internet-Draft            Agentic JWT Protocol             December 2025


   iat (Issued At):  REQUIRED.  Token issuance time (Unix timestamp).

   jti (JWT ID):  REQUIRED.  Unique token identifier for replay
      prevention.

   scope:  REQUIRED.  Space-delimited OAuth 2.0 scopes.

   *Proof-of-Possession Claim:*

   cnf (Confirmation):  REQUIRED.  Proof-of-possession confirmation as
      defined in RFC 7800 [RFC7800].  Contains "jwk" field with the
      agent's public key in JWK format.

   *Intent-Specific Claims (nested under "intent" object):*

   workflow_id:  REQUIRED when workflow_enabled.  Workflow identifier.

   workflow_step:  REQUIRED when workflow_enabled.  Current step
      identifier.

   executed_by:  REQUIRED.  Agent executing this step (same as sub).

   delegation_chain:  REQUIRED.  Cryptographic hash of the delegation
      sequence.  Computed as SHA-256 over the pipe-delimited chain of
      agent_ids, truncated to 16 hex characters.  See Section 4.4.4

   step_sequence_hash:  REQUIRED.  Cryptographic hash of completed
      workflow steps.  Computed as SHA-256 over pipe-delimited completed
      step IDs, truncated to 16 hex characters.  See Section 4.4.4

   *Agent Proof Claims (nested under "agent_proof" object):*

   agent_checksum:  REQUIRED.  The verified agent checksum (from
      request.computed_checksum).  See Section 5 for detailed agent
      identity and checksum analysis.

   registration_id:  REQUIRED.  The registration identifier from the
      agent registry, enabling token revocation at the registration
      level.

4.4.3.  Token Example

   Example decoded intent token payload:








Goswami                    Expires 4 July 2026                 [Page 17]

Internet-Draft            Agentic JWT Protocol             December 2025


       {
         "iss": "https://idp.example.com",
         "aud": "https://api.github.com",
         "sub": "vulnerability-patcher-v1",
         "exp": 1735690800,
         "iat": 1735690500,
         "jti": "token_a3f7e89c",
         "scope": "repo:write vulnerability:read",
         "cnf": {
           "jwk": {
             "kty": "RSA",
             "use": "sig",
             "alg": "RS256",
             "n": "xGOr-H7A-PWi...",
             "e": "AQAB"
           }
         },
         "intent": {
           "workflow_id": "auto-patch-workflow-v1",
           "workflow_step": "step_3_patch_application",
           "executed_by": "vulnerability-patcher-v1",
           "delegation_chain": "f3e8d9c7b2a41a3c",
           "step_sequence_hash": "a7c9e2f4b8d61c3f"
         },
         "agent_proof": {
           "agent_checksum": "sha256:a3c7f2e8d9b4f1e2c8a7d6f3e9b2c4f1...",
           "registration_id": "reg_vulnerability-patcher-v1_1735680000"
         }
       }

4.4.4.  Sequence Hash Computation

   The delegation_chain and step_sequence_hash provide cryptographic
   integrity over the workflow execution path:

   *Delegation Chain Hash:*

       # Input: delegation_context.chain + current agent_id
       chain = ["supervisor", "planner", "patcher"]
       chain_string = "supervisor|planner|patcher"
       hash = SHA256(chain_string.encode('utf-8'))
       delegation_chain = hash.hexdigest()[:16]
       # Result: "f3e8d9c7b2a41a3c"

   *Step Sequence Hash:*






Goswami                    Expires 4 July 2026                 [Page 18]

Internet-Draft            Agentic JWT Protocol             December 2025


       # Input: delegation_context.completed_steps + current step
       steps = ["step_1_analyze", "step_2_plan", "step_3_patch"]
       steps_string = "step_1_analyze|step_2_plan|step_3_patch"
       hash = SHA256(steps_string.encode('utf-8'))
       step_sequence_hash = hash.hexdigest()[:16]
       # Result: "a7c9e2f4b8d61c3f"

   If an agent has skipped steps or altered the delegation chain, the
   IDP side library will be able to detect during intent token request.
   However, including these hashes in the intent token additionally
   enables resource servers to detect if an agent has skipped steps or
   altered the delegation chain.

4.5.  Error Responses

4.5.1.  Error Response Format

   Error responses follow the OAuth 2.0 error response format defined in
   Section 5.2 of RFC 6749 [RFC6749]:

       HTTP/1.1 400 Bad Request
       Content-Type: application/json
       Cache-Control: no-store
       Pragma: no-cache

       {
         "error": "agent_checksum_mismatch",
         "error_description": "Agent checksum mismatch - code integrity violation",
         "error_uri": "https://idp.example.com/docs/errors#checksum_mismatch"
       }

4.5.2.  unsupported_grant_type

   Error Code: unsupported_grant_type

   HTTP Status: 400 Bad Request

   Description: The grant_type parameter does not equal
   "agent_checksum".

   Example:

       {
         "error": "unsupported_grant_type",
         "error_description": "Grant type must be 'agent_checksum'"
       }





Goswami                    Expires 4 July 2026                 [Page 19]

Internet-Draft            Agentic JWT Protocol             December 2025


4.5.3.  unknown_agent

   Error Code: unknown_agent

   HTTP Status: 401 Unauthorized

   Description: The agent_id is not registered with the authorization
   server.

   Recommended Action: Agent must complete registration (Section 6.1)
   before requesting tokens.

   Example:

       {
         "error": "unknown_agent",
         "error_description": "Agent ID not found in registry. Register first."
       }

4.5.4.  agent_checksum_mismatch

   Error Code: agent_checksum_mismatch

   HTTP Status: 401 Unauthorized

   Description: The computed_checksum does not match the registered
   checksum for the agent_id.  This indicates that the agent's
   configuration (prompt, tools, or model parameters) has been modified
   since registration.

   Security Implication: This is a critical security error that may
   indicate:

   *  Unauthorized modification of the agent

   *  Attempted impersonation attack

   *  Code integrity violation

   Recommended Action: Agent must re-register with updated checksum
   before requesting tokens.  Authorization server SHOULD log this event
   for security monitoring.

   Example:







Goswami                    Expires 4 July 2026                 [Page 20]

Internet-Draft            Agentic JWT Protocol             December 2025


       {
         "error": "agent_checksum_mismatch",
         "error_description": "Agent checksum mismatch - code integrity violation",
         "error_uri": "https://idp.example.com/docs/errors#checksum_mismatch"
       }

4.5.5.  workflow_step_unauthorized

   Error Code: workflow_step_unauthorized

   HTTP Status: 403 Forbidden

   Description: The agent is not authorized to execute the specified
   workflow_step.  This may occur when:

   *  Prerequisite steps have not been completed

   *  Required approval gate has not been passed

   *  Step is not defined in the workflow

   *  Agent is not assigned to this workflow step

   Recommended Action: Review workflow definition and ensure all
   required prerequisites are met.

   Example:

       {
         "error": "workflow_step_unauthorized",
         "error_description": "Agent not authorized for workflow step.
                               Required prerequisite steps not completed.",
         "missing_steps": ["step_1_analyze_manifest", "step_2_approval_gate"]
       }

4.5.6.  invalid_request

   Error Code: invalid_request

   HTTP Status: 400 Bad Request

   Description: The request is malformed or missing required parameters.
   Common causes:

   *  Missing required fields (agent_id, computed_checksum, etc.)

   *  Invalid JSON format




Goswami                    Expires 4 July 2026                 [Page 21]

Internet-Draft            Agentic JWT Protocol             December 2025


   *  workflow_enabled=true but workflow_id/workflow_step missing

   *  Invalid checksum format (must be "sha256:<hex>")

   Example:

       {
         "error": "invalid_request",
         "error_description": "Missing required parameter: computed_checksum"
       }

4.6.  Auth Grant Security Considerations

   For grant type specific security considerations, see:

   *  Checksum verification: Section 9.1.1

   *  Token lifetime: Section Section 9.2.1

   *  Workflow validation: Section 9.3

   For comprehensive security analysis, see Section 9.

4.7.  Implementation Notes

4.7.1.  Agent Registry

   The authorization server maintains an agent registry mapping agent_id
   to registration records.  Each record contains:

   *  agent_id - Unique identifier

   *  checksum - SHA-256 agent checksum

   *  registration_id - Unique registration instance ID

   *  public_key - Agent's public key (for cnf claim)

   *  registered_at - Registration timestamp

   *  version - Registration version (for checksum updates)

   Multiple registrations may exist for the same agent_id when the
   agent's configuration changes.  The authorization server uses the
   LATEST registration for verification.






Goswami                    Expires 4 July 2026                 [Page 22]

Internet-Draft            Agentic JWT Protocol             December 2025


4.7.2.  Workflow Registry

   The workflow registry stores workflow definitions including:

   *  workflow_id - Unique workflow identifier

   *  steps - Ordered array of workflow step definitions

   Each step contains:

   *  step_id - Unique step identifier

   *  required - Boolean indicating if step is required

   *  requires_approval - Boolean for approval requirement

   *  approval_gate - Boolean marking this step as approval gate

   *  agent_id - Agent authorized to execute this step (optional)

4.7.3.  Performance Considerations

   The checksum verification and workflow validation add overhead to
   token issuance.  Implementations SHOULD:

   *  Cache agent registry lookups to reduce database queries

   *  Use indexed database queries on agent_id for fast lookup

   *  Pre-compute workflow step dependencies to speed validation

   *  Implement connection pooling for registry data stores

   The reference implementation shows ~4.3% overhead compared to
   standard OAuth 2.0 token issuance, which is acceptable for most
   production deployments.

5.  Agent Identity

5.1.  Overview

   Agent identity in this specification is based on cryptographic
   checksums computed over an agent's configuration.  Unlike traditional
   client credentials that can be shared or stolen, the agent checksum
   provides a unique cryptographic fingerprint of the agent's actual
   implementation.

   The agent checksum serves three critical functions:



Goswami                    Expires 4 July 2026                 [Page 23]

Internet-Draft            Agentic JWT Protocol             December 2025


   *  *Identity Verification:* Proves that an agent's configuration
      matches what was registered with the authorization server

   *  *Code Integrity:* Detects unauthorized modifications to the
      agent's system prompt, tools, or configuration

   *  *Non-Transferability:* Prevents credentials from being reused by
      different agent implementations

   This section defines how agent identity is established, verified, and
   maintained throughout the agent lifecycle.

5.2.  Agent Configuration Structure

5.2.1.  Agent Specification

   An agent's identity is derived from its specification, which includes
   all components that define the agent's behavior:

   agent_id:
      REQUIRED.  Unique identifier for the agent.  MUST be unique within
      the application scope.  Format: alphanumeric with hyphens, e.g.,
      "vulnerability-patcher-v1".

   prompt:
      REQUIRED.  The complete system prompt that defines the agent's
      role, capabilities, and constraints.  This is the full text
      provided to the language model that shapes agent behavior.

   tools:
      REQUIRED.  Array of tool definitions available to the agent.  Each
      tool includes name, description, and parameter schema.  The order
      of tools MUST be deterministic.

   configuration:
      OPTIONAL.  Additional configuration parameters including:

      *  model_name - Language model identifier

      *  temperature - Sampling temperature (0.0-1.0)

      *  max_tokens - Maximum generation length

      *  top_p - Nucleus sampling parameter







Goswami                    Expires 4 July 2026                 [Page 24]

Internet-Draft            Agentic JWT Protocol             December 2025


5.2.2.  Example Agent Specification

   Example agent specification for a vulnerability patching agent:

       {
         "agent_id": "vulnerability-patcher-v1",
         "prompt": "You are a security agent responsible for patching
                   vulnerabilities in software dependencies. Analyze
                   manifests, identify vulnerable packages, and generate
                   patches. Always verify changes before committing.",
         "tools": [
           {
             "name": "read_manifest",
             "description": "Read package manifest file",
             "parameters": {
               "type": "object",
               "properties": {
                 "file_path": {"type": "string"}
               },
               "required": ["file_path"]
             }
           },
           {
             "name": "check_vulnerability",
             "description": "Check package for known vulnerabilities",
             "parameters": {
               "type": "object",
               "properties": {
                 "package": {"type": "string"},
                 "version": {"type": "string"}
               },
               "required": ["package", "version"]
             }
           },
           {
             "name": "create_patch",
             "description": "Create patch for vulnerable package",
             "parameters": {
               "type": "object",
               "properties": {
                 "package": {"type": "string"},
                 "current_version": {"type": "string"},
                 "target_version": {"type": "string"}
               },
               "required": ["package", "current_version", "target_version"]
             }
           }
         ],



Goswami                    Expires 4 July 2026                 [Page 25]

Internet-Draft            Agentic JWT Protocol             December 2025


         "configuration": {
           "model_name": "claude-3-5-sonnet-20241022",
           "temperature": 0.0,
           "max_tokens": 4096
         }
       }

5.2.3.  Tool Checksum Levels

   Tools may be included in the checksum computation at two levels:

   Shallow (Default):  Only the tool signature (name, description,
      parameters) is included in the checksum.  The actual function
      implementation is not hashed.  This allows tool implementation to
      evolve without requiring re-registration.

   Deep:  The complete tool implementation, including normalized
      function source code, is included in the checksum.  This provides
      stronger integrity guarantees but requires re-registration for any
      code changes.

   Implementations MUST support shallow checksums.  Deep checksums are
   OPTIONAL and MAY be indicated through tool metadata.

   In the reference implementation, tools are marked for deep
   checksumming using a decorator:

       @secure_tool(name="critical_operation", checksum_level=ChecksumLevel.deep)
       def critical_operation(params):
           # Tool implementation included in checksum
           pass

   When including source code in deep checksums, implementations MUST
   normalize the source code to ensure formatting changes do not affect
   checksums while logic changes are always detected.

5.2.4.  Tool Signature Normalization

   Tool function signatures MUST be normalized to remove framework-
   specific wrapper parameters that do not affect agent behavior.  This
   ensures that checksums remain stable across different agent
   frameworks.

   *Wrapper Parameters to Remove:*

   *  config - Framework configuration object

   *  callbacks - Callback handlers



Goswami                    Expires 4 July 2026                 [Page 26]

Internet-Draft            Agentic JWT Protocol             December 2025


   *  run_manager - Execution manager

   *  tags - Execution tags

   *  metadata - Execution metadata

   *  run_id - Execution identifier

   *  **kwargs - Catchall for framework parameters

   Reference implementation for signature normalization:








































Goswami                    Expires 4 July 2026                 [Page 27]

Internet-Draft            Agentic JWT Protocol             December 2025


       import inspect

       def get_core_signature(func) -> str:
           """
           Get function signature with wrapper parameters removed.
           """
           # Unwrap decorators to get original function
           current = func
           try:
               current = inspect.unwrap(func)
           except (ValueError, AttributeError):
               pass

           sig = inspect.signature(current)

           # Known wrapper parameters to filter out
           WRAPPER_PARAMS = {
               'config', 'callbacks', 'run_manager', 'tags', 'metadata',
               'run_id', 'parent_run_id', 'configurable', 'recursion_limit'
           }

           # Build cleaned parameter list
           cleaned_params = []

           for name, param in sig.parameters.items():
               # Skip known wrapper params
               if name in WRAPPER_PARAMS:
                   continue

               # Skip VAR_KEYWORD (**kwargs) if it looks like wrapper catchall
               if param.kind == inspect.Parameter.VAR_KEYWORD:
                   continue

               # Skip VAR_POSITIONAL (*args) used by wrappers
               if param.kind == inspect.Parameter.VAR_POSITIONAL and name == 'args':
                   continue

               cleaned_params.append(param)

           # Create new signature
           new_sig = inspect.Signature(
               cleaned_params,
               return_annotation=sig.return_annotation
           )

           return str(new_sig)





Goswami                    Expires 4 July 2026                 [Page 28]

Internet-Draft            Agentic JWT Protocol             December 2025


   This normalization is CRITICAL for cross-framework compatibility.
   Without it, the same logical tool would have different checksums when
   used in LangChain [LANGCHAIN] vs CrewAI [CREWAI] vs other frameworks.
   [LANGGRAPH]

5.2.5.  Source Code Normalization

   For deep checksum tools that include source code, implementations
   MUST normalize the source code using Abstract Syntax Tree (AST)
   parsing.  This ensures that formatting changes do not affect
   checksums while any logic changes are always detected.

   Normalization process:

   1.  Parse source code to AST (Abstract Syntax Tree)

   2.  Remove docstrings (captured separately in tool description)

   3.  Remove comments (not part of execution logic)

   4.  Unparse AST to canonical form

   Reference implementation:

       import ast
       import textwrap
       import inspect

       def remove_docstrings(tree: ast.AST) -> None:
           """
           Remove docstring nodes from AST in-place.

           Docstrings are captured separately in tool description,
           so we remove them from implementation to avoid duplication.
           """
           for node in ast.walk(tree):
               if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef,
                                   ast.ClassDef, ast.Module)):
                   if (node.body and
                       isinstance(node.body[0], ast.Expr) and
                       isinstance(node.body[0].value, ast.Constant) and
                       isinstance(node.body[0].value.value, str)):
                       # This is a docstring - remove it
                       node.body = node.body[1:] if len(node.body) > 1 else [ast.Pass()]

       def normalize_source(source_code: str) -> str:
           """
           Normalize Python source code using AST.



Goswami                    Expires 4 July 2026                 [Page 29]

Internet-Draft            Agentic JWT Protocol             December 2025


           This ensures that formatting changes don't affect checksums
           while logic changes are always detected.

           Strips:
               - Comments (not part of execution logic)
               - Formatting differences (whitespace, indentation)
               - Docstrings (captured separately in checksum)

           Preserves:
               - All execution logic
               - Variable names (semantically significant)
               - Control flow structures
               - Function calls and their arguments
           """
           # Remove leading indentation
           source = textwrap.dedent(source_code)

           try:
               # Parse to AST
               tree = ast.parse(source)

               # Remove docstrings
               remove_docstrings(tree)

               # Unparse to canonical form
               normalized = ast.unparse(tree)

               return normalized

           except SyntaxError:
               # If code has syntax errors, return as-is
               # This will cause checksum mismatch (correct behavior)
               return source

       def get_tool_source_code(func: callable) -> str | None:
           """
           Get normalized source code for a tool function.
           Returns None if source cannot be retrieved.
           """
           try:
               source = inspect.getsource(func)
               normalized = normalize_source(source)
               return normalized
           except (OSError, TypeError):
               return None

   This normalization means:




Goswami                    Expires 4 July 2026                 [Page 30]

Internet-Draft            Agentic JWT Protocol             December 2025


   *  *SAME checksum:* Reformatting code, adding comments, changing
      indentation

   *  *DIFFERENT checksum:* Changing logic, adding/removing statements,
      modifying control flow

   Example demonstrating normalization:

       # These produce IDENTICAL checksums after normalization:

       def example1(x):
           # This is a comment
           return x + 1

       def example1(x): return x+1  # inline

       def example1(x):
           """Docstring here"""
           return x + 1


       # This produces DIFFERENT checksum:

       def example1(x):
           return x + 2  # Logic changed

5.3.  Checksum Computation

5.3.1.  Computation Algorithm

   The agent checksum MUST be computed as follows:

   1.  *Construct Agent Components Object:* Create a JSON object
       containing the agent's configuration:

















Goswami                    Expires 4 July 2026                 [Page 31]

Internet-Draft            Agentic JWT Protocol             December 2025


          {
            "agent_id": "string",
            "prompt_template": "string",
            "tools": [
              {
                "name": "string",
                "description": "string",
                "parameters": { /* JSON schema */ }
              }
            ],
            "configuration": {
              "model_name": "string",
              "temperature": number,
              "max_tokens": number
            }
          }

   2.  *Canonicalize JSON:* Serialize the object using RFC 8785
       [RFC8785] JSON Canonicalization Scheme (JCS).  This ensures
       deterministic ordering of keys and consistent formatting.

       Canonical serialization is REQUIRED because:

       *  JSON objects have no inherent key ordering

       *  Whitespace and formatting vary across implementations

       *  Floating point precision may differ

       *  Unicode escaping can be inconsistent

   3.  *Compute SHA-256 Hash:* Hash the canonical JSON bytes using
       SHA-256 as defined in FIPS 180-4 [FIPS-180-4].

   4.  *Format Checksum:* Encode the hash as lowercase hexadecimal (64
       characters):

          checksum = hex(hash_bytes).lowercase()
          # Result: "a3c7f2e8d9b4f1e2c8a7d6f3e9b2c4f1a8e7d3c2b5f4e9..."

       Note: The reference implementation uses bare hex encoding.
       Implementations MAY prefix with "sha256:" for explicit algorithm
       identification.

5.3.2.  Implementation Guidance

   Implementations MUST ensure checksum computation is deterministic
   across different platforms, languages, and runtime environments.



Goswami                    Expires 4 July 2026                 [Page 32]

Internet-Draft            Agentic JWT Protocol             December 2025


   *Reference Implementation (Python):*

       import hashlib
       import json

       def normalize_prompt(prompt: str) -> str:
           """
           Normalize prompt string for consistent checksum computation.
           Apply this in BOTH client and server-side computation.
           """
           if not prompt:
               return ""

           # 1. Strip leading/trailing whitespace
           normalized = prompt.strip()

           # 2. Normalize line endings (Windows \r\n vs Unix \n)
           normalized = normalized.replace('\r\n', '\n')

           # 3. Collapse multiple consecutive newlines into single newline
           import re
           normalized = re.sub(r'\n\s*\n', '\n', normalized)

           # 4. Strip whitespace from each line
           lines = [line.strip() for line in normalized.split('\n')]
           normalized = '\n'.join(lines)

           # 5. Remove empty lines
           lines = [line for line in lines if line]
           normalized = '\n'.join(lines)

           return normalized

       def compute_agent_checksum(agent_components) -> str:
           """
           Compute deterministic SHA-256 checksum for agent configuration.

           Args:
               agent_components: Object with fields:
                   - agent_id: str
                   - prompt_template: str
                   - tools: list of Tool objects
                   - configuration: dict

           Returns:
               64-character lowercase hex string (SHA-256 hash)
           """
           # Construct canonical components object



Goswami                    Expires 4 July 2026                 [Page 33]

Internet-Draft            Agentic JWT Protocol             December 2025


           components = {
               "id": agent_components.agent_id,
               "prompt": normalize_prompt(agent_components.prompt_template),
               "tools": sorted([
                   {
                       "name": tool.name,
                       "signature": tool.signature,
                       "description": tool.description
                       # "source_code" included only for deep checksum tools
                   }
                   for tool in agent_components.tools
               ], key=lambda x: x["name"]),  # Sort tools by name
               "config": agent_components.configuration
           }

           # Serialize with sorted keys for determinism
           content = json.dumps(components, sort_keys=True)

           # Compute SHA-256 hash
           return hashlib.sha256(content.encode('utf-8')).hexdigest()

   *Critical Requirements:*

   *  Use json.dumps() with sort_keys=True for deterministic JSON
      serialization

   *  Normalize prompts using the exact normalization function above
      (whitespace, line endings, empty lines)

   *  Sort tools by name before serialization

   *  Encode JSON string as UTF-8 before hashing

   *  Output lowercase hexadecimal (64 characters)

   *  Tool signatures MUST use get_core_signature() to remove wrapper
      parameters (see Section 4.2.4)

   *Common Implementation Pitfalls:*

   *  Not normalizing prompts identically on client and server (most
      common cause of checksum mismatch)

   *  Including wrapper function parameters in tool signatures (config,
      callbacks, run_manager, etc.)

   *  Platform-specific line endings (\r\n vs \n) in prompts




Goswami                    Expires 4 July 2026                 [Page 34]

Internet-Draft            Agentic JWT Protocol             December 2025


   *  Non-deterministic tool ordering (MUST sort by name)

   *  Using standard JSON.stringify() without sort_keys

   *  Uppercase hexadecimal encoding (MUST be lowercase)

5.4.  Agent Registration

5.4.1.  Registration Overview

   Before an agent can request tokens, it MUST register its checksum
   with the authorization server.  Registration creates a binding
   between the agent_id and its cryptographic identity.

   The registration process:

   1.  Agent computes its checksum client-side

   2.  Agent sends registration request to IDP

   3.  IDP validates agent configuration

   4.  IDP recomputes checksum for verification

   5.  IDP stores agent_id → checksum mapping

   6.  IDP returns registration confirmation

5.4.2.  IDP Processing

   The authorization server MUST perform the following steps:

   1.  *Validate Request Structure:* Verify all required fields are
       present and properly formatted

   2.  *Compute Checksum:* Recompute agent checksum from
       agent_components using the algorithm defined in Section 4.2.1

   3.  *Check for Duplicates:* Verify that the computed checksum does
       not already exist in the registry.  If it does, reject with error
       "duplicate_agent".  This prevents agent impersonation.

   4.  *Generate Registration ID:* Create unique registration
       identifier:

          registration_id = "reg_" + agent_id + "_" + timestamp

   5.  *Store Registration:* Persist mapping:



Goswami                    Expires 4 July 2026                 [Page 35]

Internet-Draft            Agentic JWT Protocol             December 2025


          {
            "agent_id": "vulnerability-patcher-v1",
            "registration_id": "reg_vulnerability-patcher-v1_1735680000",
            "checksum": "a3c7f2e8d9b4f1e2c8a7d6f3e9b2c4f1a8e7d3c2b5f4e9a7c3d8f2b6e1a9c4f7",
            "prompt": "You are a security agent...",
            "tools": [ /* tool definitions */ ],
            "public_key": "-----BEGIN PUBLIC KEY-----...",
            "registered_at": 1735680000000,
            "app_id": "vulnerability-patcher-app",
            "version": 1
          }

   6.  *Return Confirmation:* Return registration details to client

5.4.3.  Registration Response

   Success response:

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

       {
         "agent_id": "vulnerability-patcher-v1",
         "registration_id": "reg_vulnerability-patcher-v1_1735680000",
         "checksum": "a3c7f2e8d9b4f1e2c8a7d6f3e9b2c4f1a8e7d3c2b5f4e9a7c3d8f2b6e1a9c4f7"
       }

   Error response (duplicate checksum):

       HTTP/1.1 400 Bad Request
       Content-Type: application/json

       {
         "error": "duplicate_agent",
         "error_description": "Agent with identical checksum already exists",
         "existing_agent_id": "other-agent-v1"
       }

5.4.4.  Agent Updates

   When an agent's configuration changes (e.g., tool updates, prompt
   modifications), a new checksum is computed and the agent MUST re-
   register.








Goswami                    Expires 4 July 2026                 [Page 36]

Internet-Draft            Agentic JWT Protocol             December 2025


   *NOTE:* This registration process can be automated by introdcuing
   additional steps into CI / CD or by Model Context Protocol (MCP,
   [MCP]) integration to the IDP server, or by any other agent resource
   management process.  Regardless of the methodology used the
   underlying conceptual process remains the same.

   Update procedure:

   1.  Compute new checksum from updated configuration

   2.  Submit new registration request (same agent_id)

   3.  IDP validates new checksum is different from previous

   4.  IDP creates new registration record with incremented version

   5.  IDP MAY maintain previous registrations for audit trail

   6.  IDP uses LATEST registration for token validation

   Example: Agent version progression

       // Version 1 (original)
       {
         "agent_id": "patcher-v1",
         "checksum": "aaa1234567890abcdef1234567890abcdef1234567890abcdef1234567890abc",
         "version": 1,
         "registered_at": 1735680000000
       }

       // Version 2 (tool updated)
       {
         "agent_id": "patcher-v1",
         "checksum": "bbb9876543210fedcba9876543210fedcba9876543210fedcba9876543210fed",
         "version": 2,
         "registered_at": 1735690000000
       }

   The IDP MUST use the latest version (highest registered_at) for
   checksum verification during token requests.

5.5.  Checksum Verification

5.5.1.  Client-Side Verification

   Before requesting a token, the agent MUST compute its current
   checksum and include it in the token request.  This proves that the
   requesting agent's configuration matches the registered identity.



Goswami                    Expires 4 July 2026                 [Page 37]

Internet-Draft            Agentic JWT Protocol             December 2025


   Client-side process:

       # 1. Detect current agent context
       agent_spec = get_current_agent_spec()

       # 2. Compute checksum from current configuration
       current_checksum = compute_agent_checksum(agent_spec)

       # 3. Include in token request
       token_request = {
           "grant_type": "agent_checksum",
           "agent_id": agent_spec.agent_id,
           "computed_checksum": current_checksum,
           ...
       }

5.5.2.  Server-Side Verification

   Upon receiving a token request, the authorization server MUST verify
   the agent checksum:

       # From intent.py implementation

       # 1. Retrieve registered checksum
       registered_checksums = registry.get_agent(agent_id)
       stored_checksum = registered_checksums[-1].checksum  # Latest version

       # 2. Compare with submitted checksum (constant-time)
       if computed_checksum != stored_checksum:
           raise AgentChecksumMismatch(
               "Agent checksum mismatch - code integrity violation"
           )

   The comparison MUST use constant-time string comparison to prevent
   timing attacks that could reveal checksum information.

   NOTE: The authorization server retrieves the LATEST registration for
   the agent_id, as agents may re-register with updated checksums when
   their configuration changes.

5.6.  Identity Lifecycle

5.6.1.  Lifecycle Stages

   Agent identity progresses through several stages:

   1.  *UNREGISTERED:* Agent exists but has not registered with IDP.
       Cannot request tokens.



Goswami                    Expires 4 July 2026                 [Page 38]

Internet-Draft            Agentic JWT Protocol             December 2025


   2.  *REGISTERED:* Agent checksum stored in IDP registry.  Can request
       tokens if checksum matches.

   3.  *VERIFIED:* Agent successfully authenticated and obtained token.
       Identity confirmed through checksum match.

   4.  *UPDATED:* Agent configuration changed, new checksum computed,
       re-registration required.  Previous tokens may be invalidated.

   5.  *REVOKED:* Agent identity revoked by administrator.  All tokens
       invalidated.  Cannot request new tokens.

5.6.2.  State Transitions

   Valid state transitions:

     UNREGISTERED --[register]--> REGISTERED
                                       |
                                       v
     REGISTERED --[token request + checksum match]--> VERIFIED
                                       |
                                       v
     VERIFIED --[config change]--> UPDATED --[re-register]--> REGISTERED
                                       |
                                       v
     ANY STATE --[admin action]--> REVOKED

5.7.  Identity Security Considerations

   Agent identity security considerations:

   *  Checksum strength: See Section 9.1.2

   *  Registration security: See Section 9.1.3

   *  Agent Registry Security: See Section 9.1.4

   For comprehensive security analysis, see Section 9.

6.  Protocol Flows

6.1.  Overview

   This section describes the detailed protocol flows for agent
   registration, token issuance, and authorization.  Each flow includes
   step-by-step procedures, HTTP request/response examples, and
   validation requirements.




Goswami                    Expires 4 July 2026                 [Page 39]

Internet-Draft            Agentic JWT Protocol             December 2025


   The flows in this section build upon the abstract protocol flow
   described in Section 3.2, providing complete implementation guidance
   for:

   *  Agent registration and checksum verification

   *  Workflow registration and definition

   *  Intent token issuance with user approval

   *  Access token requests using agent_checksum grant

   *  API authorization and token validation

   *  Multi-agent delegation chains

6.2.  Agent Registration Flow

6.2.1.  Overview

   Before an agent can request tokens, it MUST register its identity
   with the authorization server.  This flow establishes the
   cryptographic binding between the agent_id and its configuration
   checksum.

6.2.2.  Sequence Diagram

   Agent registration sequence:























Goswami                    Expires 4 July 2026                 [Page 40]

Internet-Draft            Agentic JWT Protocol             December 2025


    ┌─────────┐              ┌─────────────┐         ┌──────────────┐
    │ Agent   │              │ Application │         │ IDP          │
    │ Runtime │              │ (Client)    │         │              │
    └────┬────┘              └──────┬──────┘         └──────┬───────┘
        │                          │                       │
        │ 1. Compute checksum      │                       │
        │<─────────────────────────│                       │
        │   compute_agent_checksum()│                       │
        │                          │                       │
        │ 2. Return checksum       │                       │
        │──────────────────────────>│                       │
        │                          │                       │
        │                          │ 3. POST /register/agent│
        │                          │──────────────────────>│
        │                          │   (agent_components,  │
        │                          │    public_key)        │
        │                          │                       │
        │                          │                       │ 4. Recompute
        │                          │                       │    checksum
        │                          │                       │<───────────
        │                          │                       │
        │                          │                       │ 5. Check for
        │                          │                       │    duplicates
        │                          │                       │<───────────
        │                          │                       │
        │                          │                       │ 6. Store
        │                          │                       │    registration
        │                          │                       │<───────────
        │                          │                       │
        │                          │ 7. Registration response│
        │                          │<──────────────────────│
        │                          │   (registration_id,   │
        │                          │    checksum)          │
        │                          │                       │

6.2.3.  Step-by-Step Procedure

   1.  *Agent Checksum Computation (Client-Side):* The agent runtime
       computes its configuration checksum using the algorithm defined
       in Section 5.3.  This includes the agent's prompt, tools, and
       configuration parameters.

   2.  *Public Key Generation (Optional):* If proof-of-possession
       [RFC7800] is required, the agent generates an RSA key pair and
       prepares the public key in PEM format.






Goswami                    Expires 4 July 2026                 [Page 41]

Internet-Draft            Agentic JWT Protocol             December 2025


   3.  *Registration Request:* The application sends a registration
       request to the IDP's agent registration endpoint, including the
       complete agent configuration and optional public key.

   4.  *Server-Side Checksum Verification:* The IDP recomputes the agent
       checksum from the submitted configuration and verifies it matches
       the claimed checksum.

   5.  *Duplicate Detection:* The IDP checks if the computed checksum
       already exists in the registry.  If found, the request is
       rejected with error "duplicate_agent" to prevent agent
       impersonation.

   6.  *Registration Storage:* The IDP creates a unique registration_id,
       stores the mapping (agent_id → checksum → registration_id), and
       persists the registration record.

   7.  *Response:* The IDP returns the registration_id and computed
       checksum to the client for verification.

6.3.  Workflow Registration Flow

6.3.1.  Overview

   Workflows define the sequence of steps that agents execute and the
   authorization requirements for each step.  Workflow registration
   establishes the workflow definition with the IDP before execution.

6.3.2.  Sequence Diagram






















Goswami                    Expires 4 July 2026                 [Page 42]

Internet-Draft            Agentic JWT Protocol             December 2025


        ┌─────────────┐                           ┌──────────────┐
        │ Application │                           │ IDP          │
        └──────┬──────┘                           └──────┬───────┘
              │                                         │
              │ 1. POST /register/workflow              │
              │────────────────────────────────────────>│
              │   (workflow_id, steps[])                │
              │                                         │
              │                                         │ 2. Validate
              │                                         │    structure
              │                                         │<───────────
              │                                         │
              │                                         │ 3. Check for
              │                                         │    duplicates
              │                                         │<───────────
              │                                         │
              │                                         │ 4. Store
              │                                         │    workflow
              │                                         │<───────────
              │                                         │
              │ 5. Registration confirmation            │
              │<────────────────────────────────────────│
              │   (workflow_id, status)                 │
              │                                         │

6.3.3.  HTTP Example

   Workflow registration request:























Goswami                    Expires 4 July 2026                 [Page 43]

Internet-Draft            Agentic JWT Protocol             December 2025


       POST /intent/register/workflow HTTP/1.1
       Host: idp.example.com
       Content-Type: application/json
       Authorization: Bearer <admin_token>

       {
         "workflow_id": "auto-patch-workflow-v1",
         "steps": {
           "step_1_analyze_manifest": {
             "required": true,
             "requires_approval": false,
             "agent_id": "vulnerability-analyzer"
           },
           "step_2_create_patch_plan": {
             "required": true,
             "requires_approval": false,
             "agent_id": "patch-planner"
           },
           "step_3_approval_gate": {
             "required": true,
             "requires_approval": false,
             "approval_gate": true
           },
           "step_4_apply_patch": {
             "required": true,
             "requires_approval": true,
             "agent_id": "vulnerability-patcher-v1"
           },
           "step_5_verify_patch": {
             "required": true,
             "requires_approval": false,
             "agent_id": "patch-verifier"
           }
         }
       }

   Success response:

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

       {
         "status": "registered",
         "workflow_id": "auto-patch-workflow-v1"
       }

6.4.  Token Request Flow




Goswami                    Expires 4 July 2026                 [Page 44]

Internet-Draft            Agentic JWT Protocol             December 2025


6.4.1.  Overview

   This flow describes how an agent requests an intent token using the
   agent_checksum grant type.  The flow includes agent identity
   verification, workflow step authorization, and token issuance.

6.4.2.  Sequence Diagram












































Goswami                    Expires 4 July 2026                 [Page 45]

Internet-Draft            Agentic JWT Protocol             December 2025


    ┌──────┐     ┌────────┐     ┌─────┐     ┌──────────┐     ┌──────────┐
    │Agent │     │Client  │     │User │     │IDP       │     │Registry  │
    └──┬───┘     └───┬────┘     └──┬──┘     └────┬─────┘     └────┬─────┘
      │             │              │             │                │
      │1. Trigger   │              │             │                │
      │────────────>│              │             │                │
      │             │              │             │                │
      │             │2. Compute    │             │                │
      │             │   checksum   │             │                │
      │<────────────│              │             │                │
      │             │              │             │                │
      │3. Checksum  │              │             │                │
      │────────────>│              │             │                │
      │             │              │             │                │
      │             │4. POST /token│             │                │
      │             │──────────────┼─────────────>│                │
      │             │  (agent_id,  │             │                │
      │             │   checksum,  │             │                │
      │             │   workflow)  │             │                │
      │             │              │             │                │
      │             │              │             │5. Get agent    │
      │             │              │             │   registration │
      │             │              │             │───────────────>│
      │             │              │             │                │
      │             │              │             │6. Registration │
      │             │              │             │<───────────────│
      │             │              │             │                │
      │             │              │             │7. Verify       │
      │             │              │             │   checksum     │
      │             │              │             │<───────────    │
      │             │              │             │                │
      │             │              │             │8. Validate     │
      │             │              │             │   workflow step│
      │             │              │             │<───────────    │
      │             │              │             │                │
      │             │              │             │9. Create token │
      │             │              │             │<───────────    │
      │             │              │             │                │
      │             │10. Token     │             │                │
      │             │<─────────────┼─────────────│                │
      │             │  response    │             │                │
      │             │              │             │                │

6.4.3.  Step-by-Step Procedure

   1.   *Execution Trigger:* Agent execution is triggered by application
        logic or user request.




Goswami                    Expires 4 July 2026                 [Page 46]

Internet-Draft            Agentic JWT Protocol             December 2025


   2.   *Checksum Computation:* Client computes current agent checksum
        using algorithm from Section 5.3.

   3.   *Checksum Return:* Agent runtime returns computed checksum to
        client library.

   4.   *Token Request:* Client sends token request to IDP with
        agent_checksum grant type, including agent_id, computed
        checksum, workflow details, and requested scopes.

   5.   *Registry Lookup:* IDP retrieves agent registration from
        registry based on agent_id.

   6.   *Registration Return:* Registry returns stored registration
        including registered checksum.

   7.   *Checksum Verification:* IDP compares computed_checksum (from
        request) with stored checksum.  If mismatch, return error
        "agent_checksum_mismatch".

   8.   *Workflow Step Validation:* If workflow_enabled=true, IDP
        validates:

        *  Workflow exists in registry

        *  Step exists in workflow definition

        *  Required prerequisite steps are completed

        *  Approval requirements are satisfied

        If validation fails, return error "workflow_step_unauthorized".

   9.   *Token Creation:* IDP creates intent token with:

        *  Standard JWT claims (iss, aud, sub, exp, iat, jti, scope)

        *  cnf claim with agent's public key

        *  intent object with workflow details

        *  agent_proof object with checksum and registration_id

   10.  *Token Response:* IDP returns token response with access_token,
        token_type, expires_in, and granted scopes.

6.5.  API Authorization Flow




Goswami                    Expires 4 July 2026                 [Page 47]

Internet-Draft            Agentic JWT Protocol             December 2025


6.5.1.  Overview

   This flow describes how a resource server validates an intent token
   and authorizes an API request from an agent.  The validation includes
   token signature verification, checksum validation, workflow binding
   checks, and scope verification.

6.5.2.  Sequence Diagram

           ┌──────┐     ┌────────┐     ┌──────────┐     ┌──────────┐
           │Agent │     │Client  │     │Resource  │     │IDP       │
           │      │     │        │     │Server    │     │(JWKS)    │
           └──┬───┘     └───┬────┘     └────┬─────┘     └────┬─────┘
             │             │               │                │
             │1. API call  │               │                │
             │────────────>│               │                │
             │             │               │                │
             │             │2. GET /api    │                │
             │             │──────────────>│                │
             │             │   Bearer token│                │
             │             │               │                │
             │             │               │3. Get JWKS     │
             │             │               │───────────────>│
             │             │               │                │
             │             │               │4. Public keys  │
             │             │               │<───────────────│
             │             │               │                │
             │             │               │5. Verify       │
             │             │               │   signature    │
             │             │               │<───────────    │
             │             │               │                │
             │             │               │6. Validate     │
             │             │               │   claims       │
             │             │               │<───────────    │
             │             │               │                │
             │             │               │7. Check scope  │
             │             │               │<───────────    │
             │             │               │                │
             │             │               │8. Process      │
             │             │               │   request      │
             │             │               │<───────────    │
             │             │               │                │
             │             │9. API response│                │
             │             │<──────────────│                │
             │             │               │                │
             │10. Result   │               │                │
             │<────────────│               │                │
             │             │               │                │



Goswami                    Expires 4 July 2026                 [Page 48]

Internet-Draft            Agentic JWT Protocol             December 2025


6.5.3.  Validation Steps

   1.  *Extract Token:* Resource server extracts Bearer token from
       Authorization header.

   2.  *Retrieve JWKS:* Resource server fetches IDP's JSON Web Key Set
       for signature verification.

   3.  *Verify Signature:* Resource server verifies JWT signature using
       IDP's public key identified by "kid" header.

   4.  *Validate Standard Claims:*

       *  Check token not expired (exp > current time)

       *  Validate issuer (iss matches expected IDP)

       *  Validate audience (aud matches resource server)

       *  Check token issued time (iat not in future)

   5.  *Validate Agent Proof:*

       *  Verify agent_proof.agent_checksum is present

       *  Verify agent_proof.registration_id is present

       *  Optionally verify checksum against known agents

   6.  *Validate Workflow Binding (if applicable):*

       *  Check intent.workflow_id matches expected workflow

       *  Verify intent.workflow_step is authorized for this API

       *  Validate delegation_chain if delegation is restricted

   7.  *Verify Scopes:* Check that requested operation is permitted by
       token scopes.

   8.  *Proof-of-Possession (Optional):* If required, verify PoP
       signature using public key in cnf claim.

   9.  *Process Request:* If all validations pass, execute the API
       operation.

6.6.  Multi-Agent Delegation Flow




Goswami                    Expires 4 July 2026                 [Page 49]

Internet-Draft            Agentic JWT Protocol             December 2025


6.6.1.  Overview

   Multi-agent workflows involve delegation chains where a supervisor
   agent delegates tasks to subordinate agents.  Each agent in the chain
   requests its own token, building upon the delegation context from
   parent agents.

   This flow illustrates a three-agent delegation chain for automated
   vulnerability patching:

   *  Supervisor Agent - Orchestrates the workflow

   *  Planner Agent - Creates patch strategy

   *  Patcher Agent - Applies the actual patch

6.6.2.  Sequence Diagram

      ┌────────────┐  ┌─────────┐  ┌─────────┐  ┌─────┐  ┌─────────────┐
      │Supervisor  │  │Planner  │  │Patcher  │  │User │  │IDP          │
      └─────┬──────┘  └────┬────┘  └────┬────┘  └──┬──┘  └──────┬──────┘
            │              │             │          │            │
            │1. Request    │             │          │            │
            │   token      │             │          │            │
            │──────────────┼─────────────┼──────────┼───────────>│
            │   (step_1,   │             │          │            │
            │    chain=[]) │             │          │            │
            │              │             │          │            │
            │2. Token      │             │          │            │
            │<─────────────┼─────────────┼──────────┼────────────│
            │              │             │          │            │
            │3. Delegate   │             │          │            │
            │   to Planner │             │          │            │
            │─────────────>│             │          │            │
            │              │             │          │            │
            │              │4. Request   │          │            │
            │              │   token     │          │            │
            │              │─────────────┼──────────┼───────────>│
            │              │ (step_2,    │          │            │
            │              │  chain=[S]) │          │            │
            │              │             │          │            │
            │              │5. Token     │          │            │
            │              │<────────────┼──────────┼────────────│
            │              │             │          │            │
            │              │6. Delegate  │          │            │
            │              │   to Patcher│          │            │
            │              │────────────>│          │            │
            │              │             │          │            │



Goswami                    Expires 4 July 2026                 [Page 50]

Internet-Draft            Agentic JWT Protocol             December 2025


            │              │             │7. Request│            │
            │              │             │   token  │            │
            │              │             │──────────┼───────────>│
            │              │             │(step_4,  │            │
            │              │             │chain=[S,P])           │
            │              │             │          │            │
            │              │             │          │8. Approval │
            │              │             │          │   required │
            │              │             │          │<───────────│
            │              │             │          │            │
            │              │             │          │9. Approve  │
            │              │             │          │───────────>│
            │              │             │          │            │
            │              │             │10. Token │            │
            │              │             │<─────────┼────────────│
            │              │             │          │            │
            │              │             │11. Execute            │
            │              │             │<─────────             │
            │              │             │                       │

   Legend: S = Supervisor, P = Planner

6.6.3.  Delegation Steps

   1.   *Supervisor Token Request:* Supervisor agent requests token for
        step_1 with empty delegation chain.

          {
            "agent_id": "supervisor-agent",
            "workflow_step": "step_1_analyze_manifest",
            "delegation_context": {
              "chain": [],
              "completed_steps": []
            }
          }

   2.   *Supervisor Executes Step 1:* Supervisor analyzes the manifest
        and determines patching is needed.

   3.   *Delegation to Planner:* Supervisor delegates to Planner agent,
        passing delegation context.

   4.   *Planner Token Request:* Planner requests token for step_2,
        including Supervisor in chain.







Goswami                    Expires 4 July 2026                 [Page 51]

Internet-Draft            Agentic JWT Protocol             December 2025


          {
            "agent_id": "patch-planner",
            "workflow_step": "step_2_create_patch_plan",
            "delegation_context": {
              "chain": ["supervisor-agent"],
              "completed_steps": ["step_1_analyze_manifest"]
            }
          }

   5.   *Planner Executes Step 2:* Planner creates patch strategy and
        identifies target packages.

   6.   *Delegation to Patcher:* Planner delegates to Patcher agent,
        passing updated delegation context.

   7.   *Patcher Token Request:* Patcher requests token for step_4,
        including full delegation chain.

          {
            "agent_id": "vulnerability-patcher-v1",
            "workflow_step": "step_4_apply_patch",
            "delegation_context": {
              "chain": ["supervisor-agent", "patch-planner"],
              "completed_steps": [
                "step_1_analyze_manifest",
                "step_2_create_patch_plan",
                "step_3_approval_gate"
              ]
            }
          }

   8.   *Approval Check:* IDP detects step_4 requires approval (step_3
        is approval gate).  Step_3 must be in completed_steps or request
        is rejected.

   9.   *User Approval:* User has already approved at step_3 approval
        gate.

   10.  *Token Issuance:* IDP issues token to Patcher with:

        *  delegation_chain: SHA-256("supervisor-agent|patch-
           planner|vulnerability-patcher-v1")

        *  step_sequence_hash: SHA-256("step_1|step_2|step_3|step_4")

   11.  *Patcher Execution:* Patcher applies the security patch using
        the intent token.




Goswami                    Expires 4 July 2026                 [Page 52]

Internet-Draft            Agentic JWT Protocol             December 2025


6.6.4.  Delegation Validation

   At each delegation step, the IDP validates:

   1.  *Chain Continuity:* Current agent is appended to
       delegation_context.chain, not inserted or replaced.

   2.  *Step Sequence:* completed_steps contains all required
       prerequisite steps.

   3.  *Approval Requirements:* If step requires approval, the most
       recent approval gate must be in completed_steps.

   4.  *Agent Authorization:* Current agent is authorized to execute the
       requested workflow step.

   Resource servers MAY additionally validate:

   *  Delegation depth is within acceptable limits

   *  All agents in delegation chain are registered and not revoked

   *  Delegation chain matches expected workflow pattern

7.  Future Work

   Future versions or extensions of this specification may align with
   the Grant Negotiation and Authorization Protocol (GNAP)
   [I-D.ietf-txauth-gnap], which provides a JSON-based foundation for
   dynamic authorization scenarios.  A GNAP binding for Agentic JWT
   would enable the agent-specific security mechanisms defined in this
   specification to work within the GNAP framework.

   Additional areas for future development include:

   *  Integration with Model Context Protocol (MCP) standard [MCP]

   *  Support for additional hash algorithms beyond SHA-256

   *  Cross-domain agent identity federation

   *  Support for gRPC protocol.  [GRPC]

   *  Support for prorietary protocols used for database connections,
      and asynchrnous messaging.

8.  IANA Considerations




Goswami                    Expires 4 July 2026                 [Page 53]

Internet-Draft            Agentic JWT Protocol             December 2025


8.1.  Overview

   This specification requires IANA to register a new OAuth 2.0
   authorization grant type, JWT claims, OAuth parameters, and error
   codes in the appropriate registries.

8.2.  OAuth Authorization Grant Type Registration

   This section registers the following grant type value in the IANA
   "OAuth URI" registry [IANA.OAuth.URI] established by "An IETF URN
   Sub-Namespace for Auth" [RFC6755]:

   +==============+============================+========+==========+==========+
   |Grant Type    |URN                         |Common  |Change    |Reference |
   |              |                            |Name    |Controller|          |
   +==============+============================+========+==========+==========+
   |agent_checksum|urn:ietf:params:oauth:grant-|Agent   |IETF      |[this     |
   |              |type:agent_checksum         |Checksum|          |document],|
   |              |                            |Grant   |          |Section 4 |
   |              |                            |type for|          |          |
   |              |                            |OAuth   |          |          |
   |              |                            |2.0     |          |          |
   +--------------+----------------------------+--------+----------+----------+

                   Table 1: OAuth Grant Type Registration

8.3.  JWT Claims Registration

   This section registers the following claims in the IANA "JSON Web
   Token Claims" registry [IANA.JWT.Claims] established by [RFC7519]:





















Goswami                    Expires 4 July 2026                 [Page 54]

Internet-Draft            Agentic JWT Protocol             December 2025


   +====================+================+============+===============+
   | Claim Name         | Claim          | Change     | Specification |
   |                    | Description    | Controller | Document      |
   +====================+================+============+===============+
   | workflow_id        | Identifier of  | IETF       | [this         |
   |                    | the workflow   |            | document],    |
   |                    | being executed |            | Section 4.4.2 |
   +--------------------+----------------+------------+---------------+
   | workflow_step      | Identifier of  | IETF       | [this         |
   |                    | the current    |            | document],    |
   |                    | workflow step  |            | Section 4.4.2 |
   +--------------------+----------------+------------+---------------+
   | executed_by        | Agent          | IETF       | [this         |
   |                    | identifier     |            | document],    |
   |                    | executing the  |            | Section 4.4.2 |
   |                    | workflow step  |            |               |
   +--------------------+----------------+------------+---------------+
   | delegation_chain   | SHA-256 hash   | IETF       | [this         |
   |                    | of agent       |            | document],    |
   |                    | delegation     |            | Section 4.4.2 |
   |                    | sequence       |            |               |
   +--------------------+----------------+------------+---------------+
   | step_sequence_hash | SHA-256 hash   | IETF       | [this         |
   |                    | of completed   |            | document],    |
   |                    | workflow steps |            | Section 4.4.2 |
   +--------------------+----------------+------------+---------------+
   | agent_checksum     | SHA-256        | IETF       | [this         |
   |                    | checksum of    |            | document],    |
   |                    | agent          |            | Section 4.4.2 |
   |                    | configuration  |            |               |
   +--------------------+----------------+------------+---------------+
   | registration_id    | Unique agent   | IETF       | [this         |
   |                    | registration   |            | document],    |
   |                    | instance       |            | Section 4.4.2 |
   |                    | identifier     |            |               |
   +--------------------+----------------+------------+---------------+

                    Table 2: JWT Claims Registrations

8.4.  OAuth Parameters Registration

   This section registers the following parameters in the IANA "OAuth
   Parameters" registry [IANA.OAuth.Parameters] established by
   [RFC6749]:







Goswami                    Expires 4 July 2026                 [Page 55]

Internet-Draft            Agentic JWT Protocol             December 2025


   +====================+================+============+===============+
   | Parameter Name     | Parameter      | Change     | Specification |
   |                    | Usage Location | Controller | Document      |
   +====================+================+============+===============+
   | agent_id           | token request  | IETF       | [this         |
   |                    |                |            | document],    |
   |                    |                |            | Section 4.2.1 |
   +--------------------+----------------+------------+---------------+
   | computed_checksum  | token request  | IETF       | [this         |
   |                    |                |            | document],    |
   |                    |                |            | Section 4.2.1 |
   +--------------------+----------------+------------+---------------+
   | workflow_id        | token request  | IETF       | [this         |
   |                    |                |            | document],    |
   |                    |                |            | Section 4.2.1 |
   +--------------------+----------------+------------+---------------+
   | workflow_step      | token request  | IETF       | [this         |
   |                    |                |            | document],    |
   |                    |                |            | Section 4.2.1 |
   +--------------------+----------------+------------+---------------+
   | workflow_enabled   | token request  | IETF       | [this         |
   |                    |                |            | document],    |
   |                    |                |            | Section 4.2.1 |
   +--------------------+----------------+------------+---------------+
   | delegation_context | token request  | IETF       | [this         |
   |                    |                |            | document],    |
   |                    |                |            | Section 4.2.1 |
   +--------------------+----------------+------------+---------------+
   | requested_scopes   | token request  | IETF       | [this         |
   |                    |                |            | document],    |
   |                    |                |            | Section 4.2.1 |
   +--------------------+----------------+------------+---------------+

                 Table 3: OAuth Parameters Registrations

8.5.  OAuth Extensions Error Registration

   This section registers the following error codes in the "OAuth
   Extensions Error Registry" [IANA.Extensions.Error] established by
   [RFC6749]:











Goswami                    Expires 4 July 2026                 [Page 56]

Internet-Draft            Agentic JWT Protocol             December 2025


   +==========================+========+=========+==========+=============+
   |Error Name                |Error   |Related  |Change    |Specification|
   |                          |Usage   |Protocol |Controller|             |
   |                          |Location|Extension|          |             |
   +==========================+========+=========+==========+=============+
   |unknown_agent             |token   |Agent    |IETF      |[this        |
   |                          |error   |Checksum |          |document],   |
   |                          |response|Grant    |          |Section 4.5.3|
   +--------------------------+--------+---------+----------+-------------+
   |agent_checksum_mismatch   |token   |Agent    |IETF      |[this        |
   |                          |error   |Checksum |          |document],   |
   |                          |response|Grant    |          |Section 4.5.4|
   +--------------------------+--------+---------+----------+-------------+
   |workflow_step_unauthorized|token   |Agent    |IETF      |[this        |
   |                          |error   |Checksum |          |document],   |
   |                          |response|Grant    |          |Section 4.5.5|
   +--------------------------+--------+---------+----------+-------------+

                  Table 4: OAuth Error Code Registrations

8.6.  Media Type Registration

   This specification does not define any new media types.  Agent
   identity verification and token issuance use existing media types:

   *  application/json (RFC 7159) - For token requests and responses

   *  application/jwt (RFC 7519) - For intent tokens

8.7.  Registration Summary

   Summary of IANA registrations required by this specification:

   +=================================+=========================+
   | Registry                        | Number of Registrations |
   +=================================+=========================+
   | OAuth URI                       | 1                       |
   +---------------------------------+-------------------------+
   | JSON Web Token Claims           | 7                       |
   +---------------------------------+-------------------------+
   | OAuth Parameters                | 7                       |
   +---------------------------------+-------------------------+
   | OAuth Extensions Error Registry | 3                       |
   +---------------------------------+-------------------------+
   | *TOTAL*                         | *18*                    |
   +---------------------------------+-------------------------+

                 Table 5: IANA Registration Summary



Goswami                    Expires 4 July 2026                 [Page 57]

Internet-Draft            Agentic JWT Protocol             December 2025


9.  Security Considerations

   This section describes Threat Model and Security Considerations
   similar to OAuth 2.0 [RFC6819].

9.1.  Checksum Security

9.1.1.  Checksum Verification Security

   The agent checksum is the primary security mechanism in this grant
   type.  Implementations MUST:

   *  Use constant-time comparison when verifying checksums to prevent
      timing attacks

   *  Log all checksum mismatch events for security monitoring

   *  Consider implementing rate limiting on checksum verification
      failures to prevent brute-force attacks

   *  Reject checksums that don't match the expected format (sha256:<64
      hex chars>)

9.1.2.  Checksum Strength

   SHA-256 provides 256-bit security against collision and preimage
   attacks.  This is sufficient for agent identity purposes given:

   *  Checksums are not used for long-term secrets (only identity
      binding)

   *  Collision resistance prevents two different agents from having
      same checksum

   *  Preimage resistance prevents deriving agent config from checksum

   Future versions of this specification MAY support alternative hash
   algorithms (e.g., SHA-3) through algorithm prefix versioning.

9.1.3.  Registration Security

   Agent registration endpoints MUST be protected with authentication
   and authorization to prevent:

   *  Unauthorized agents registering under legitimate agent_ids

   *  Denial of service through excessive registrations




Goswami                    Expires 4 July 2026                 [Page 58]

Internet-Draft            Agentic JWT Protocol             December 2025


   *  Checksum enumeration attacks

   The reference implementation requires admin-level OAuth tokens with
   "register:intent" scope for registration endpoints.

9.1.4.  Registry Storage Security

   The agent registry contains sensitive identity information and MUST
   be protected:

   *  Store checksums with access controls (only IDP can read)

   *  Encrypt registry data at rest

   *  Log all registry access for audit trails

   *  Implement rate limiting on registry queries

   *  Regularly backup registry with integrity verification

9.2.  Token Security

9.2.1.  Token Lifetime

   Intent tokens SHOULD have short lifetimes (5-10 minutes) because:

   *  They represent user intent for a specific workflow step

   *  Workflow state may change rapidly in multi-agent systems

   *  Short lifetime limits the window for token theft/replay

   The reference implementation uses 5 minutes (300 seconds).  But this
   value should be fully configurable.

9.2.2.  Proof-of-Possession

   The cnf (confirmation) claim with JWK binding provides proof-of-
   possession, preventing token theft.  Resource servers SHOULD:

   *  Verify that API requests include proof of possession of the
      private key corresponding to the JWK in the cnf claim

   *  Reject tokens presented without valid proof-of-possession

   *  Use mechanisms like DPoP [I-D.ietf-oauth-dpop] for proof-of-
      possession validation




Goswami                    Expires 4 July 2026                 [Page 59]

Internet-Draft            Agentic JWT Protocol             December 2025


9.3.  Workflow Security

   Authorization servers MUST implement access controls on workflow
   definition endpoints.  Only authenticated administrators with
   appropriate privileges SHOULD be able to create or modify workflow
   definitions.

   Implementations SHOULD validate workflow definitions for security
   properties such as: (1) no cycles in agent transitions, (2)
   appropriate scope restrictions at each step, (3) required approval
   gates for high-privilege operations.

9.3.1.  Workflow Validation

   Workflow step validation is critical for preventing privilege
   escalation.  But is applicable only if enabled.  Authorization
   servers MUST:

   *  Enforce prerequisite step completion before issuing tokens

   *  Verify approval gates have been passed for steps requiring
      approval

   *  Validate that the delegation_chain is consistent with the workflow
      definition

   *  Prevent agents from skipping required steps

9.3.2.  Delegation Chain Integrity

   The delegation_chain hash provides integrity over the agent
   delegation path.  However, implementations SHOULD additionally:

   *  Maintain a server-side record of delegation chains

   *  Validate that each delegation was authorized

   *  Limit delegation depth to prevent infinite delegation chains

   *  Revoke all tokens in a delegation chain if a parent agent is
      compromised

9.4.  Implementation Considerations








Goswami                    Expires 4 July 2026                 [Page 60]

Internet-Draft            Agentic JWT Protocol             December 2025


9.4.1.  Cryptographic Requirements

   Implementations MUST use cryptographically secure hash functions for
   agent checksum computation.  SHA-256 or stronger algorithms are
   REQUIRED.  Weaker algorithms such as MD5 or SHA-1 MUST NOT be used.

   For proof-of-possession key binding, implementations MUST support
   EdDSA with Ed25519 curves [ED25519] or ECDSA with P-256 curves.  RSA
   keys with minimum 2048-bit length MAY be supported for backward
   compatibility.

   Intent hash computation MUST use SHA-256 or stronger.  The hash MUST
   be computed over the canonical JSON representation of the intent
   token to ensure consistent results across implementations.

9.4.2.  Privacy Considerations

   Authorization servers and resource servers MUST implement appropriate
   data retention and deletion policies to minimize privacy risks.

   Token logging and audit trails SHOULD exclude sensitive user data
   when possible.  If user data must be logged, implementations SHOULD
   use tokenization or anonymization techniques to protect privacy.

   Cross-border data transfers of tokens containing personal information
   MUST comply with applicable data protection regulations such as GDPR,
   CCPA, and similar frameworks.

9.4.3.  Denial of Service Considerations

   The additional cryptographic operations required by this protocol
   (checksum computation, signature verification, hash computation)
   introduce potential denial of service attack vectors.
   Implementations SHOULD implement rate limiting on token endpoints.

   Authorization servers SHOULD monitor for patterns indicating DoS
   attacks, such as: (1) excessive token requests from single clients,
   (2) repeated failed checksum validations, (3) malformed token
   requests designed to trigger expensive validation operations.

   Resource servers MAY implement caching of validation results (with
   appropriate cache invalidation) to reduce computational overhead for
   repeated token validations.








Goswami                    Expires 4 July 2026                 [Page 61]

Internet-Draft            Agentic JWT Protocol             December 2025


9.5.  Threat Analysis

   The following 12 distinct security threats across six STRIDE
   categories [SHOSTACK] enumerated with their categorization and
   mitigation status in Table 6, have been used to demonstrate the need
   for this Agentic JWT protocol.













































Goswami                    Expires 4 July 2026                 [Page 62]

Internet-Draft            Agentic JWT Protocol             December 2025


   +=====+=====================+=============+============+============+
   | ID  | Threat Name         | STRIDE      | OWASP      | Mitigation |
   +=====+=====================+=============+============+============+
   | T1  | Agent Identity      | Spoofing    | A01:2021   | A1, A2     |
   |     | Spoofing            |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T2  | Token Replay        | Spoofing    | A02:2021   | A6         |
   |     | Attacks             |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T3  | Shim Library        | Spoofing    | A08:2021   | A1, A2     |
   |     | Impersonation       |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T4  | Runtime Code        | Tampering   | A03:2021   | A1, A12    |
   |     | Modification        |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T5  | Prompt Injection    | Tampering   | LLM01:2025 | A12        |
   |     | Attacks             |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T6  | Workflow            | Tampering   | A04:2021   | A8, A11    |
   |     | Definition          |             |            |            |
   |     | Tampering           |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T7  | Cross-Agent         | Priv.       | A01:2021   | A3, A7, A8 |
   |     | Privilege           | Elev.       |            |            |
   |     | Escalation          |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T8  | Workflow Step       | Priv.       | A01:2021   | A8, A10    |
   |     | Bypass              | Elev.       |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T9  | Scope Inflation     | Priv.       | LLM06:2025 | A7, A8     |
   |     |                     | Elev.       |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T10 | Intent Origin       | Repudiation | A09:2021   | A9, A10    |
   |     | Forgery             |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T11 | Delegation Chain    | Repudiation | A02:2021   | A6, A9     |
   |     | Manipulation        |             |            |            |
   +-----+---------------------+-------------+------------+------------+
   | T12 | Agent               | Info.       | A01:2021   | A1, A2     |
   |     | Configuration       | Disc.       |            |            |
   |     | Exposure            |             |            |            |
   +-----+---------------------+-------------+------------+------------+

             Table 6: Threat Enumeration and Mitigation Status

   OWASP categories referenced [OWASP-TOP10-2021] A01:2021 (Broken
   Access Control), A02:2021 (Cryptographic Failures), A03:2021
   (Injection), A04:2021 (Insecure Design), A08:2021 (Software and Data



Goswami                    Expires 4 July 2026                 [Page 63]

Internet-Draft            Agentic JWT Protocol             December 2025


   Integrity Failures), A09:2021 (Security Logging and Monitoring
   Failures), LLM01:2025 (Prompt Injection) [OWASP-LLM01], LLM06:2025
   (Excessive Agency) [OWASP-LLM06].

   Mitigation anchors (detailed in Table 8): A1 (Agent Checksum
   Verification), A2 (Shim Library Integrity), A3 (Scope Binding), A6
   (PoP Key Binding), A7 (Delegation Context), A8 (Workflow State
   Tracking), A9 (Intent Hash Binding), A10 (Step Authorization), A11
   (IDP Access Control), A12 (Input Validation).

9.6.  Threat Descriptions and Attack Vectors

   This section provides detailed descriptions of each identified
   threat, including attack vectors and real-world precedents.  Table 7
   presents this information in tabular form.

   +=====+=====================================+======================+
   | ID  | Description                         | Attack Vector        |
   +=====+=====================================+======================+
   | T1  | A malicious agent impersonates a    | Attacker gains       |
   |     | legitimate agent by replicating its | access to agent      |
   |     | identifier, source code structure,  | source code (e.g.,   |
   |     | prompts, and tool configurations to | through repository   |
   |     | create a malicious agent with       | compromise) and      |
   |     | identical checksum signatures.      | creates a malicious  |
   |     | [OWASP-LLM07]                       | agent with identical |
   |     |                                     | checksum signatures. |
   +-----+-------------------------------------+----------------------+
   | T2  | Intercepted intent tokens are       | Network interception |
   |     | replayed by unauthorized agents to  | or memory dumps      |
   |     | gain access to protected resources. | expose valid intent  |
   |     |                                     | tokens that are      |
   |     |                                     | replayed before      |
   |     |                                     | expiration.          |
   +-----+-------------------------------------+----------------------+
   | T3  | Malicious replacement of legitimate | Supply chain         |
   |     | shim library with compromised       | compromise or local  |
   |     | version that bypasses security      | privilege escalation |
   |     | controls.                           | to replace shim      |
   |     |                                     | library files.       |
   +-----+-------------------------------------+----------------------+
   | T4  | Agent prompts, tools, or            | Memory injection,    |
   |     | configurations are modified at      | debugger attachment, |
   |     | runtime after successful checksum   | or reflection-based  |
   |     | registration.                       | modification of      |
   |     |                                     | agent properties.    |
   +-----+-------------------------------------+----------------------+
   | T5  | Malicious inputs cause LLM agents   | Crafted user inputs  |



Goswami                    Expires 4 July 2026                 [Page 64]

Internet-Draft            Agentic JWT Protocol             December 2025


   |     | to generate unintended instructions | or external data     |
   |     | that bypass security policies.      | sources containing   |
   |     | [OWASP-LLM01],                      | prompt injection     |
   |     | [PEREZ-PROMPT-INJECTION].           | payloads that        |
   |     |                                     | manipulate agent     |
   |     |                                     | reasoning.           |
   +-----+-------------------------------------+----------------------+
   | T6  | Unauthorized modification of        | Compromised          |
   |     | workflow definitions in the         | administrative       |
   |     | authorization server to permit      | credentials or       |
   |     | unauthorized agent transitions.     | authorization server |
   |     |                                     | vulnerabilities      |
   |     |                                     | allowing workflow    |
   |     |                                     | redefinition.        |
   +-----+-------------------------------------+----------------------+
   | T7  | Lower-privilege agent manipulates   | Agent A with read-   |
   |     | higher-privilege agent to perform   | only permissions     |
   |     | unauthorized operations beyond the  | crafts requests that |
   |     | original user intent.               | cause Agent B to     |
   |     |                                     | execute destructive  |
   |     |                                     | operations.          |
   +-----+-------------------------------------+----------------------+
   | T8  | Agents skip required approval steps | Direct API calls     |
   |     | or execute workflow steps out of    | bypassing workflow   |
   |     | sequence to gain unauthorized       | engine or            |
   |     | access.                             | manipulation of      |
   |     |                                     | workflow state       |
   |     |                                     | tracking.            |
   +-----+-------------------------------------+----------------------+
   | T9  | Agents request or utilize broader   | Token minting        |
   |     | scopes than originally intended for | requests with        |
   |     | the specific workflow step.         | inflated scopes or   |
   |     | [OWASP-LLM06]                       | misuse of broad      |
   |     |                                     | scopes for           |
   |     |                                     | unintended           |
   |     |                                     | operations.          |
   +-----+-------------------------------------+----------------------+
   | T10 | Unable to cryptographically prove   | Lack of              |
   |     | which user intent led to specific   | cryptographic        |
   |     | agent actions, enabling plausible   | binding between user |
   |     | deniability.                        | intent and           |
   |     |                                     | downstream agent     |
   |     |                                     | actions.             |
   +-----+-------------------------------------+----------------------+
   | T11 | Modification or forgery of          | Manipulation of      |
   |     | delegation chains to hide true      | delegation assertion |
   |     | origin of agent actions.            | claims or replay of  |
   |     |                                     | valid delegation     |



Goswami                    Expires 4 July 2026                 [Page 65]

Internet-Draft            Agentic JWT Protocol             December 2025


   |     |                                     | chains in            |
   |     |                                     | unauthorized         |
   |     |                                     | contexts.            |
   +-----+-------------------------------------+----------------------+
   | T12 | Unauthorized access to agent        | API endpoints        |
   |     | prompts, tools, and configurations  | exposing agent       |
   |     | leading to system knowledge         | metadata or memory   |
   |     | disclosure.                         | dumps revealing      |
   |     |                                     | agent                |
   |     |                                     | configurations.      |
   +-----+-------------------------------------+----------------------+

             Table 7: Threat Descriptions and Attack Vectors

9.7.  Security Anchors and Mitigation Mechanisms

   The Agentic JWT protocol employs twelve security anchors that
   collectively address all identified threats.  Table 8 describes each
   mitigation mechanism and the threats it addresses.
































Goswami                    Expires 4 July 2026                 [Page 66]

Internet-Draft            Agentic JWT Protocol             December 2025


   +========+=======================================+=========+
   | Anchor | Mechanism                             | Threats |
   +========+=======================================+=========+
   | A1     | Agent Checksum Verification: Runtime  | T1, T3, |
   |        | checksum computation and verification | T4, T12 |
   |        | against registered values             |         |
   +--------+---------------------------------------+---------+
   | A2     | Shim Library Integrity: Cryptographic | T1, T3, |
   |        | validation of shim library            | T12     |
   |        | authenticity                          |         |
   +--------+---------------------------------------+---------+
   | A3     | Scope Binding: Cryptographic binding  | T7, T9  |
   |        | of authorized scopes to specific      |         |
   |        | workflow steps                        |         |
   +--------+---------------------------------------+---------+
   | A6     | Proof-of-Possession Key Binding: Per- | T2, T11 |
   |        | agent cryptographic keys bound to     |         |
   |        | tokens                                |         |
   +--------+---------------------------------------+---------+
   | A7     | Delegation Context Validation:        | T7, T9  |
   |        | Verification of delegation chain      |         |
   |        | authenticity                          |         |
   +--------+---------------------------------------+---------+
   | A8     | Workflow State Tracking:              | T6, T7, |
   |        | Authorization server maintains        | T8      |
   |        | workflow execution state              |         |
   +--------+---------------------------------------+---------+
   | A9     | Intent Hash Binding: Cryptographic    | T10,    |
   |        | binding of user intent to token       | T11     |
   |        | lifecycle                             |         |
   +--------+---------------------------------------+---------+
   | A10    | Step Authorization: Per-step          | T8, T10 |
   |        | authorization checks at resource      |         |
   |        | servers                               |         |
   +--------+---------------------------------------+---------+
   | A11    | Authorization Server Access Control:  | T6      |
   |        | Protection of workflow definitions    |         |
   +--------+---------------------------------------+---------+
   | A12    | Input Validation and Sanitization:    | T4, T5  |
   |        | Validation of agent inputs and LLM    |         |
   |        | outputs                               |         |
   +--------+---------------------------------------+---------+

       Table 8: Security Anchors and Mitigation Mechanisms

10.  References

10.1.  Normative References



Goswami                    Expires 4 July 2026                 [Page 67]

Internet-Draft            Agentic JWT Protocol             December 2025


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

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

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

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <https://www.rfc-editor.org/info/rfc6750>.

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

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

   [RFC7516]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May
              2015, <https://www.rfc-editor.org/info/rfc7516>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

   [RFC6755]  Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
              for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
              <https://www.rfc-editor.org/info/rfc6755>.

   [FIPS-180-4]
              National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4, August 2015.

   [RFC7800]  Jones, M., Campbell, J., and J. Bradley, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/info/rfc7800>.




Goswami                    Expires 4 July 2026                 [Page 68]

Internet-Draft            Agentic JWT Protocol             December 2025


10.2.  Informative References

   [RFC6819]  Lodderstedt, T., 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/info/rfc6819>.

   [RFC8693]  Campbell, B., Bradley, J., Sakimura, N., Jones, M., and W.
              Denniss, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/info/rfc8693>.

   [I-D.ietf-oauth-dpop]
              Fett, D., Denniss, W., and M. Ansari, "OAuth 2.0
              Demonstrating Proof-of-Possession at the Application Layer
              (DPoP)", Work in Progress, Internet-Draft, draft-ietf-
              oauth-dpop-06, April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              dpop-06>.

   [I-D.ietf-txauth-gnap]
              Richer, J. and K. Bezemer, "Grant Negotiation and
              Authorization Protocol", Work in Progress, Internet-Draft,
              draft-ietf-txauth-gnap-17, March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-txauth-
              gnap-17>.

   [NIST-SP-800-63]
              National Institute of Standards and Technology, "Digital
              Identity Guidelines", NIST Special Publication 800-63-3,
              DOI 10.6028/NIST.SP.800-63-3, June 2017,
              <https://doi.org/10.6028/NIST.SP.800-63-3>.

   [NIST-SP-800-63C]
              National Institute of Standards and Technology, "Digital
              Identity Guidelines: Federation and Assertions", NIST
              Special Publication 800-63C, DOI 10.6028/NIST.SP.800-63c,
              June 2017, <https://doi.org/10.6028/NIST.SP.800-63c>.

   [NIST-SP-800-207]
              Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
              "Zero Trust Architecture", NIST Special
              Publication 800-207, DOI 10.6028/NIST.SP.800-207,
              September 2020, <https://doi.org/10.6028/NIST.SP.800-207>.







Goswami                    Expires 4 July 2026                 [Page 69]

Internet-Draft            Agentic JWT Protocol             December 2025


   [OWASP-TOP10-2021]
              OWASP Foundation, "OWASP Top 10 - 2021: The Ten Most
              Critical Web Application Security Risks", Version 2021,
              2021.

   [OWASP-LLM01]
              OWASP Foundation, "LLM01:2025 Prompt Injection", OWASP Top
              10 for LLM Applications v1.1, 2025.

   [OWASP-LLM06]
              OWASP Foundation, "LLM06:2025 Excessive Agency", OWASP Top
              10 for LLM Applications v1.1, 2025.

   [OWASP-LLM07]
              OWASP Foundation, "LLM07:2025 System Prompt Leakage",
              OWASP Top 10 for LLM Applications v1.1, 2025.

   [SHOSTACK] Shostack, A., "Threat Modeling: Designing for Security",
              Publisher Wiley, ISBN 978-1118809990, 2014.

   [LANGCHAIN]
              Chase, H., "LangChain: Framework for Developing LLM-
              Powered Applications", 2022.

   [LANGGRAPH]
              LangChain, "LangGraph: Library for Building Stateful
              Multi-Agent Applications", 2024.

   [CREWAI]   CrewAI, "CrewAI: Framework for Orchestrating Role-Playing
              Autonomous AI Agents", 2023.

   [MCP]      Anthropic PBC, "Model Context Protocol (MCP): A Protocol
              for Connecting AI Agents to Data Sources and Tools", 2024.

   [GRPC]     Google, "gRPC: A High-Performance, Open Source Universal
              RPC Framework", 2015.

   [ED25519]  Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B.
              Yang, "High-Speed High-Security Signatures", Cryptology
              ePrint Archive Report 2011/368, 2012.

   [PEREZ-PROMPT-INJECTION]
              Perez, F. and I. Ribeiro, "Ignore Previous Prompt: Attack
              Techniques For Language Models", arXiv arXiv:2211.09527,
              DOI 10.48550/ARXIV.2211.09527, 2022,
              <https://doi.org/10.48550/ARXIV.2211.09527>.





Goswami                    Expires 4 July 2026                 [Page 70]

Internet-Draft            Agentic JWT Protocol             December 2025


   [PATENT-REF]
              Goswami, A., "Cryptographic Agent Authentication and
              Intent Delegation System with Checksum Based Identity
              Verification and Workflow Aware Token Binding", U.S.
              Patent Application 19/315,486, 30 August 2025.  pending

   [PAPER-REF]
              Goswami, A., "Agentic JWT: Securing Autonomous AI Agents
              Through Cryptographic Intent Binding",
              arXiv arXiv:2509.13597, 2025.  To be updated with actual
              arXiv identifier after publication

   [IANA.OAuth.URI]
              IANA, "OAuth URI", <https://www.iana.org/assignments/
              oauth-parameters/oauth-parameters.xhtml#uri>.

   [IANA.OAuth.Parameters]
              IANA, "OAuth Parameters",
              <https://www.iana.org/assignments/oauth-parameters/oauth-
              parameters.xhtml#parameters>.

   [IANA.JWT.Claims]
              IANA, "JSON Web Token Claims",
              <https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.

   [IANA.Extensions.Error]
              IANA, "JSON Web Token Claims",
              <https://www.iana.org/assignments/oauth-parameters/oauth-
              parameters.xhtml#extensions-error>.

Acknowledgements

   This work builds upon the foundational contributions of the OAuth
   working group and the broader internet security community.

Contributors

   Abhishek Goswami
   Email: abhishek@abhishekgoswami.io


Author's Address

   Abhishek Goswami (editor)
   Email: abhishek@abhishekgoswami.io






Goswami                    Expires 4 July 2026                 [Page 71]


