# drafts

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: []
tags: []
fetched_at: 2026-03-07T06:55:05.659038+00:00
source: ietf
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]


name: draft-zhang-aiproto-svcb-mapping-for-agents
rev: 01
title: Service Binding Mapping for Agents
time: 2026-01-05T07:14:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-09T07:14:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659043+00:00
source: ietf
abstract:
  With the continuous introduction of intelligent agent communication
     and interaction protocols, the current DNS cannot adequately meet the
     requirements for agent service resolution.  This document defines a
     new DNS resource record type, AGENT, which is a SVCB-compatible RR
     type, and specifies the mapping specifications.

full_text:
  Network Working Group                                           M. Zhang
  Internet-Draft                                                  Z.W. Yan
  Intended status: Informational                                 K.J. Dong
  Expires: 6 July 2026                                             H.T. Li
                                                                     CNNIC
                                                            2 January 2026


                     Service Binding Mapping for Agents
               draft-zhang-aiproto-svcb-mapping-for-agents-01

  Abstract

     With the continuous introduction of intelligent agent communication
     and interaction protocols, the current DNS cannot adequately meet the
     requirements for agent service resolution.  This document defines a
     new DNS resource record type, AGENT, which is a SVCB-compatible RR
     type, and specifies the mapping specifications.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 6 July 2026.

  Copyright Notice

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











  Zhang, et al.              Expires 6 July 2026                  [Page 1]


  Internet-Draft     Service Binding Mapping for Agents       January 2026


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

  Table of Contents

     1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Basic requirements  . . . . . . . . . . . . . . . . . . . . .   3
     4.  SvcParamKeys defined by SVCB  . . . . . . . . . . . . . . . .   3
       4.1.  "alpn"  . . . . . . . . . . . . . . . . . . . . . . . . .   3
       4.2.  "port"  . . . . . . . . . . . . . . . . . . . . . . . . .   3
       4.3.  "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . .   4
     5.  Definition of the New SvcParamKeys  . . . . . . . . . . . . .   4
       5.1.  "apn" . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       5.2.  "agentpath" . . . . . . . . . . . . . . . . . . . . . . .   4
       5.3.  "descpath"  . . . . . . . . . . . . . . . . . . . . . . .   4
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
       9.2.  Informative References  . . . . . . . . . . . . . . . . .   5
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Requirements notation

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

  2.  Introduction

     Building on the existing DNS, SVCB records provide additional
     convenience for clients to select different services and obtain the
     parameters required for connections.








  Zhang, et al.              Expires 6 July 2026                  [Page 2]


  Internet-Draft     Service Binding Mapping for Agents       January 2026


     With the rapid development of artificial intelligence, various
     communication and interaction protocols related to agents are
     currently being developed.  Agents have put forward new technical
     requirements in terms of session, communication, service invocation,
     and collaboration, and existing DNS cannot adequately meet the needs
     of agent service resolution.

     This document defines a new DNS resource record type, AGENT, which is
     a SVCB-compatible RR type, and specifies the mapping specifications
     required by SVCB.

  3.  Basic requirements

     To provide special handling for agent service use cases, the AGENT RR
     type is defined as a SVCB-compatible RR type, specific to the "agent"
     scheme.

     The presentation format of the record is: Name TTL IN AGENT
     SvcPriority TargetName SvcParams

  4.  SvcParamKeys defined by SVCB

     The SVCB record [RFC9460] defines a set of initial SvcParamKeys,
     which are applicable to the AGENT scheme.

  4.1.  "alpn"

     This key indicates the set of protocols supported by the endpoint.

     When a specific protocol is designated, corresponding configurations
     shall be implemented via other parameters in accordance with the
     usage requirements and specifications of that protocol, so as to
     provide a complete protocol suite supporting it.

     Otherwise, setting only this value without specifying other necessary
     parameters for the protocol shall be considered an error.

  4.2.  "port"

     The "port" SvcParamKey defines the port number to be used for
     connecting to this alternative endpoint.

     If this key is not present, the client shall use the default port
     number of the transport protocol.







  Zhang, et al.              Expires 6 July 2026                  [Page 3]


  Internet-Draft     Service Binding Mapping for Agents       January 2026


  4.3.  "ipv4hint" and "ipv6hint"

     The "ipv4hint" and "ipv6hint" keys convey the IP addresses that the
     client may use to access the agent service.

  5.  Definition of the New SvcParamKeys

     In addition to the aforementioned SvcParamKeys defined by SVCB, this
     document specifies new SvcParamKeys for agent service usage.

  5.1.  "apn"

     The "apn" SvcParamKey is used to indicate the protocol employed for
     agent communication and interaction, where "apn" refers to Agent
     Protocol Negotiation.

     When a specific protocol is designated, other parameters must be
     configured in accordance with the usage requirements and
     specifications of that protocol to provide a complete protocol suite
     supporting it.

     Otherwise, setting only this value without specifying other necessary
     parameters for the protocol shall be considered an error.

     The "apn" key shall be used in conjunction with the "alpn" key.

     Since some agent-related protocols are currently in the stage of
     discussion and revision, the usage and supporting requirements of
     this parameter will be updated accordingly based on the release of
     future protocols.

  5.2.  "agentpath"

     The value of the "agentpath" SvcParamKey is the URI template of the
     agent.

  5.3.  "descpath"

     Agent description information includes attribute details such as
     agent identity, authentication, capabilities, and collaboration
     mechanisms.  Currently, its specific form varies across different
     protocols.

     The "descpath" SvcParamKey is used to identify the access address
     (e.g., the URL) of the agent's detailed information.






  Zhang, et al.              Expires 6 July 2026                  [Page 4]


  Internet-Draft     Service Binding Mapping for Agents       January 2026


  6.  Security Considerations

     The use of DNSSEC is optional for AGENT records.

     The downgrade attacks relevant to the SVCB record are also applicable
     to this document.

  7.  IANA Considerations

     To be determined.

  8.  Acknowledgments

     To be determined.

  9.  References

  9.1.  Normative References

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

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

  9.2.  Informative References

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

  Authors' Addresses

     Man Zhang
     CNNIC
     Email: zmjy_9@163.com


     Zhiwei Yan
     CNNIC
     Email: yan@cnnic.cn






  Zhang, et al.              Expires 6 July 2026                  [Page 5]


  Internet-Draft     Service Binding Mapping for Agents       January 2026


     Kejun Dong
     CNNIC
     Email: dongkejun@cnnic.cn


     Hongtao Li
     CNNIC
     Email: lihongtao@cnnic.cn











































  Zhang, et al.              Expires 6 July 2026                  [Page 6]


name: draft-chen-ai-agent-auth-new-requirements
rev: 00
title: New requirements for Authentication and Authorization in the AI Agents era
time: 2026-01-06T02:22:59Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-10T02:22:59Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659047+00:00
source: ietf
abstract:
  AI Agents are rapidly evolving from academic concepts into the core
     engines driving next-generation applications.  However, their
     autonomy, dynamic nature, and complex delegation relationships pose a
     fundamental challenge to our existing authentication and
     authorization frameworks, which were designed for human users and
     traditional software.  This document dissects the novel
     characteristics of AI Agents and outlines the new requirements for
     authentication and authorization which can manage dynamic behavior
     rather than verifying static identity.

full_text:
  Internet Engineering Task Force                                  M. Chen
  Internet-Draft                                                     L. Su
  Intended status: Standards Track                            China Mobile
  Expires: 10 July 2026                                     6 January 2026


   New requirements for Authentication and Authorization in the AI Agents
                                    era
                draft-chen-ai-agent-auth-new-requirements-00

  Abstract

     AI Agents are rapidly evolving from academic concepts into the core
     engines driving next-generation applications.  However, their
     autonomy, dynamic nature, and complex delegation relationships pose a
     fundamental challenge to our existing authentication and
     authorization frameworks, which were designed for human users and
     traditional software.  This document dissects the novel
     characteristics of AI Agents and outlines the new requirements for
     authentication and authorization which can manage dynamic behavior
     rather than verifying static identity.

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

  Copyright Notice

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

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



  Chen & Su                 Expires 10 July 2026                  [Page 1]


  Internet-Draft  AI Agent Authentication and Authorizatio    January 2026


     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.  New Authentication Requirements:From "Who Are You?" to "Are You
             Still Trustworthy?" . . . . . . . . . . . . . . . . . . .   3
       3.1.  New Requirement 1: Traceable Identity and Provenance  . .   3
       3.2.  New Requirement 2: Continuous Behavioral Attestation  . .   4
       3.3.  New Requirement 3: Ultra-Low-Overhead Identity
             Management  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  New Authorization Requirements: From "What Permissions Do You
             Have?" to "What Are You Allowed to Do, Right Here, Right
             Now?" . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  New Requirement 1: Intent-Driven, Just-in-Time (JIT)
             Permissions . . . . . . . . . . . . . . . . . . . . . . .   4
       4.2.  New Requirement 2: Rich Context and Risk-Awareness  . . .   4
       4.3.  New Requirement 3: Explainable and Auditable
             Authorization . . . . . . . . . . . . . . . . . . . . . .   5
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     Traditional security models are built on a core assumption: the
     behavior of a protected entity, be it a human or a service, is
     relatively predictable.  We authenticate an "identity" and then grant
     it a set of fixed "permissions."  AI Agents shatter this foundation.

     An AI Agent is not a simple instruction executor; it is a goal
     achiever.  We provide it with a high-level objective (e.g., "optimize
     supply chain costs"), and it autonomously deconstructs the task,
     learns from its environment, invokes tools, and may discover
     innovative operational paths we never anticipated.  This shift
     introduces four disruptive characteristics:

     High Autonomy and Emergent Behavior: An Agent's actions are not pre-
     coded but are dynamically generated to achieve a goal.  Static
     permission rules can neither foresee nor cover all its possible
     operations.






  Chen & Su                 Expires 10 July 2026                  [Page 2]


  Internet-Draft  AI Agent Authentication and Authorizatio    January 2026


     Dynamic, Ephemeral, and Replicable Nature: For efficiency, a primary
     Agent may spawn thousands of ephemeral sub-agents in an instant to
     handle parallel tasks.  Their identities are transient, massive in
     scale, and may exist for only milliseconds.

     Complex Delegation and Chains of Responsibility: Agents can form
     deep, networked call chains.  A travel Agent might call a flight
     Agent, which in turn calls a payment Agent.  When an unauthorized
     action occurs, attributing responsibility and tracing the flow of
     permissions becomes incredibly complex.

     Continuous Learning and Adaptation: An Agent's decision-making model
     evolves over time.  This means an Agent's "normal behavior" today may
     differ from yesterday's, making it vulnerable to model drift or
     malicious manipulation that traditional static credentials cannot
     detect.

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

  3.  New Authentication Requirements:From "Who Are You?" to "Are You
      Still Trustworthy?"

     In the face of these characteristics, one-time authentication becomes
     woefully inadequate.  We need a new authentication framework capable
     of continuously assessing an Agent's trustworthiness.

  3.1.  New Requirement 1: Traceable Identity and Provenance

     Authentication protocols must support a new identity format that is
     more than just an ID; it's a cryptographic "provenance record."  This
     certificate must contain:

     Genesis Information: The root user or task that initiated the Agent's
     creation.  Delegation Chain: A cryptographically signed, non-
     forgeable call path that clearly records every delegation from the
     genesis to the current instance.










  Chen & Su                 Expires 10 July 2026                  [Page 3]


  Internet-Draft  AI Agent Authentication and Authorizatio    January 2026


  3.2.  New Requirement 2: Continuous Behavioral Attestation

     Authentication cannot be a single event.  Protocols must support a
     lightweight "behavioral heartbeat" mechanism, allowing an Agent to
     periodically submit a cryptographic digest of its recent actions to a
     monitoring system.  By comparing this digest against an expected
     behavioral baseline, the system can continuously verify that the
     Agent is "acting normally," thus detecting hijacking or unexpected
     drift even if its identity credential remains valid.

  3.3.  New Requirement 3: Ultra-Low-Overhead Identity Management

     To support massive-scale, ephemeral Agents, protocols must enable
     near-zero overhead for identity creation and verification.  Expensive
     public-key operations and complex handshakes should be replaced with
     efficient symmetric-key mechanisms to meet the demands of high-
     frequency creation, destruction, and continuous attestation.

  4.  New Authorization Requirements: From "What Permissions Do You Have?"
      to "What Are You Allowed to Do, Right Here, Right Now?"

     Static, Role-Based Access Control (RBAC) is obsolete in the face of
     autonomous Agents.  Authorization decisions must become dynamic,
     precise, and risk-aware.

  4.1.  New Requirement 1: Intent-Driven, Just-in-Time (JIT) Permissions

     Authorization is no longer about pre-assigning a broad role.
     Instead, it must be about granting the principle of least privilege
     required to complete a specific task, at the moment of execution.
     For example, the system should grant an Agent permission to "execute
     a payment of amount <= $100 for the purpose of booking a flight"
     rather than a generic "payment" permission.  This permission must
     expire immediately upon task completion.

  4.2.  New Requirement 2: Rich Context and Risk-Awareness

     Authorization decisions must be based on a rich set of contextual
     factors, including but not limited to:

     *  The Agent's intent and objective.

     *  A risk assessment of the requested operation.

     *  Whether its current behavioral patterns are normal.

     *  The sensitivity and provenance of the data being accessed.




  Chen & Su                 Expires 10 July 2026                  [Page 4]


  Internet-Draft  AI Agent Authentication and Authorizatio    January 2026


     Protocols must be able to efficiently carry this structured context
     to the policy engine for real-time evaluation.

  4.3.  New Requirement 3: Explainable and Auditable Authorization

     Given the autonomy of Agents, when something goes wrong, we must be
     able to answer, "Why was the system authorized to do that?"
     Therefore, the response from an authorization protocol must be
     explainable.  It should return not just an "Allow" or "Deny" verdict
     but also the rationale behind the decision, such as the policy IDs
     that were matched and a snapshot of the critical context evaluated.
     This is essential for post-mortem audits, accountability, and the
     iterative refinement of security guardrails.

  5.  IANA Considerations

  6.  Security Considerations

  Authors' Addresses

     Meiling Chen
     China Mobile
     BeiJing
     China
     Email: chenmeiling@chinamobile.com


     Li Su
     China Mobile
     BeiJing
     China
     Email: suli@chinamobile.com



















  Chen & Su                 Expires 10 July 2026                  [Page 5]


name: draft-chen-oauth-rar-agent-extensions
rev: 00
title: Policy and Lifecycle Extensions for OAuth Rich Authorization Requests
time: 2026-02-04T02:18:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-08T02:18:23Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659050+00:00
source: ietf
abstract:
  OAuth 2.0 Rich Authorization Requests (RAR), as defined in RFC 9396,
     provides a mechanism for clients to request fine-grained, structured
     authorization details.  However, in emerging ecosystems of
     collaborating AI agents and long-running automated tasks, two
     critical authorization dimensions remain implicit: the required
     security assurance level of the authorization policy and the strict
     binding of authorization lifetime to a task's lifecycle.

     This document extends the "authorization_details" object of RAR by
     introducing two new members: "policy_context" and
     "lifecycle_binding".  The "policy_context" member allows a client to
     explicitly request that the authorization be evaluated and granted
     under a specific policy assurance level, mitigating policy downgrade
     attacks and enhancing user consent.  The "lifecycle_binding" member
     enables the validity of an authorization grant to be tied directly to
     the state of an external entity, such as an automated task, ensuring
     permissions are automatically and immediately revoked upon task
     completion.  These extensions provide a standardized way to achieve
     more secure, transparent, and context-aware authorization in complex,
     automated environments.

full_text:
  oauth                                                            M. Chen
  Internet-Draft                                                     L. Su
  Intended status: Standards Track                            China Mobile
  Expires: 8 August 2026                                   4 February 2026


   Policy and Lifecycle Extensions for OAuth Rich Authorization Requests
                  draft-chen-oauth-rar-agent-extensions-00

  Abstract

     OAuth 2.0 Rich Authorization Requests (RAR), as defined in RFC 9396,
     provides a mechanism for clients to request fine-grained, structured
     authorization details.  However, in emerging ecosystems of
     collaborating AI agents and long-running automated tasks, two
     critical authorization dimensions remain implicit: the required
     security assurance level of the authorization policy and the strict
     binding of authorization lifetime to a task's lifecycle.

     This document extends the "authorization_details" object of RAR by
     introducing two new members: "policy_context" and
     "lifecycle_binding".  The "policy_context" member allows a client to
     explicitly request that the authorization be evaluated and granted
     under a specific policy assurance level, mitigating policy downgrade
     attacks and enhancing user consent.  The "lifecycle_binding" member
     enables the validity of an authorization grant to be tied directly to
     the state of an external entity, such as an automated task, ensuring
     permissions are automatically and immediately revoked upon task
     completion.  These extensions provide a standardized way to achieve
     more secure, transparent, and context-aware authorization in complex,
     automated 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 8 August 2026.



  Chen & Su                 Expires 8 August 2026                 [Page 1]


  Internet-Draft             extensions for RAR              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
       1.1.  The Need for Advanced Authorization in AI Agent
             Ecosystems  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  The "policy_context" Member . . . . . . . . . . . . . . . . .   4
       2.1.  Structure of the "policy_context" Object  . . . . . . . .   4
       2.2.  Pre-defined Policy Context Parameters . . . . . . . . . .   4
         2.2.1.  The "assurance_level" Parameter . . . . . . . . . . .   4
         2.2.2.  The "compliance_frameworks" Parameter . . . . . . . .   4
       2.3.  Authorization Server Processing . . . . . . . . . . . . .   5
       2.4.  Issuance in Access Tokens . . . . . . . . . . . . . . . .   5
     3.  The "lifecycle_binding" Member  . . . . . . . . . . . . . . .   5
       3.1.  Structure of the "lifecycle_binding" Object . . . . . . .   5
       3.2.  Lifecycle Binding Types . . . . . . . . . . . . . . . . .   5
         3.2.1.  The "task_status_webhook" Type  . . . . . . . . . . .   6
       3.3.  Authorization Server Processing . . . . . . . . . . . . .   6
       3.4.  Resource Server Responsibilities  . . . . . . . . . . . .   6
     4.  Example Authorization Request . . . . . . . . . . . . . . . .   6
     5.  Authorization Server Metadata . . . . . . . . . . . . . . . .   7
     6.  Error Response  . . . . . . . . . . . . . . . . . . . . . . .   7
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
       8.1.  OAuth Authorization Server Metadata . . . . . . . . . . .   8
       8.2.  OAuth Extensions Error Registry . . . . . . . . . . . . .   8
     9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
       10.2.  Informative References . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9






  Chen & Su                 Expires 8 August 2026                 [Page 2]


  Internet-Draft             extensions for RAR              February 2026


  1.  Introduction

     OAuth 2.0 Rich Authorization Requests [RFC9396] significantly
     enhances the expressive power of authorization requests beyond simple
     string- based scopes.  This enables clients, such as sophisticated AI
     agents, to articulate their needs with greater precision.

  1.1.  The Need for Advanced Authorization in AI Agent Ecosystems

     Modern distributed systems are increasingly composed of autonomous or
     semi-autonomous AI agents that collaborate to fulfill complex user
     intents.  For example, a user's request to "plan a business trip to
     Paris" might involve a primary "coordinator" agent that delegates
     sub-tasks to specialized agents for flight booking, hotel
     reservation, and expense reporting.

     In such scenarios, traditional authorization models face two major
     challenges:

     *Permission Abuse and Policy Downgrade: An agent might request a
     high-privilege action (e.g., booking a flight) but the authorization
     server (AS) might grant it under a default, low- assurance security
     policy.  A malicious or compromised client could exploit this
     ambiguity to bypass stricter security controls like multi-factor
     authentication or fraud detection that should be associated with
     high-risk operations.  The authorization request lacks a standard
     mechanism for the client to explicitly request and for the user to
     consent to a specific, appropriate level of policy assurance.

     *Excessive Permission Lifetime: An agent is granted permission to
     manage a long-running task (e.g., a data processing job).
     Traditional access tokens rely on a fixed expiration time ("exp"
     claim).  If the task completes or fails prematurely, the token
     remains valid for the remainder of its lifetime, creating a
     significant window of opportunity for misuse if the token is
     compromised.  The principle of least privilege dictates that the
     permission's lifetime should be strictly bound to the task's active
     lifecycle.

     This specification addresses these gaps by extending the RAR
     framework to include explicit policy context and lifecycle binding
     information within the authorization request itself.









  Chen & Su                 Expires 8 August 2026                 [Page 3]


  Internet-Draft             extensions for RAR              February 2026


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

     This document uses the terms "Authorization Server" (AS), "Client",
     "Resource Server" (RS), and "Access Token" as defined in The OAuth
     2.0 Authorization Framework [RFC6749].  The term
     "authorization_details" is used as defined in Rich Authorization
     Requests [RFC9396].

  2.  The "policy_context" Member

     This specification defines a new JSON object member,
     "policy_context", for the "authorization_details" object.  This
     member allows a client to request that the authorization decision be
     subject to a specific set of policy constraints and assurance levels.

  2.1.  Structure of the "policy_context" Object

     The "policy_context" member, if present, MUST be a JSON object.  Its
     members provide context for the policy decision.

     { "assurance_level": "financial_grade_v1", "compliance_frameworks":
     ["pci-dss", "gdpr","iso27001"] }

  2.2.  Pre-defined Policy Context Parameters

  2.2.1.  The "assurance_level" Parameter

     A string that identifies the desired policy assurance level.  This
     identifier MUST be from a list of values pre-defined and published by
     the authorization server.  It serves as the primary input for the AS
     to select the appropriate set of evaluation rules (e.g., requiring
     MFA, performing risk analysis).This identifier MUST be one of the
     values advertised by the Authorization Server in its
     "policy_assurance_levels_supported" metadata entry (see Section 5).

  2.2.2.  The "compliance_frameworks" Parameter

     An optional array of strings identifying specific compliance
     frameworks that the requested operation must adhere to.  These string
     identifiers MUST be values from the "OAuth Policy Compliance
     Frameworks" registry established by this specification (see
     Section 10.3.2).




  Chen & Su                 Expires 8 August 2026                 [Page 4]


  Internet-Draft             extensions for RAR              February 2026


  2.3.  Authorization Server Processing

     When an AS receives an "authorization_details" object containing a
     "policy_context" member, it MUST:

     1.  Validate that the value of "assurance_level" is known and
         supported.

     2.  Use the "policy_context" to select and execute the corresponding
         authorization policies.

     3.  Perform a cross-validation to ensure the requested policy context
         is appropriate for the requested "type" and "actions".  For
         instance, an AS policy may require that a "payment_transaction"
         type MUST request a "financial_grade_v1" or higher assurance
         level.

     4.  Clearly communicate the semantic meaning of the requested
         "policy_context" to the end-user during the consent process.

  2.4.  Issuance in Access Tokens

     If the request is approved, the AS SHOULD include the validated
     "policy_context" object within the "authorization_details" claim of
     the issued JWT access token.  This enables the resource server to
     perform its own local policy enforcement based on this context.

  3.  The "lifecycle_binding" Member

     This specification defines another new JSON object member,
     "lifecycle_binding", for the "authorization_details" object.  This
     member ties the authorization's validity to the lifecycle of an
     external entity.

  3.1.  Structure of the "lifecycle_binding" Object

     The "lifecycle_binding" member, if present, MUST be a JSON object.

     { "type": "task_status_webhook", "task_id": "job-d4a3b2-8c7e-4f5a-
     9b1c-2d3e4f5a6b7c", "termination_states": ["COMPLETED", "FAILED",
     "CANCELLED"] }

  3.2.  Lifecycle Binding Types

     The "type" member indicates the mechanism by which the AS can monitor
     the external entity's state.





  Chen & Su                 Expires 8 August 2026                 [Page 5]


  Internet-Draft             extensions for RAR              February 2026


  3.2.1.  The "task_status_webhook" Type

     Indicates that the external task provider will notify the AS of
     terminal state changes via a pre-configured webhook.  The object MUST
     also contain:

     o "task_id" (string): A unique identifier for the task.  o
     "termination_states" (array of strings): A list of states that, once
     the task enters, will trigger the immediate revocation of the
     associated authorization.

  3.3.  Authorization Server Processing

     When an AS processes a request with a "lifecycle_binding" member, it
     MUST:

     1.  Verify its capability to monitor the specified task.

     2.  Create an internal record linking the "task_id" to the access
         token to be issued (e.g., via its "jti").

     3.  Upon receiving notification that the task has entered a terminal
         state, the AS MUST immediately revoke the associated token and
         propagate this revocation information.

  3.4.  Resource Server Responsibilities

     Resource servers receiving tokens that contain a "lifecycle_binding"
     claim SHOULD NOT rely solely on the "exp" claim for validation.  They
     MUST employ a mechanism to check for real-time revocation, such as
     subscribing to a revocation feed from the AS or using token
     introspection [RFC7662].

  4.  Example Authorization Request

     The following is a non-normative example of an
     "authorization_details" object utilizing both new members for a
     request to execute a sensitive data processing task.

     [ { "type": "patient_data_analysis_job", "actions": ["execute",
     "monitor_progress"], "locations": ["https://api.compute.com/jobs"],
     "policy_context": { "assurance_level": "hipaa_phi_access",
     "compliance_frameworks": ["hipaa", "gdpr"] }, "lifecycle_binding": {
     "type": "task_status_webhook", "task_id": "analysis-job-1138",
     "termination_states": ["COMPLETED", "FAILED_VALIDATION"] } } ]






  Chen & Su                 Expires 8 August 2026                 [Page 6]


  Internet-Draft             extensions for RAR              February 2026


  5.  Authorization Server Metadata

     This specification adds the following parameters to the OAuth
     Authorization Server Metadata [RFC8414].

     policy_assurance_levels_supported: OPTIONAL.  A JSON array of
     objects, where each object represents a supported assurance level.
     Each object has the following members:

     "level" (string): A structured identifier for the assurance level
     (e.g., "nist_ial2").  REQUIRED. "description" (string): A human-
     readable description.  OPTIONAL. "uri" (string): A URI pointing to
     the detailed definition of the level.  OPTIONAL.

     policy_compliance_frameworks_supported: OPTIONAL.  A JSON array of
     strings containing the compliance framework identifiers supported by
     the AS.

  6.  Error Response

     When a request is denied due to a failure in validating the
     "policy_context", the AS returns an error response with the following
     error code:

     Error Code: policy_requirement_not_met Description: The requested
     "policy_context" is not supported or cannot be satisfied.  The AS
     SHOULD include an "error_description" parameter to provide developers
     with more details about the failure.

  7.  Security Considerations

     Preventing Policy Downgrade Attacks: The "policy_context" member
     allows the AS to enforce that high-risk actions are always requested
     with a corresponding high-assurance policy context.  The AS MUST
     reject requests where this mapping is violated, thus preventing a
     client from obtaining a privileged token under weak security
     pretenses.

     Ensuring Timely Revocation: The "lifecycle_binding" member
     significantly reduces the risk window of compromised tokens for long-
     running tasks.  The effectiveness of this mechanism is entirely
     dependent on the reliability of the state notification and revocation
     propagation systems.  Implementations MUST include robust error
     handling and fallbacks.  The token's "exp" claim serves as an
     essential fallback mechanism.






  Chen & Su                 Expires 8 August 2026                 [Page 7]


  Internet-Draft             extensions for RAR              February 2026


     User Consent and Transparency: The structured nature of these new
     members allows the AS to present a far more intelligible and accurate
     consent screen to the user, leading to more meaningful and informed
     authorization decisions.

     Reliability of External State Monitoring: The AS must trust the
     source of the lifecycle events (e.g., the task provider's webhook).
     Mechanisms such as mutual TLS authentication and request signing
     SHOULD be used to secure the communication channel for state updates.

     The "policy_context" and "lifecycle_binding" members may contain
     information about the user's intended actions and associated tasks.
     This information must be handled with care by the AS and RS, subject
     to the system's overall privacy policy.

  8.  IANA Considerations

  8.1.  OAuth Authorization Server Metadata

     This specification requests the registration of the following values
     in the "OAuth Authorization Server Metadata" registry:

     *policy_assurance_levels_supported
     *policy_compliance_frameworks_supported

  8.2.  OAuth Extensions Error Registry

     This specification requests the registration of the following value
     in the "OAuth Extensions Error Registry":

     *Error Code: policy_requirement_not_met

  9.  Acknowledgements

     This document based on RFC9396

  10.  References

  10.1.  Normative References

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

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



  Chen & Su                 Expires 8 August 2026                 [Page 8]


  Internet-Draft             extensions for RAR              February 2026


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

     [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
                Rich Authorization Requests", RFC 9396,
                DOI 10.17487/RFC9396, May 2023,
                <https://www.rfc-editor.org/rfc/rfc9396>.

     [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
                Authorization Server Metadata", RFC 8414,
                DOI 10.17487/RFC8414, June 2018,
                <https://www.rfc-editor.org/rfc/rfc8414>.

  10.2.  Informative References

     [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
                RFC 7662, DOI 10.17487/RFC7662, October 2015,
                <https://www.rfc-editor.org/rfc/rfc7662>.

  Authors' Addresses

     Meiling Chen
     China Mobile
     BeiJing
     China
     Email: chenmeiling@chinamobile.com


     Li Su
     China Mobile
     BeiJing
     China
     Email: suli@chinamobile.com

















  Chen & Su                 Expires 8 August 2026                 [Page 9]


name: draft-han-ai-agent-impact-infra
rev: 00
title: The Impact of AI Agent to Network Infrastructure
time: 2026-01-09T07:09:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T09:04:53Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659054+00:00
source: ietf
abstract:
  This document disucss and analyses the impact of AI Agent on network
     infrastructure aiming to facilitate the discussion and
     standardization about AI Agent communication within IETF.

full_text:
  Network Working Group                                        M. Han, Ed.
  Internet-Draft                                             N. Zhang, Ed.
  Intended status: Informative                              X. Gu, Ed.
  Expires: 8 January 2026                                     China Unicom
                                                               7 July 2025


              The Impact of AI Agent to Network Infrastructure
                     draft-han-ai-agent-impact-infra-00

  Abstract

     This document disucss and analyses the impact of AI Agent on network
     infrastructure aiming to facilitate the discussion and
     standardization about AI Agent communication within IETF.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 8 January 2026.

  Copyright Notice

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

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





  Han, et al.              Expires 8 January 2026                 [Page 1]


  Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Network for Agent Communication . . . . . . . . . . . . . . .   3
       3.1.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . .   3
         3.1.1.  Agent Communication in LAN  . . . . . . . . . . . . .   3
         3.1.2.  Agent Communication across WAN  . . . . . . . . . . .   4
         3.1.3.  Agent Communication in Fields . . . . . . . . . . . .   4
       3.2.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . .   5
         3.2.1.  Agent ID management among heterougenous networks  . .   5
         3.2.2.  Mobility Management (esp. for Non-3GPP networks)  . .   5
         3.2.3.  Pervassive Point-to-Point Secure Channel  . . . . . .   5
       3.3.  Potential new works . . . . . . . . . . . . . . . . . . .   6
         3.3.1.  Pervasive Mobility Managment in fixed networks  . . .   6
         3.3.2.  On-demand Point-to-Point Private Line service . . . .   6
     4.  Agent-based Network O&M . . . . . . . . . . . . . . . . . . .   6
       4.1.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . .   6
         4.1.1.  Autonomic O&M through AI Agent built into Devices . .   6
         4.1.2.  Agent interactions between Devices and Controllers  .   6
       4.2.  Potential new works . . . . . . . . . . . . . . . . . . .   7
         4.2.1.  Extension of Anima Framework & Protocols  . . . . . .   7
         4.2.2.  South-bound Interface Extension for Agentic O&M . . .   7
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     The rapid advancement of AI agents has introduced transformative
     changes across various domains, particularly in network
     infrastructure.  AI agents, the autonomous, intelligent entities
     capable of perception, reasoning, and decision-making, are
     increasingly being deployed in diverse scenarios.  On the one hand,
     the network needs to provide communication support for AI agent
     collaboration, such as industrial, office, smart home and other
     scenarios.  On the other hand, AI agents can be deployed in the
     network to achieve automatic network O&M.

     Traditional network infrastructures were primarily designed for
     human-driven communication (e.g., web browsing, video streaming).
     However, the rise of multi-agent systems, where AI agents collaborate
     or compete in real-time, demands ultra-low-delay communication,
     dynamic resource allocation, and enhanced security protocols.




  Han, et al.              Expires 8 January 2026                 [Page 2]


  Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


     Besides, AI agents are revolutionizing network O&M.  AI agents,
     powered by reinforcement learning and large language models, enable
     autonomous fault detection, predictive maintenance, and intent-driven
     networking.

     This draft explores the impact of AI Agents on network
     infrastructure, with a focus on Network for Agent Communication and
     Agent-based Network O&M.

  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.  Abbreviations and definitions used in this
     document:

  3.  Network for Agent Communication

  3.1.  Scenarios

  3.1.1.  Agent Communication in LAN

     a.  Office networks In the office network scenario, agents rely on a
     stable LAN environment to build an efficient collaboration system.
     Typical office agents, such as personal AI assistant, can
     automatically analyze users' work requirements, such as writing
     emails, organizing reports, and quickly generating drafts.  In the
     situation of team collaboration, multiple agents share data in real-
     time, automatically arrange task priorities, which can reduce manual
     communication costs and significantly improve work efficiency.  There
     is a requirement for office network to provide security guarantees
     for data interaction among agents to prevent the leakage of sensitive
     information.

     b.  Industrial networks In the industrial scenario, the LAN
     establishes a low-delay and highly reliable communication environment
     for agents, enabling efficient interconnection among production
     equipment, logistics robots, and management systems.  For example, in
     the warehousing and logistics process, the agents carried by AGV
     communicate with the central dispatching agent through the network,
     dynamically planning transportation routes based on real-time traffic
     conditions to improve the efficiency of material distribution.







  Han, et al.              Expires 8 January 2026                 [Page 3]


  Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


  3.1.2.  Agent Communication across WAN

     a.  Agents directly access to public networks When agents directly
     access public network, they can achieve efficient coordination over a
     wide range and across regions.  For example, in smart city, traffic
     management agents, environment monitoring agents, and public service
     agents collaborate efficiently through public networks.  However, the
     openness of public networks also brings challenges in data security
     and privacy protection, which require the use of technologies such as
     encryption and authentication to ensure the security of agent
     communication.

     b.  Agents in Campus/DC to communicate across the WAN AI agents
     within different DCs can achieve resource sharing and remote
     collaboration through WAN.  For example, when a data center
     experiences a shortage of computing resources, the resource
     scheduling agent in this DC negotiates with resource scheduling
     agents of other DCs through the WAN to divert some tasks to DCs with
     idle resources.  This requires the WAN to ensure low delay.

  3.1.3.  Agent Communication in Fields

     a.  Interaction through 3GPP radio networks In the office network
     scenario, agents rely on a stable LAN environment to build an
     efficient collaboration system.  Typical office agents, such as
     personal AI assistant, can automatically analyze users' work
     requirements, such as writing emails, organizing reports, and quickly
     generating drafts.  In the situation of team collaboration, multiple
     agents share data in real-time, automatically arrange task
     priorities, which can reduce manual communication costs and
     significantly improve work efficiency.  There is a requirement for
     office network to provide security guarantees for data interaction
     among agents to prevent the leakage of sensitive information.

     b.  Interaction through WiFi In the industrial scenario, the LAN
     establishes a low-delay and highly reliable communication environment
     for agents, enabling efficient interconnection among production
     equipment, logistics robots, and management systems.  For example, in
     the warehousing and logistics process, the agents carried by AGV
     communicate with the central dispatching agent through the network,
     dynamically planning transportation routes based on real-time traffic
     conditions to improve the efficiency of material distribution.

     c.  Interaction through satellite networks In the industrial
     scenario, the LAN establishes a low-delay and highly reliable
     communication environment for agents, enabling efficient
     interconnection among production equipment, logistics robots, and
     management systems.  For example, in the warehousing and logistics



  Han, et al.              Expires 8 January 2026                 [Page 4]


  Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


     process, the agents carried by AGV communicate with the central
     dispatching agent through the network, dynamically planning
     transportation routes based on real-time traffic conditions to
     improve the efficiency of material distribution.

  3.2.  Gap Analysis

  3.2.1.  Agent ID management among heterougenous networks

     Agent ID management in heterogeneous networks refers to the processes
     and systems for uniquely identifying, authenticating, and managing
     agents (software entities, devices, or services) across networks with
     different architectures, protocols, and technologies.  Key challenges
     include interoperability, scalability, security, dynamicity, and
     privacy protection.

  3.2.2.  Mobility Management (esp. for Non-3GPP networks)

     The AI agent era exacerbates existing gaps in mobility management,
     particularly in interoperability, security, and context awareness.
     Addressing these requires,

     AI-native mobility frameworks that prioritize agent intent over
     device-centric logic.  Dynamic, secure abstraction layers for cross-
     protocol interoperability.  Standardized interfaces for agents to
     share mobility intent with networks.  Energy-efficient, role-based
     QoS models tailored to autonomous AI agents.

  3.2.3.  Pervassive Point-to-Point Secure Channel

     Pervasive P2P secure channels in the AI agent era require a paradigm
     shift from device-centric, static security to agent-aware, dynamic,
     and scalable frameworks.  Addressing these requires,

     Developing lightweight, context-aware trust models for ephemeral
     agent interactions.  Implementing distributed key management and low-
     latency protocols for massive agent swarms.  Creating adaptive
     security abstractions that work across heterogeneous networks.
     Integrating privacy-preserving techniques, such as metadata
     obfuscation and fine-grained access control, into core channel
     design.  Establishing AI-specific standards that align security with
     agent roles and autonomy.









  Han, et al.              Expires 8 January 2026                 [Page 5]


  Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


  3.3.  Potential new works

  3.3.1.  Pervasive Mobility Managment in fixed networks

     TBD

  3.3.2.  On-demand Point-to-Point Private Line service

     TBD

  4.  Agent-based Network O&M

  4.1.  Scenarios

  4.1.1.  Autonomic O&M through AI Agent built into Devices

     In traditional congestion control method, there is a lack of cross-
     device historical data sharing and AI model collaboration between
     devices.  It is unable to adaptively optimize based on real-time
     traffic patterns.  When AI agents are introduced into network
     devices, intelligent collaboration can be achieved.  Devices
     synchronize real-time link bandwidth and TOP-N traffic
     characteristics through BGP extension.  The AI agent dynamically
     define congestion thresholds based on traffic data, replacing manual
     threshold configuration.  Upon detecting congestion, devices
     negotiate AI-generated policies (e.g., dynamic adjustment of Multi-
     Exit Discriminator (MED) values) and route traffic precisely to
     lightly loaded links.  Reinforcement learning is applied to
     dynamically optimize policy parameters during this process.

  4.1.2.  Agent interactions between Devices and Controllers

     In the current IPv6 end-to-end traffic monitoring scenario, traffic
     data collection and analysis rely on manual intervention, while the
     large volume of live network traffic data results in high resource
     requirements.  When AI agents are deployed in network controllers and
     devices, intelligent collaboration can be achieved between
     controllers and edge devices.  The controller agent collects and
     monitors IPv6/IP traffic data in real time, and performs preliminary
     analysis including flow pattern recognition and IPv6/IPv4 traffic
     ratio trending.  The device agent collects customer traffic data,
     decomposes traffic distribution characteristics to identify high-
     value business scenarios, and synchronizes these insights to the
     controller agwnt.  The controller agent integrates global traffic
     ingress/egress data to construct regional traffic matrices, obtaining
     analysis results such as traffic distribution and link utilization.





  Han, et al.              Expires 8 January 2026                 [Page 6]


  Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


  4.2.  Potential new works

  4.2.1.  Extension of Anima Framework & Protocols

     Considering the Anima Framework & Protocols [RFC7575] with AI Agent,
     which provides more intelligent operation and management of network
     devices to achieve the Intention-driven network and Auto-driven
     network.

  4.2.2.  South-bound Interface Extension for Agentic O&M

     The relatted agent communication protocols such as MCP, A2A etc.,
     need to be extended to support the collabration between network
     devices and controller.

  5.  Security Considerations

     TBD

  6.  IANA Considerations

     TBD

  7.  References

  7.1.  Normative References

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

  7.2.  Informative References

     [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
                Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
                Networking: Definitions and Design Goals", RFC 7575,
                DOI 10.17487/RFC7575, June 2015,
                <https://www.rfc-editor.org/info/rfc7575>.

  Authors' Addresses






  Han, et al.              Expires 8 January 2026                 [Page 7]


  Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


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


     Naihan Zhang (editor)
     China Unicom
     Beijing
     China
     Email: zhangnh12@chinaunicom.cn


     Xinrui Gu (editor)
     China Unicom
     Beijing
     China
     Email: guxr12@chinaunicom.cn
































  Han, et al.              Expires 8 January 2026                 [Page 8]


name: draft-yu-dmsc-ai-agent-use-cases-in-6g
rev: 01
title: AI Agent Use Cases and Requirements in 6G Network
time: 2026-01-12T03:16:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-16T03:16:03Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659057+00:00
source: ietf
abstract:
  This draft introduces use cases related to AI Agents in 6G networks,
     primarily referencing the technical report of 3GPP SA1 R20 Study on
     6G Use Cases and Service Requirements (TR 22.870).  It also
     elaborates on some of the requirements for introducing AI Agents into
     6G networks from the perspective of operators.

full_text:
  Network Working Group                                              M. Yu
  Internet-Draft                                                   A. Wang
  Intended status: Informational                                     J. Li
  Expires: 16 July 2026                                              Z. Li
                                                             China Telecom
                                                           12 January 2026


             AI Agent Use Cases and Requirements in 6G Network
                 draft-yu-dmsc-ai-agent-use-cases-in-6g-01

  Abstract

     This draft introduces use cases related to AI Agents in 6G networks,
     primarily referencing the technical report of 3GPP SA1 R20 Study on
     6G Use Cases and Service Requirements (TR 22.870).  It also
     elaborates on some of the requirements for introducing AI Agents into
     6G networks from the perspective of operators.

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

  Copyright Notice

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











  Yu, et al.                Expires 16 July 2026                  [Page 1]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Intent-based 6G Services Enabled by Network AI Agents . .   4
       2.2.  Device-Network Collaboration  . . . . . . . . . . . . . .   5
       2.3.  Multiple Devices Collaboration  . . . . . . . . . . . . .   5
       2.4.  Network-Application Collaboration . . . . . . . . . . . .   6
     3.  Potential Requirements for 6G Network . . . . . . . . . . . .   7
       3.1.  The Identity of AI Agents . . . . . . . . . . . . . . . .   7
       3.2.  Efficient Collaboration . . . . . . . . . . . . . . . . .   7
       3.3.  Cross-Domain Collaboration  . . . . . . . . . . . . . . .   7
       3.4.  Registration and Discovery  . . . . . . . . . . . . . . .   8
       3.5.  Service and Data Exposure . . . . . . . . . . . . . . . .   8
       3.6.  Reliability Assurance . . . . . . . . . . . . . . . . . .   8
       3.7.  High-performance Communication  . . . . . . . . . . . . .   8
       3.8.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.9.  Energy Efficiency . . . . . . . . . . . . . . . . . . . .   8
     4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Informative References  . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Currently, with breakthroughs in large language models and multi-
     modal technologies, AI Agent has emerged as a major research focus in
     the industry.  Equipped with capabilities such as intent
     understanding, action planning, decision-making, task execution, and
     self-awareness, AI Agents can integrate environmental perception,
     memory, tool invocation, and multi-agent collaboration to accomplish
     complex tasks.  They have already demonstrated significant value in
     key fields like autonomous driving, intelligent customer service, and
     smart home systems.  In the 6G era, the introduction of AI Agent
     technology will enable operators to fully leverage the potential of
     mobile communication networks, significantly improving network
     operational efficiency and user experience.  As a result, AI Agents
     are expected to become a key research focus in future 6G networks,
     leading to deep integration between 6G and AI Agent technologies.




  Yu, et al.                Expires 16 July 2026                  [Page 2]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


     In the 3GPP R20 standardization research for 6G, AI Agent has been
     one of the most discussed and debated topics, whether in SA1's study
     on 6G scenarios and requirements or SA2's research on network
     architecture.  In the SA1#109 meeting, 19 contributions related to AI
     Agents were submitted, which include 16 new use cases, with 4 use
     cases ultimately agreed.  And a preliminary definition of AI Agent
     from a capability perspective was adopted: "an automated intelligent
     entity capable of e.g interacting with its environment, acquiring
     contextual information, reasoning, self-learning, decision-making,
     executing tasks (autonomously or in collaboration with other Al
     Agents) to achieve a specific goal."  In the SA1#110 meeting, more
     than 30 contributions related to AI Agents were submitted, which
     include 22 new use cases, with 7 ultimately agreed.  In the SA2#172
     meeting, how to achieve deep integration of 6G network with AI
     technology (e.g. AI agent) has been explicitly included in the scope
     of 6G architecture study.

     This draft summarizes and categorizes the AI Agent-related use cases
     in 6G networks, with a brief introduction provided in Section 2.  In
     Section 3, from an operator's perspective, we elaborate on the
     potential requirements for introducing AI Agents into 6G networks,
     which should be considered when designing the agent communication
     related protocol in mobile communication network.  In Section 4, we
     conclude this draft.

  2.  Use Cases

     AI Agents can be deployed at various locations within the 6G system.
     Depending on their deployment positions, AI Agents in 6G can be
     classified into On-device AI Agents, application AI Agents, network
     AI Agents, operation management AI Agents, etc.  For instance, on-
     device AI Agents refer to those implemented on end-user devices,
     while network AI Agents are those embedded within the 6G network.

     This section summarizes and categorizes AI Agent-related use cases in
     6G networks.  Unlike AI Agents in the Internet domain, use cases
     involving AI Agents in mobile communication networks place greater
     emphasis on how network AI Agents can deliver 6G services to users,
     as well as how different AI Agents within the 6G system coordinate
     with each other.











  Yu, et al.                Expires 16 July 2026                  [Page 3]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


  2.1.  Intent-based 6G Services Enabled by Network AI Agents

     By deploying AI Agents within 6G network, the 6G network can provide
     users with intent-based services.  These intelligent services may
     represent combinations of multiple network capabilities, such as
     communication, sensing, AI/ML, computing, data and more.  Users only
     need to express their intent to the 6G network, without requiring
     specialized technical knowledge to decompose the intent into
     technical requirements.  In this context, 3GPP SA1 has formally
     defined network intent as: Expectations including requirements, goals
     and constraints without specifying how to achieve them.

     Use Case A: Network-Wide Intent Fulfilment

     The 6G system interprets high-level service intents and translate
     such intent into concrete actions, including resource selection,
     configuration, and coordination across communication, sensing,
     computing, AI, and data capabilities utilizing network AI Agents.

     Use Case B: Dynamic Service Customization and Optimization

     The 6G network AI Agents dynamically adapt and optimize service
     behavior based on real-time context information, user requirements,
     and operational conditions in order to maintain desired service
     objectives.

                                     +-------------+
                                     | User Intent |
                                     +------+------+
                                            |
                                   +--------v----------+
                                   | Network AI Agents |
                                   +--------+----------+
                                            |
                             +--------------v----------------+
                             |    Service Orchestration &    |
                             |      Resource Optimization    |
                             +-------------------------------+

                          Figure 2.1 Intent-Based Network Control











  Yu, et al.                Expires 16 July 2026                  [Page 4]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


  2.2.  Device-Network Collaboration

     With the rapid advancement of technologies like smart phones and
     lightweight large-scale AI models, capabilities of user devices have
     significantly expanded, enabling autonomous execution of certain AI
     tasks and independent decision-making.  However, due to inherent
     device limitations - including constrained computational resources
     and battery capacity - deploying complex AI agents or performing
     sophisticated AI tasks locally on devices remains challenging.
     Consequently, investigating optimal collaboration mechanisms between
     UE-based AI agents and network-based AI agents to accomplish complex
     tasks represents a critical research direction for 6G networks.

     Use Case A: Enhanced UE Intelligence via Network Support

     The 6G system enables collaboration between on-device AI Agents and
     Network AI Agents such that devices can leverage network-provided
     context, analytics, and capabilities to improve local decision-making
     and task execution.

     Use Case B: Joint Device and Network Coordination Services

     On-device AI Agents and Network AI Agents jointly support
     coordination services in which adaptation decisions are distributed
     across device-side and network-side components.

          +-------------------+                  +-----------------------+
          | On-Device AI      | <--------------> | 6G Network AI Agents  |
          | Agent (UE)        |                  | and Network Support   |
          +-------------------+                  +-----------------------+
                    |                                        |
                    |                                        |
          +---------v---------+                  +-----------v----------+
          | Local Decisions   |                  | Network Capabilities |
          +-------------------+                  +----------------------+

                  Figure 2.2 Device-Network AI Collaboration

  2.3.  Multiple Devices Collaboration

     Under the powerful communication capabilities of 6G network, multiple
     on-device AI Agents can collaborate with each other to accomplish
     complex AI tasks.  These AI Agents may from either the same
     application or different applications.

     Use Case A: Cross-Device Intelligent Coordination





  Yu, et al.                Expires 16 July 2026                  [Page 5]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


     The 6G system securely exchanges information among multiple on-device
     AI Agents to enable coordinated task execution across devices.

     Use Case B: Group AI Agent Collaboration Domains

     The 6G system dynamically establishes the collaboration domains that
     allow authorized AI Agents to participate in group-based task
     execution under defined security and policy constraints.

   +-------------------+    +-------------------+    +-------------------+
   |   On-Device AI    |    |   On-Device AI    |    |   On-Device AI    |
   | Agent (Device 1)  |<-->| Agent (Device 2)  |<-->| Agent (Device N)  |
   +-------------------+    +-------------------+    +-------------------+
               \                    |                     /
                \                   |                    /
          +--------------------------------------------------------+
          | Dynamic Multi-Agent Secured Collaboration(DMSC) Domain |
          +--------------------------------------------------------+

                Figure 2.3 Multiple On-device AI Agents Collaboration

  2.4.  Network-Application Collaboration

     The 6G network AI Agents and application AI Agents can fully
     collaborate to accomplish network tasks.  On one hand, AI agents
     within the 6G network can invoke appropriate application AI Agents
     based on service characteristics.  On the other hand, the network AI
     Agents can share network data and domain expertise with application
     AI Agents, providing crucial data support for application AI Agents.

     Use Case A: Integrated Service Orchestration

     The 6G system enables cooperation between Network AI Agents and
     application-layer AI Agents to support end-to-end service
     orchestration through context sharing and coordinated control
     actions.

     Use Case B: Knowledge-Driven AI Enhancements

     The 6G system provides mechanisms for exposing network-generated
     knowledge, such as sensing data and telemetry, to authorized AI
     Agents in support of advanced reasoning and service optimization.









  Yu, et al.                Expires 16 July 2026                  [Page 6]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


      +---------------------+                +-----------------------+
      |    Application      |                | 6G Network AI Agents  |
      |     AI Agents       |<-------------->|                       |
      +----------+----------+                +----------+------------+
                 |                                      |
     +-----------v---------+                +-----------v------------------+
     | External Services   |                | Network Knowledge            |
     |  and Applications   |                | (Sensing, AI, Computing,etc) |
     +---------------------+                +------------------------------+

            Figure 2.4 Network-Application AI Collaboration

  3.  Potential Requirements for 6G Network

     In this section, we present potential requirements to 6G network that
     may arise from the introduction of AI Agents in 6G mobile
     communication network from an operator's perspective.  Some of these
     potential requirements have already been agreed by 3GPP, while others
     have not yet been adopted by 3GPP.

  3.1.  The Identity of AI Agents

     The 6G network shall support secure authentication, authorization,
     and management mechanisms for AI Agents' digital identities.  These
     AI Agents include on-device AI Agents, 3rd party AI Agents, Network
     AI Agents, etc.  A robust identity management mechanism is the
     prerequisite for interactions between users and AI Agents, as well as
     between different AI Agents.

  3.2.  Efficient Collaboration

     The 6G network shall support efficient collaboration between
     different AI Agents and between AI Agents and the tools.  This
     include: developing agent communication protocols better suited for
     6G network characteristics, supporting multi-modal data (such as
     text, audio, video, etc.) interactions, enabling rapid transmission
     of massive data volumes, etc.

  3.3.  Cross-Domain Collaboration

     Future AI agents will be ubiquitous, forming a device-network-
     industry end-to-end ecosystem. 6G network shall support the cross-
     domain collaboration of AI agents, including the device domain, RAN
     domain, core network domain, operation and management domain,
     application domain, etc.






  Yu, et al.                Expires 16 July 2026                  [Page 7]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


  3.4.  Registration and Discovery

     The 6G network shall support mechanisms for on-device AI Agents, 3rd
     party AI Agent, Network AI Agents and tools to register their
     attributes to 6G network, which enables efficient, cross-platforms
     and cross-domain AI Agents and tools discovery.  This may different
     from the discovery mechanism in existing agent communication related
     protocol (e.g. NRF discovery mechanism).

  3.5.  Service and Data Exposure

     The 6G network shall support secure mechanisms to expose the 6G
     services (e.g. sensing service, computing service, AI/ML service,
     etc.) and network data (e.g. sensing data, positioning data, etc.) to
     3rd party AI Agents.

  3.6.  Reliability Assurance

     The 6G network shall be able to provide mechanisms (e.g. network
     digital twin) to ensure the reliability and the validity of the
     decisions made by the AI Agents.  The decisions made by the AI Agents
     in 6G network may directly change the network status, parameters,
     configurations.  Only decisions that have been verified for
     reliability can be executed to change the network environment.

  3.7.  High-performance Communication

     The 6G network shall enable high-performance communication, which may
     include low latency, high band-width, ultra-high data rate, etc.
     This is crucial for numerous scenarios such as device-network
     collaboration, network-application collaboration.

  3.8.  Security

     The security of AI Agents communication in 6G includes the data
     protection and user consent.  Data privacy means the 6G network shall
     support end-to-end encryption for the interactions between AI Agents
     to ensure robust data protection and privacy security for sensitive
     information.  Besides, 6G network shall be able to provide mechanisms
     to collect the user consent for the local data collection.

  3.9.  Energy Efficiency

     The 6G network shall be able to provide mechanisms to optimize the
     communication between AI Agents (especially for the on-device AI
     Agents) to reduce energy consumption.





  Yu, et al.                Expires 16 July 2026                  [Page 8]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


  4.  Conclusion

     AI Agents are expected to represent a critical innovation vector for
     6G.  This draft explores the transformative potential of AI Agents in
     6G network, outlining key use cases and operational requirements from
     an operator's perspective.  When designing agent communication
     related protocols for 6G network, the aforementioned requirements
     should be thoroughly considered and incorporated into the protocol
     architecture.

  5.  Informative References

     [TR_22.870]
                "3GPP TR 22.870, "Study on 6G Use Cases and Service
                Requirements", 2025.".

  Authors' Addresses

     Menghan Yu
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: yumh1@chinatelecom.cn


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


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


     Zhen Li
     China Telecom
     Beiqijia Town, Changping District



  Yu, et al.                Expires 16 July 2026                  [Page 9]


  Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


     Beijing
     Beijing, 102209
     China
     Email: liz779@chinatelecom.cn















































  Yu, et al.                Expires 16 July 2026                 [Page 10]


name: draft-chang-agent-token-efficient
rev: 02
title: A Token-efficient Data Layer for Agentic Communication
time: 2026-01-12T09:56:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-16T09:56:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659060+00:00
source: ietf
abstract:
  Agentic communication fundamentally differs from traditional machine
     communication in that its outputs are recursively consumed and
     interpreted by Large Language Models (LLMs).  This unique
     characteristic makes efficient use of the model's limited context a
     critical requirement.  However, current agent communication protocols
     - such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) -
     often suffer from token or context bloat, caused by redundant schema
     definitions, verbose message structures, and inefficient capability
     exchanges.  As a result, a substantial number of tokens are
     unnecessarily consumed within the model’s context window.

     To address these issues, this draft defines the Agentic Data
     Optimization Layer (ADOL), a general and foundational data-layer for
     agent communication.  ADOL introduces a set of backward-compatible
     optimizations, including schema deduplication through JSON
     references, adaptive inclusion of optional fields, controllable
     response verbosity, and retrieval-based selection mechanisms.
     Collectively, these mechanisms reduce token consumption, enhance
     context efficiency, and provide a scalable foundation for future
     agent communication frameworks.

full_text:
  Network Working Group                                           Z. Chang
  Internet-Draft                                                     J. Li
  Intended status: Informational                                    Z. Cao
  Expires: 16 July 2026                                             Huawei
                                                           12 January 2026


           A Token-efficient Data Layer for Agentic Communication
                    draft-chang-agent-token-efficient-02

  Abstract

     Agentic communication fundamentally differs from traditional machine
     communication in that its outputs are recursively consumed and
     interpreted by Large Language Models (LLMs).  This unique
     characteristic makes efficient use of the model's limited context a
     critical requirement.  However, current agent communication protocols
     - such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) -
     often suffer from token or context bloat, caused by redundant schema
     definitions, verbose message structures, and inefficient capability
     exchanges.  As a result, a substantial number of tokens are
     unnecessarily consumed within the model’s context window.

     To address these issues, this draft defines the Agentic Data
     Optimization Layer (ADOL), a general and foundational data-layer for
     agent communication.  ADOL introduces a set of backward-compatible
     optimizations, including schema deduplication through JSON
     references, adaptive inclusion of optional fields, controllable
     response verbosity, and retrieval-based selection mechanisms.
     Collectively, these mechanisms reduce token consumption, enhance
     context efficiency, and provide a scalable foundation for future
     agent communication frameworks.

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




  Chang, et al.             Expires 16 July 2026                  [Page 1]


  Internet-Draft              Abbreviated Title               January 2026


     This Internet-Draft will expire on 16 July 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Token Bloat Problem in A2A (Agent-Agent Communication)  .   3
       1.2.  Token Bloat Problem in MCP (Agent-Tool Communication) . .   3
       1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Repetitive Schema Across Tools  . . . . . . . . . . . . .   4
       2.2.  Excessive Optional Content  . . . . . . . . . . . . . . .   5
       2.3.  Overly Long Server Responses  . . . . . . . . . . . . . .   5
       2.4.  Inefficient Tool Selection  . . . . . . . . . . . . . . .   6
     3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Schema Deduplication Using JSON References  . . . . . . .   7
       3.2.  Adaptive Optional Field Inclusion . . . . . . . . . . . .   8
       3.3.  Controllable Response Verbosity . . . . . . . . . . . . .   8
       3.4.  Tool Selection Mechanism  . . . . . . . . . . . . . . . .   9
     4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

  1.  Introduction









  Chang, et al.             Expires 16 July 2026                  [Page 2]


  Internet-Draft              Abbreviated Title               January 2026


  1.1.  Token Bloat Problem in A2A (Agent-Agent Communication)

     The Agent-to-Agent (A2A) protocol defines structured message
     exchanges among multiple AI agents to support coordination,
     collaboration, and task delegation.  It provides a semantic framework
     through which agents can advertise their capabilities, exchange
     intermediate reasoning results, and invoke each other's functions in
     a standardized manner.

     A2A communication typically uses JSON-based message structures to
     ensure interoperability across heterogeneous agents.  However, as the
     number and complexity of agents increase, message size and redundancy
     also grow.  Agents often repeatedly exchange static or overlapping
     information (such as capability descriptions, metadata, or schema
     definitions) across multiple rounds of interaction.  This repetition
     leads to a phenomenon known as token bloat, where verbose or
     redundant message components consume excessive tokens in the LLM's
     context window.

     Token bloat degrades reasoning efficiency, increases latency, and
     elevates operational cost, particularly in large-scale or multi-agent
     deployments.  These challenges highlight the need for a unified and
     optimized data layer that reduces redundancy while preserving
     interoperability and semantic integrity.

  1.2.  Token Bloat Problem in MCP (Agent-Tool Communication)

     The Model Context Protocol (MCP) defines a standardized interface for
     communication between Large Language Models (LLMs) and external tools
     or data sources.  It allows agents to describe, list, and invoke
     tools in a structured and interoperable manner.  MCP follows a
     client-server architecture consisting of a client (which connects to
     the MCP server), a server (which hosts tool definitions and logic),
     and a host (which coordinates the overall interaction).
     Conceptually, MCP consists of two layers:

     1. the data layer, which defines JSON-RPC-based primitives such as
     tools, resources, prompts, and notifications; and

     2. the transport layer, which handles connection establishment,
     message framing, and authorization.










  Chang, et al.             Expires 16 July 2026                  [Page 3]


  Internet-Draft              Abbreviated Title               January 2026


     As the number of MCP servers/tools increases, token bloat problem
     also emerges.  Each tool's detailed schema, including optional fields
     and human-readable descriptions, is transmitted to the model during
     reasoning.  Overlapping schemas, unfiltered tool lists, and verbose
     outputs also contribute to redundant token usage.  Though protocol
     correctness is unaffected, efficiency, latency, and cost are
     negatively impacted.  These limitations motivate the design of a more
     efficient data layer.

  1.3.  Requirements Language

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

  2.  Problem Statement

     Agentic communication introduces unique efficiency challenges because
     all exchanged messages are recursively processed by Large Language
     Models (LLMs).  Every transmitted token consumes part of the model's
     limited context window, making redundancy and verbosity directly
     detrimental to reasoning efficiency and operational cost.

     Across current agent protocols - such as the [MCP] and [A2A] - four
     common inefficiencies are observed in the data-layer design:
     repetitive schemas, excessive optional content, verbose responses,
     and inefficient capability selection.  Together, these issues cause
     token and context bloat, limiting scalability and responsiveness in
     multi-agent systems.

  2.1.  Repetitive Schema Across Tools

     When the LLM requests a list of tools from the server, the server
     returns a list of tools that includes the tool schema for all tools.
     However, tools hosted on the same MCP server often share similar or
     identical schema components, such as parameters or output schemas.
     These recurring elements not only introduce unnecessary repetition
     but also waste tokens when provided to LLM.  We have conducted an
     experiment to analyze the duplicate content in the schemas of 60
     tools within the official GitHub MCP server.  According to our
     results, the repetition rate of some contents within the 60 tool
     schemas, such as







  Chang, et al.             Expires 16 July 2026                  [Page 4]


  Internet-Draft              Abbreviated Title               January 2026


     {
       "repo": {
             "description": "Repository name",
             "type": "string"
           }
     }

                      Figure 1: Repetitive Schema Example

     reached 9.84%, indicating that it is necessary to improve the tool
     schemas to reduce such repetitive fields.

  2.2.  Excessive Optional Content

     The MCP tool schema currently includes a variety of optional fields,
     such as output schemas and metadata.  In many cases, these fields are
     not essential for successful tool invocation.  For instance, the
     output schema is primarily intended to help the LLM interpret and
     structure the server’s response.  However, when the server’s output
     is already concise and semantically clear, the value of providing an
     additional output schema becomes marginal.  From the server’s
     standpoint, these fields are optional; yet, once transmitted, they
     are fully processed and tokenized by the LLM, contributing directly
     to prompt length and token overhead.  At present, the client has no
     mechanism to indicate whether such optional content should be
     included, resulting in unnecessary data exchange and reduced token
     efficiency.

  2.3.  Overly Long Server Responses

     Under the current MCP architecture, the server is responsible for
     generating outputs that conform to its declared output schema.
     However, in many scenarios, this design results in overly verbose
     responses that exceed the LLM’s actual informational needs.  For
     example, when a weather-reporting tool provides detailed structured
     data—including temperature, humidity, wind speed, and visibility—an
     LLM may only require a subset of this information, such as
     temperature and humidity.  Since the server lacks awareness of the
     LLM’s contextual requirements, it always returns the complete output
     defined by the schema.  Consequently, the LLM must parse and tokenize
     all fields, even those irrelevant to the current prompt.  This
     behavior introduces unnecessary token consumption and increases
     computational cost, particularly in use cases where concise responses
     are sufficient.







  Chang, et al.             Expires 16 July 2026                  [Page 5]


  Internet-Draft              Abbreviated Title               January 2026


  2.4.  Inefficient Tool Selection

     In practice, a service provider typically exposes a single MCP server
     that aggregates multiple tools under one endpoint.  These tools may
     span heterogeneous functional domains (e.g., translation, data
     retrieval, summarization), all of which are simultaneously
     discoverable by the MCP client.  While this design simplifies server-
     side deployment and management, it introduces inefficiency on the
     client side.  As the number of available tools grows, agents must
     evaluate and compare an increasingly large set of tool descriptions
     to determine the most relevant one.  This process not only increases
     computational overhead but also leads to selection ambiguity,
     especially when multiple tools exhibit overlapping functionalities or
     verbose metadata.  Empirical observations indicate that excessively
     detailed tool descriptions, while intended to enhance
     interpretability, can paradoxically increase token consumption during
     parsing and prompt formation.  Moreover, the expanded search space
     degrades the accuracy and efficiency of tool selection, particularly
     in real-time or resource-constrained scenarios.

  3.  Solution Overview

         +--------------------------------------------------------+
         |         Agentic Data Optimization Layer (ADOL)         |
         +--------------------------------------------------------+

    +--------+               +---------------+               +-----------+
    |        |               |               |               |           |
    |  LLM   |               |    Client     | B&D.Tool/list |  Server   |
    |        |               |               +-------------->+           |
    |        |               |               | --short --tag |           |
    |        |               |               |               |           |
    |        | Curated List  |               |A.Curated List |           |
    |        <---------------+               <---------------+           |
    |        |               |               |               |           |
    |        |   Tool Call   |               |   Tool Call   |           |
    |        +-------------->+               +-------------->+           |
    |        |C.requireOutput|               |               |           |
    |        |               |               |               |           |
    |        |    Response   |               |    Response   |           |
    |        <---------------+ requireOutput <---------------+           |
    |        |   (Filtered)  |               |               |           |
    +--------+               +---------------+               +-----------+

                      Figure 2: Typical workflow of ADOL






  Chang, et al.             Expires 16 July 2026                  [Page 6]


  Internet-Draft              Abbreviated Title               January 2026


     To systematically address the inefficiencies identified above, this
     draft introduces the Agentic Data Optimization Layer (ADOL) -- a
     unified and backward-compatible enhancement to existing agentic data
     layers.  Rather than focusing on a single protocol, ADOL provides a
     generalized framework that improves the efficiency of data exchange
     across diverse agent communication settings, including both Model
     Context Protocol (MCP) and Agent-to-Agent (A2A) workflows.

     ADOL defines a set of lightweight mechanisms that preserve
     interoperability while significantly reducing redundant token usage
     in LLM-driven interactions.  It optimizes data compactness and
     adaptiveness without altering existing transport or semantic layers.
     As displayed in Figure 2, ADOL enhances the agentic data layer along
     four complementary dimensions:

     A.  Schema Deduplication: eliminate repetitive definitions through
         JSON references;

     B.  Adaptive Optional Inclusion: allow clients to request concise or
         full schemas;

     C.  Controllable Response Verbosity: enable models to specify the
         required output scope;

     D.  Context-Aware Tool Selection: limit tool exposure to those
         relevant to the current task.

     Together, these mechanisms establish a more efficient and extensible
     foundation for agentic communication, reducing token and context
     bloat while maintaining full compatibility with existing agent
     frameworks.

  3.1.  Schema Deduplication Using JSON References

     To eliminate redundant schema definitions, MCP tool schemas may
     enable the JSON `$ref` mechanism, which was not supported in the
     original MCP architecture and thus leads to a significant amount of
     duplicate content.  This JSON `$ref` mechanism supports both internal
     and external references, as can be seen in [JSON].

     {
       "definitions": {
         "user": { "type": "object" }
       },
       "properties": {
         "data": { "$ref": "#/definitions/user" }
       }
     }



  Chang, et al.             Expires 16 July 2026                  [Page 7]


  Internet-Draft              Abbreviated Title               January 2026


                     Figure 3: Example: Internal Reference

     The internal reference case enables schema reuse within the same
     file, which applies to situations where there is multiple duplicate
     content within the same Json schema.

     {
       "$ref": "schema/common/user.json"
     }

                     Figure 4: Example: External Reference

     The external reference allows a tool schema to reference a shared
     template stored either locally or remotely.  The MCP host or client
     may cache these schemas to avoid repeated token consumption.  This
     mechanism is more suitable for situations where there is overlapping
     content among multiple tool schemas.  We have conducted extensive
     experiments where the tool schema in the server are modified by using
     $ref references.  The results show that the LLM can still accurately
     recognize and invoke these tools, introducing no backward
     incompatibility.

  3.2.  Adaptive Optional Field Inclusion

     When responding to `tool/list` requests, servers SHOULD determine
     whether to include optional schema content based on the client
     request.  Specifically, an additional field `optional` is introduced
     in the server's tool configuration file, which contains schema
     content that is not mandatory.  If the client requests a “short” list
     (for example, via `tool/list --short`), the server SHOULD omit
     unnecessary optional contents included in the `optional` field and
     return a concise tool schema.  This conditional inclusion mechanism
     prevents unnecessary token usage.

  3.3.  Controllable Response Verbosity

     Client SHOULD be capable of adjusting response verbosity based on the
     LLM’s request.  To address this, ADOL introduces a new
     `requireOutput` field in the tool schema.












  Chang, et al.             Expires 16 July 2026                  [Page 8]


  Internet-Draft              Abbreviated Title               January 2026


     {
       "requireOutput": {
         "description": "A list of output field names that the LLM expects to be returned from the tool's complete output.",
         "type": "array",
         "items": {
           "type": "string",
           "enum": ["toolOutcome_1", "toolOutcome_2", "toolOutcome_n"]
         },
         "uniqueItems": true
       }
     }

                         Figure 5: RequireOutput Schema

     When invoking a tool, the LLM first retrieves the tool list and
     corresponding schemas through the client.  Each tool schema may
     include a `requireOutput` field, which defines an optional list of
     output fields that can be selectively requested.  This field enables
     the LLM to specify which parts of a tool’s output are relevant to the
     current context.  Based on this field, the LLM infers which elements
     of the tool’s defined enumerated outcome are needed and passes the
     generated `requireOutput` schema to the MCP client.  Upon receiving
     the tool’s execution result, the MCP client filters the output
     according to `requireOutput` and returns the trimmed result to the
     LLM.  For example, in a weather-related tool, the output schema may
     contain multiple fields such as current conditions, temperature,
     humidity, and visibility.  The `requireOutput` allows the client to
     specify which subset of these results should be included (e.g.,
     `"requireOutput": ["temperature", "humidity"]`).  After receiving the
     server’s response, the client extracts and forwards only these fields
     to the LLM, filtering out unnecessary content while preserving
     semantic completeness.  This design ensures that the LLM only
     receives the necessary data for the current context, thereby reducing
     redundant information and minimizing token consumption.

  3.4.  Tool Selection Mechanism

     To alleviate the token overhead caused by large tool lists, an
     retrieval-based mechanism is introduced.  Generally, The MCP client
     may include additional informative field in the `tool/list` request
     to indicate its requirements for tool.  The server then filters and
     returns only the tools that meet the need.  We propose two typical
     implementation approaches:








  Chang, et al.             Expires 16 July 2026                  [Page 9]


  Internet-Draft              Abbreviated Title               January 2026


     1.  Semantic-based retrieval: The client provides a natural language
         description of its requirement.  The server computes an embedding
         for the requirement and compares it with precomputed embeddings
         of all available tools.  Then, the server ranks the tools based
         on similarity and returns either the top-K most relevant tools or
         those whose similarity score exceeds a predefined threshold.

     2.  Tag-based retrieval: The client provides one or more predefined
         tool tags.  Each tool is assigned at least one tag.  The server
         returns the tools whose tags match the ones requested by the
         client.

     These two approaches can accommodate servers with different
     capabilities.  Approach 1 requires a more sophisticated server
     implementation, but it is expected to provide better retrieval
     performance and higher flexibility.  In contrast, Approach 2 is
     simpler to implement, though it introduces some usage limitations.

     By tool selection mechanism, the range of tools selected by the LLM
     is narrowed down, thereby reducing the token overhead of the LLM and
     improving the accuracy of tool selection.

  4.  Specification

     The proposed extensions can be summarized as follows:

       +===================+============================+=============+
       | Mechanism         | Description                | Impact      |
       +===================+============================+=============+
       | JSON $ref support | Deduplicate schema content | Reduce      |
       |                   |                            | token usage |
       +-------------------+----------------------------+-------------+
       | Optional field    | Client-specified schema    | Reduce      |
       | control           | inclusion                  | token usage |
       +-------------------+----------------------------+-------------+
       | Response          | Adaptive detail level in   | Reduce      |
       | Verbosity control | output                     | token usage |
       +-------------------+----------------------------+-------------+
       | Retrieval-based   | Vectorized tool selection  | Improve     |
       | tool selection    |                            | accuracy    |
       +-------------------+----------------------------+-------------+

                          Table 1: Mechanism Summary

     Backward compatibility is maintained, as none of the proposed changes
     modify existing MCP schema semantics.





  Chang, et al.             Expires 16 July 2026                 [Page 10]


  Internet-Draft              Abbreviated Title               January 2026


  5.  IANA Considerations

     This memo includes no request to IANA.

  6.  Security Considerations

     Embedding-based retrieval introduces potential information exposure
     risks if tool embeddings or client embeddings are transmitted in
     plaintext.  Implementations SHOULD ensure encryption and access
     control when exchanging embedding vectors.  Schema caching and
     external references should only reference trusted sources to avoid
     code injection or schema poisoning.

     In addition to this, ADOL does not introduce new security
     vulnerabilities beyond those already present in existing agent
     communication protocols such as MCP or A2A.  However, implementers
     should ensure that any schema references or external resources
     retrieved via $ref are obtained from trusted sources to prevent
     schema injection or data tampering.

  7.  References

  7.1.  Normative References

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

  7.2.  Informative References

     [A2A]      Google, "Agent2Agent(A2A) Protocol", 2025,
                <https://a2a-protocol.org/latest>.

     [MCP]      Anthropic, "Model Context Protocol (MCP)", 2025,
                <https://modelcontextprotocol.io/docs/getting-started/
                intro>.

     [JSON]     Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
                Schema: A Media Type for Describing JSON Documents", 2022.







  Chang, et al.             Expires 16 July 2026                 [Page 11]


  Internet-Draft              Abbreviated Title               January 2026


  Acknowledgements

     The author thanks the MCP and A2A open-source community for the
     ongoing discussion and the SEP authors for foundational design
     insights.  The SEP link we proposed in the official MCP GitHub
     community is:
     https://github.com/modelcontextprotocol/modelcontextprotocol/
     issues/1576.

  Authors' Addresses

     Zeze Chang
     Huawei
     No. 3, Shangdi Information Road, Haidian District
     Beijing
     100085
     China
     Email: changzeze@huawei.com


     Jinyang Li
     Huawei
     No. 3, Shangdi Information Road, Haidian District
     Beijing
     100085
     China
     Email: lijinyang9@huawei.com


     Zhen Cao
     Huawei
     No. 3, Shangdi Information Road, Haidian District
     Beijing
     100085
     China
     Email: zhen.cao@huawei.com















  Chang, et al.             Expires 16 July 2026                 [Page 12]


name: draft-fu-nmop-agent-communication-framework
rev: 00
title: Agent Communication Framework for Network AIOps
time: 2026-01-25T05:44:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-29T05:44:04Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659065+00:00
source: ietf
abstract:
  As the development of large model and agent technology, it is a trend
     for multi-agent collaboration to solve complex problems.  This
     document proposes an Agent Communication Framework, a multi-agent
     communication and collaboration framework that facilitates the
     coordination of heterogeneous multi-agents and supports intelligent
     network operations and maintenance (AIOps).  Its architecture
     includes an AI gateway and an Agent Name Service, along with
     capabilities such as monitoring and tracking, as well as security
     protection.  Agent Communication Framework provides a comprehensive
     solution for multi-agent communication and collaboration, laying the
     foundation for future interactive, scalable, secure, and controllable
     multi-agent network intelligent operations and maintenance.

full_text:
  nmop                                                               Y. Fu
  Internet-Draft                                                    Q. Sun
  Intended status: Standards Track                                 X. Song
  Expires: 29 July 2026                                             C. Xie
                                                             China Telecom
                                                           25 January 2026


              Agent Communication Framework for Network AIOps
               draft-fu-nmop-agent-communication-framework-00

  Abstract

     As the development of large model and agent technology, it is a trend
     for multi-agent collaboration to solve complex problems.  This
     document proposes an Agent Communication Framework, a multi-agent
     communication and collaboration framework that facilitates the
     coordination of heterogeneous multi-agents and supports intelligent
     network operations and maintenance (AIOps).  Its architecture
     includes an AI gateway and an Agent Name Service, along with
     capabilities such as monitoring and tracking, as well as security
     protection.  Agent Communication Framework provides a comprehensive
     solution for multi-agent communication and collaboration, laying the
     foundation for future interactive, scalable, secure, and controllable
     multi-agent network intelligent operations and maintenance.

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

  Copyright Notice

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




  Fu, et al.                Expires 29 July 2026                  [Page 1]


  Internet-Draft        Agent Communication Framework         January 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
       1.2.  Definition and Terminology  . . . . . . . . . . . . . . .   3
     2.  Agent Communication Framework and Components  . . . . . . . .   3
       2.1.  AI Gateway  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.  Agent Name Service  . . . . . . . . . . . . . . . . . . .   7
         2.2.1.  Agent Accessing . . . . . . . . . . . . . . . . . . .   7
         2.2.2.  Agent Addressing  . . . . . . . . . . . . . . . . . .   8
         2.2.3.  Security Protection . . . . . . . . . . . . . . . . .   9
         2.2.4.  Capabilities Monitoring and Management  . . . . . . .   9
         2.2.5.  Cross-domain synchronization  . . . . . . . . . . . .   9
     3.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     6.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     As the rapid development of AI technology, network operations and
     maintenance have evolved from efficiency improvement to automation,
     through the Data-Driven Digital age with the rise of AIOps
     (intelligent network operations and maintenance), now striding
     towards the Agentic AI stage.  In this new phase, the collaborative
     capabilities of intelligent agents will drive operations and
     maintenance toward a higher level of autonomy.  However, current
     multi-agent collaboration still lacks reliable mechanisms for agent
     addressing, communication, and orchestration scheduling.  It
     introduces several requirements as below:

     • Agent registering and discovering：With the rapid developments of
     multi-agent collaborative scenarios, traditional service discovery
     mechanisms face several challenges.  They are unable to adapt to the
     multi-heterogeneous and dynamically changing capability of agents.
     There is a lack of a unified capability of registration and discovery
     framework for the cross-domain and spans different subject agents,



  Fu, et al.                Expires 29 July 2026                  [Page 2]


  Internet-Draft        Agent Communication Framework         January 2026


     result in low efficiency of task-driven precise collaboration.  There
     is an urgent need to build a global agent capability registration
     mechanism, dynamically maintain the real-time capability database of
     agents across the network, and generate optimal matching strategies
     based on task requirements.

     • Cross-domain interconnection: In some task-oriented collaboration
     scenarios, it may encounter interoperability challenges—both within
     intra-domain and inter-domain use cases.  In inter-domain scenario,
     agents belonging to different domains must discover, access, and
     securely interact with one another to enable effective collaboration.

     • Security Operations: To support large-scale deployment of
     intelligent agents, a comprehensive operation-level security
     framework is required that integrates management, access control,
     traceability, and authentication tailored for agent-centric
     environments., with security mechanisms and capabilities such as zero
     trust, communication encryption and decryption, and supervision
     embedded in the protocol.

  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.

  1.2.  Definition and Terminology

     • ACF：Agent Communication Framework

     • ANS：Agent Name Service

     • AI Gateway：AI GW

  2.  Agent Communication Framework and Components

     To address the requirements described above, we propose an Agent
     Communication Framework for intra-domain and inter-domain agent
     communications.  It consists of two components: AI Gateway and Agent
     Name Service (ANS).  It is the “Connection and control Hub” for agent
     communication.  The overview of the agent communication framework is
     shown in Figure 1.







  Fu, et al.                Expires 29 July 2026                  [Page 3]


  Internet-Draft        Agent Communication Framework         January 2026


      +---------------------------+     +----------------------------+
      |                           |     |                            |
      |      Domain1:   ACF       |     |      Domain2:   ACF        |
      |                           |     |                            |
      |                           |     |                            |
      |  +--------------------+   |     |  +---------------------+   |
      |  |                    |   |     |  |                     |   |
      |  | Agent Name Service <---+-----+--> Agent Name Service  |   |
      |  |                    |   |     |  |                     |   |
      |  +---------^----------+   |     |  +--------^------------+   |
      |            |              |     |           |                |
      |            |              |     |           |                |
      |      +-----v-----+--<-----+-----+--->--+----v------+         |
      |      |           |        |     |      |           |         |
      |      |           |        |     |      |           |         |
      |  +---v---+   +---v---+    |     |  +---v---+   +---v-- +     |
      |  |       |   |       |    |     |  |       |   |       |     |
      |  | AI GW |   | AI GW |    |     |  | AI GW |   | AI GW |     |
      |  |       |   |       |    |     |  |       |   |       |     |
      |  +---^---+   +---^---+    |     |  +---^---+   +---^---+     |
      |      |           |        |     |      |           |         |
      |      |           |        |     |      |           |         |
      +------+-----------+--------+     +------+-----------+---------+
             |           |                     |           |
             |           |                     |           |
         +---v---+   +---v---+             +---v---+   +---v---+
         |       |   |       |             |       |   |       |
         | Agent |   | Agent |             | Agent |   | Agent |
         |       |   |       |             |       |   |       |
         +-------+   +-------+             +-------+   +-------+

     As described in Section 1, efficient interconnection among agents
     relies on clear identity information and capability-based discovery.
     Therefore, a unified identity identification and agent information
     management mechanism forms the foundation for the secure agent
     interconnection.  Agent Communication Framework issue unique identity
     IDs for each agent and establish an authentication framework to
     ensure the security of mutual visits.  They are capable of managing
     information for a massive number of agents, able to obtain agent
     information through multiple methods to ensure information
     comprehensiveness.  In Agent Communication Framework, a semantics-
     based dynamic agent addressing scheme is proposed to enhance the
     accuracy and flexibility of agent interconnection and collaboration,
     enabling interoperability across different domains.  In Intra-domain
     scenarios, the agent communication framework enables the discovery
     and management within the domain and presents a unified proxy
     externally.  Independent AI gateways realize the unified access and
     mutual discovery of agents within domains such as edge homes and the



  Fu, et al.                Expires 29 July 2026                  [Page 4]


  Internet-Draft        Agent Communication Framework         January 2026


     Internet of Things.  In inter-domain scenarios, information
     synchronization mechanism needs to be done by designing as an agent
     information repository in Agent Name Service (ANS) between different
     domains, combining with the existing DNS mechanisms for cross-domain
     addressing and discovery of agents.

  2.1.  AI Gateway

     An AI Gateway is a reliable, efficient, and secure interconnection
     hub for agents.  The main functions of AI Gateway include:

     *  Service Proxy: Service Proxy function acts as an intelligent
        network address translation (NAT) layer that seamlessly translates
        between internal and external network addresses, enabling secure
        communication between private services and external clients.  By
        masking the identities and IP addresses of internal agents or
        services, it effectively hides the internal network topology from
        external access, thereby enhancing security, reducing exposure to
        potential threats, and simplifying service exposure management.

     *  Traffic forwarding and optimization: The AI Gateway provides
        intelligent traffic forwarding and optimization capabilities,
        including Quality of Service (QoS) guarantees to prioritize
        critical workloads, dynamic multi-channel selection for optimal
        path routing based on real-time network conditions, and packet
        compression to reduce bandwidth consumption and latency.
        Additionally, it leverages AI-driven analytics to adaptively
        manage traffic flows, ensure reliable delivery, and enhance
        overall network efficiency and user experience.

     *  Security protection: It provides comprehensive security protection
        by implementing end-to-end channel encryption to ensure data
        confidentiality and integrity during transmission, coupled with
        advanced traffic security detection and real-time threat
        mitigation mechanisms—such as anomaly detection, intrusion
        prevention, and malicious payload filtering—to safeguard against
        cyberattacks and unauthorized access.

     *  Monitoring and auditing: It provides comprehensive monitoring and
        auditing capabilities by continuously observing and logging all
        interaction behaviors between agents, including request sources,
        destinations, timestamps, data payloads (where permitted), and
        access patterns.

     In addition to the capabilities described above, the AI Gateway also
     supports the requirements of high concurrency, high reliability, as
     well as scalability.




  Fu, et al.                Expires 29 July 2026                  [Page 5]


  Internet-Draft        Agent Communication Framework         January 2026


     *  The AI Gateway supports persistent, always online sessions for
        heterogeneous agents, enabling seamless dynamic
        participation—where agents can join or leave a session at any time
        without disrupting the workflow.  It ensures session continuity
        through intelligent checkpointing and resumption mechanisms,
        allowing tasks to resume exactly from the point of interruption in
        the event of network disconnections or agent failures, without
        requiring the entire task to be restarted.  This capability
        maintains task integrity, improves resource efficiency, and
        enhances reliability in complex, multi-agent collaborative
        scenarios.

     *  The AI Gateway is designed to deliver highly concurrent, secure,
        and ultra-low-latency asynchronous communication for multi-agent
        systems, supporting scalable workloads with millions of
        simultaneous connections.  It ensures robust security through end-
        to-end encryption and fine-grained access control, while
        optimizing message routing and processing to minimize
        latency—enabling efficient, real-time coordination among large-
        scale heterogeneous agents

     *  The AI Gateway is designed for high scalability, supporting both
        horizontal and vertical expansion to accommodate growing multi-
        agent workloads.  Horizontally, it enables elastic scaling of
        gateways to handle increased traffic and agent density by
        dynamically adding or removing nodes based on demand.  Vertically,
        it implements recursive addressing across hierarchical gateway
        layers, allowing seamless inter-layer communication and efficient
        routing in large-scale, nested, or federated agent architectures.
        Together, these capabilities ensure the system can scale flexibly
        and efficiently—both outward across distributed deployments and
        upward through logical abstraction layers—while maintaining
        performance, consistency, and manageability.

     *  The AI Gateway supports high-reliability requirements for fully
        autonomous, human-intervention-free interactions among agents.  It
        ensures continuously stable and fault-resilient network
        connectivity through redundant pathways, automatic failover
        mechanism—thereby preventing communication disruptions that could
        otherwise trigger cascading failures across the agent ecosystem.
        This reliability is critical to maintaining uninterrupted task
        execution and system-wide stability in mission-critical multi-
        agent environments.








  Fu, et al.                Expires 29 July 2026                  [Page 6]


  Internet-Draft        Agent Communication Framework         January 2026


  2.2.  Agent Name Service

     Agent Name Service provides access and semantic addressing function
     for multi-agents, and combines with the AI Gateway to provide
     security protection and monitoring capabilities.

  2.2.1.  Agent Accessing

     *  Registration: The Agent Name Service (ANS) provides a secure and
        structured access mechanism for intelligent agents through an
        integrated registration and identity management mechanism.  It
        begins with the Registration Module, which receives registration
        requests from agents, validates their legitimacy (e.g., through
        credentials, tokens, or domain policies), and initiates the
        enrollment process.  The Security Module then handles
        cryptographic identity provisioning by accepting the agent’s
        Certificate Signing Request (CSR), verifying its authenticity, and
        issuing a signed certificate to establish trusted identity.
        Finally, the Registry securely stores each agent’s
        metadata—including its unique identifier, certificate,
        capabilities—enabling reliable discovery, authentication, and
        secure communication across the multi-agents.  This end-to-end
        workflow ensures that only authorized agents are admitted into the
        system, with verifiable identities and consistent governance.



























  Fu, et al.                Expires 29 July 2026                  [Page 7]


  Internet-Draft        Agent Communication Framework         January 2026


     *  Update, Renewal and Revocation: The Agent Name Service (ANS)
        supports comprehensive lifecycle management for registered agents
        through secure and auditable update, renewal, and revocation
        operations.  For updates, agents may submit requests to modify
        their metadata—such as capabilities, protocols, or agent Card
        information.  The ANS server performs signature verification to
        authenticate the request and ensures backward compatibility; if
        the changes introduce incompatibilities, the agent must update its
        version number and do re-registration.  Upon successful
        validation, the ANS updates the corresponding versioned record in
        its registry.  For certificate renewal, agents initiate a renewal
        request before their current certificate expires.  The ANS
        validates the agent’s identity via cryptographic signature
        verification.  After confirmation, it issues a new signed
        certificate while updating the associated agent entry—ensuring
        uninterrupted, trusted operation without service disruption.  For
        revocation, agents or administrators can request certificate
        invalidation in cases of key expiration.  After verifying the
        authenticity of the revocation request through signature checks,
        the ANS permanently removes the agent’s certificate and associated
        metadata from the registry, immediately terminating its ability to
        access.  All operations are executed under strict cryptographic
        validation and audit logging, ensuring integrity, traceability,
        and continuous security across the agent lifecycle.

  2.2.2.  Agent Addressing

     The Agent Name Service (ANS) provides a millisecond-level Semantic
     Addressing Query capability that enables agent discovery—allowing
     users or systems to express intent in plain language (e.g., “Poor
     mobile signal and unstable broadband at home”) and automatically
     resolving it to the most relevant agents (e.g., Home Broadband Agent
     and Wireless Network Optimization Agent).  Semantic-based addressing
     and discovery of agents requires the Agent Name Service (ANS) to
     possess comprehensive, detailed descriptive information for all
     agents.  This functionality is implemented through three coordinated
     components:

     • The Resolution Module receives semantic resolution requests from
     agents and leverages RAG techniques to interpret the query and match
     it to appropriate agent. • The Registry then retrieves the
     corresponding agent’s metadata—including its capabilities, protocol
     details, and certificate—based on the resolved semantic intent. •
     Finally, the Security Module cryptographically signs the retrieved
     agent information and certificate using the private key, ensuring
     authenticity and integrity before returning the signed response to
     the requester.




  Fu, et al.                Expires 29 July 2026                  [Page 8]


  Internet-Draft        Agent Communication Framework         January 2026


  2.2.3.  Security Protection

     The Agent Name Service (ANS) incorporates robust security and
     governance mechanisms to ensure safe and controlled agent
     interactions.  It enforces fine-grained permission control at the
     agent level through a structured workflow that includes registration
     requests, administrative approval, and explicit
     authorization—ensuring that only vetted agents gain access to
     specific capabilities or resources.

     To counter adversarial inputs, ANS integrates prompt injection
     prevention by inspecting all incoming instructions or queries for
     malicious patterns, obfuscated commands, or attempts to hijack agent
     behavior, thereby safeguarding the integrity of agent operations.

     Additionally, it implements tiered content security protection to
     prevent sensitive information leakage, applying data classification
     policies, context-aware filtering, and output sanitization based on
     sensitivity levels.

  2.2.4.  Capabilities Monitoring and Management

     The Agent Name Service (ANS) enables real-time monitoring of agent
     reference, dynamically constructs a graph of agent relationships to
     visualize interaction patterns and dependencies across the domain,
     and supports proactive intervention in anomalous or unauthorized
     behaviors.

     The Agent Name Service (ANS) provides intelligent agent capability
     management by systematically evaluating and verifying the functional
     competencies, performance characteristics, and operational boundaries
     of registered agents.  This includes assessing declared capabilities,
     validating actual behavior through runtime evidence or sandboxed
     testing, and maintaining a trusted, up-to-date profile of each
     agent’s verified skills.  By ensuring that advertised capabilities
     accurately reflect real-world functionality, ANS enables reliable
     agent discovery, safe composition, and context-aware orchestration
     within dynamic multi-agent domains.

  2.2.5.  Cross-domain synchronization

     The Agent Name Service (ANS) enables cross-domain collaboration among
     intelligent agents by securely synchronizing agent information.  In
     inter-domain scenarios, information synchronization mechanism needs
     to be done by designing as an agent information repository in ANS
     between different domains, and combining with the existing DNS
     mechanisms for cross-domain addressing and discovery of agents.




  Fu, et al.                Expires 29 July 2026                  [Page 9]


  Internet-Draft        Agent Communication Framework         January 2026


  3.  Use Case

     *  Case 1: Home Broadband Service Installation

     In the scenario of handling home broadband service installation, we
     employ a collaborative system comprising 13 agents, including the
     Intent Recognition Agent, Domain-Specific Configuration Agent, Master
     Control Agent, Service Validation Agent etc.

     Phase 1: Service intent recognition

     Agent Used: Intent Recognition Agent; Master Control Agent of service
     installation

     Action: 1.Identify users' service installation requirements by the
     Intention Recognition Agent.  2.Automatically send the structured
     service intent to the Master Control Agent.

     Phase 2: Service Orchestration and Resource Allocation

     Agent Used: Master Control Agent of service installation; Service
     Orchestration and Resource Allocation Agent

     Action: 1.The Master Control Agent sends the service installation
     request to the Service Orchestration and Resource Allocation Agent,
     completes the planning of the service path and the evaluation and
     allocation of resources.  2.The Service Orchestration and Resource
     Allocation Agent feedback the service path and resource allocation
     plan back to the Master Control Agent.

     Phase 3: Data Preparation and Distribution

     Agent Used: Master Control Agent of service installation; Domain-
     Specific Configuration Agent

     Action: 1.The Service installation Master Control Agent initiates
     data preparation and configuration requests based on the plan.  2.The
     Domain-Specific Configuration Agent generates the systems
     corresponding configuration data and completes the automatic
     configuration of network elements (NEs) / network management systems.
     3.As the completion of the configuration, the results are
     automatically back to the Master Control Agent.

     Phase 4: Service Validation

     Agent Used: Master Control Agent of service installation; Domain-
     Specific Configuration Agent; Service Validation Agent




  Fu, et al.                Expires 29 July 2026                 [Page 10]


  Internet-Draft        Agent Communication Framework         January 2026


     Action: 1.The Master Control Agent triggers the automated service
     validation process.  2.The Service Validation Agent collaborates with
     the Domain-Specific Configuration Agent to query the data of
     configuration and status, and subsequently performs installation
     verification and validation.  3.The validation results are back to
     the Master Control Agent, forming a closed-loop validation cycle.

     Phase 5: Quality monitoring

     Agent Used: Installation and Maintenance Scheduling Agent

     Action: 1.The Installation and Maintenance Scheduling Agent performs
     continuous monitoring of customer services to ensure the quality of
     new installations.

     Phase 6: Customer feedback survey

     Agent Used: Personal Intelligent Assistant Agent

     Action: 1.The Personal Intelligent Assistant Agent schedules the
     installation/maintenance engineers for service follow-up and review.

     *  Case 2: Home Broadband Network Fault Diagnosis

     In the scenario of handling home broadband network fault diagnosis,
     we employ a collaborative system comprising 13 agents, including the
     Intent Recognition Agent, Preprocessing Agent, Single-Domain Root
     Cause Analysis Agent, Knowledge Q&A Agent, Fault Handling Agent etc.

     Phase 1: User Complaint Intent Recognition and Data Sensing

     Agent Used: Intent Recognition Agent; Preprocessing Agent

     Action: 1.Identify the type of user complaint by the Intention
     Recognition Agent.  2.Automatically trigger the data preprocessing
     function of the Preprocessing Agent based on the complaint type to
     collect key information such as user devices, alarms, and networks
     information.  3.Complete unified perception and aggregation of user-
     side data.

     Phase 2: Home Broadband Fault Complaint Handling

     Agent Used: MSingle-Domain Root Cause Analysis Agent; Perception Data
     Collection Agent; Knowledge Q&A Agent; Data Collection Agent

     Action: 1.The Single-Domain Root Cause Analysis Agent performs
     initial root cause analysis based on existing data.
     2.If information is insufficient, it triggers the data recollection



  Fu, et al.                Expires 29 July 2026                 [Page 11]


  Internet-Draft        Agent Communication Framework         January 2026


     mechanism of the Perception Data Collection Agent.  The Knowledge Q&A
     Agent guides the user to supplement key information.  The Data
     Collection Agent complements the missing data.  3. After multiple
     iterations, it outputs a most likely root cause, impact scope, and
     recommendations.

     Phase 3: Trouble Shooting

     Agent Used: Fault Handling Agent; Installation and Maintenance
     Scheduling Agent

     Action: 1.The Fault Handling Agent supports automatic fault recovery.
     2.If automatic repair fails, it triggers the Installation and
     Maintenance Scheduling Agent to generate the optimal dispatch plan
     based on the location and skills of the installation and maintenance
     engineers, as well as the urgency of the fault.

     Phase 4: Service Validation

     Agent Used: End-to-End Testing Agent

     Action: 1.The End-to-End Testing Agent initiates tests to ensure
     service consistency.

     Phase 5: Quality monitoring

     Agent Used: Installation and Maintenance Scheduling Agent

     Action: 1.The Installation and Maintenance Scheduling Agent performs
     continuous monitoring of customer services to to prevent recurring
     faults.

     Phase 6: Customer feedback survey

     Agent Used: Personal Intelligent Assistant Agent

     Action: 1.The Personal Intelligent Assistant Agent schedules the
     installation/maintenance engineers for service follow-up and review.

  4.  Security Considerations

     TBD

  5.  IANA Considerations

     This document has no IANA actions.

  6.  Normative References



  Fu, et al.                Expires 29 July 2026                 [Page 12]


  Internet-Draft        Agent Communication Framework         January 2026


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

  Acknowledgements

     TBD

  Authors' Addresses

     Yu Fu
     China Telecom
     Beijing
     China
     Email: fuy44@chinatelecom.cn


     Qing Sun
     China Telecom
     Beijing
     China
     Email: sunqiong@chinatelecom.cn


     Xin Song
     China Telecom
     Beijing
     China
     Email: songx18@chinatelecom.cn


     Chongfeng Xie
     China Telecom
     Beijing
     China
     Email: xiechf@chinatelecom.cn










  Fu, et al.                Expires 29 July 2026                 [Page 13]


name: draft-pioli-agent-discovery
rev: 01
title: Agent Registration and Discovery Protocol (ARDP)
time: 2026-02-24T08:14:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T08:14:02Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659069+00:00
source: ietf
abstract:
  This document specifies the Agent Registration and Discovery Protocol
     (ARDP), a lightweight protocol for registering, discovering, and
     reaching autonomous software agents in distributed and federated
     environments.  ARDP provides stable agent identities, dynamic
     endpoint resolution, capability advertisement (including protocol
     selection among MCP, A2A, HTTP, and gRPC), minimal presence
     signaling, and a security-first discovery control plane.  ARDP is
     transport-agnostic and complementary to existing agent interaction
     protocols.

full_text:
  Network Working Group                                           R. Pioli
  Internet-Draft                                               Independent
  Intended status: Informational                             February 2026
  Expires: 28 August 2026


              Agent Registration and Discovery Protocol (ARDP)
                       draft-pioli-agent-discovery-01

  Abstract

     This document specifies the Agent Registration and Discovery Protocol
     (ARDP), a lightweight protocol for registering, discovering, and
     reaching autonomous software agents in distributed and federated
     environments.  ARDP provides stable agent identities, dynamic
     endpoint resolution, capability advertisement (including protocol
     selection among MCP, A2A, HTTP, and gRPC), minimal presence
     signaling, and a security-first discovery control plane.  ARDP is
     transport-agnostic and complementary to existing agent interaction
     protocols.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 5 August 2026.

  Copyright Notice

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

     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



  Pioli                    Expires 28 August 2026                 [Page 1]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
     6.  Layering and Composition  . . . . . . . . . . . . . . . . . .   4
     7.  Agent Identity  . . . . . . . . . . . . . . . . . . . . . . .   5
       7.1.  AID Syntax  . . . . . . . . . . . . . . . . . . . . . . .   5
       7.2.  Canonical Form  . . . . . . . . . . . . . . . . . . . . .   5
     8.  Registration Model  . . . . . . . . . . . . . . . . . . . . .   6
       8.1.  REGISTER  . . . . . . . . . . . . . . . . . . . . . . . .   6
       8.2.  DEREGISTER  . . . . . . . . . . . . . . . . . . . . . . .   6
       8.3.  Registration Semantics  . . . . . . . . . . . . . . . . .   6
       8.4.  TTL and Refresh . . . . . . . . . . . . . . . . . . . . .   6
       8.5.  Meta Resource . . . . . . . . . . . . . . . . . . . . . .   6
     9.  Discovery and Resolution  . . . . . . . . . . . . . . . . . .   7
       9.1.  RESOLVE . . . . . . . . . . . . . . . . . . . . . . . . .   7
       9.2.  QUERY . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       9.3.  Privacy Defaults and Redaction  . . . . . . . . . . . . .   7
     10. Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   7
       10.1.  Capability Bindings  . . . . . . . . . . . . . . . . . .   8
     11. Presence and Health . . . . . . . . . . . . . . . . . . . . .   8
     12. Security Considerations . . . . . . . . . . . . . . . . . . .   8
       12.1.  Proof of Control . . . . . . . . . . . . . . . . . . . .   8
         12.1.1.  Signed Payload . . . . . . . . . . . . . . . . . . .   8
         12.1.2.  Deterministic JSON Serialization . . . . . . . . . .   8
         12.1.3.  Nonce Acquisition  . . . . . . . . . . . . . . . . .   9
         12.1.4.  Verification . . . . . . . . . . . . . . . . . . . .   9
         12.1.5.  Algorithm Support  . . . . . . . . . . . . . . . . .   9
       12.2.  Authorization Scopes . . . . . . . . . . . . . . . . . .   9
     13. Federation  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       13.1.  Federation Profile (Minimum) . . . . . . . . . . . . . .  10
     14. Relationship to Existing Protocols  . . . . . . . . . . . . .  10
     15. Wire Format Sketch (Non-Normative)  . . . . . . . . . . . . .  10
       15.1.  Minimal HTTPS Binding  . . . . . . . . . . . . . . . . .  10
       15.2.  Error Model  . . . . . . . . . . . . . . . . . . . . . .  11
     16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
       16.1.  Well-Known URI . . . . . . . . . . . . . . . . . . . . .  11
       16.2.  Agent Identifier Namespace . . . . . . . . . . . . . . .  11
     17. Capability Schema v0  . . . . . . . . . . . . . . . . . . . .  11
     18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . .  12
     19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12



  Pioli                    Expires 28 August 2026                 [Page 2]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

  1.  Introduction

     Autonomous and semi-autonomous software agents introduce challenges
     in discoverability, reachability, and interoperability.  Agents may
     be ephemeral, mobile across execution environments, and implemented
     by heterogeneous vendors.

     ARDP addresses stable addressing of agents whose runtime location
     changes, authorized discovery by identity and declared capabilities,
     capability-driven selection among interaction protocols (e.g., MCP,
     A2A, HTTP, gRPC), and minimal, privacy-aware presence signaling.

  2.  Design Goals

     Stable Identity; Dynamic Reachability; Minimalism (control plane
     only); Security by Default; Federation-Friendly; Extensibility.

  3.  Non-Goals

     ARDP is intentionally narrow in scope.  The following are explicitly
     out of scope for this specification:

     1.  Agent-to-agent interaction, session management, task execution,
         and tool invocation protocols.  These are addressed by
         interaction protocols such as MCP and A2A.

     2.  Identity governance frameworks, IAM policy languages, and
         organizational trust models.  ARDP accepts identity attestations
         as inputs but does not define how they are issued or governed.

     3.  Runtime authorization token formats and enforcement proxies.
         ARDP provides discovery-time authorization scopes; runtime
         enforcement is delegated to interaction layers.

     4.  Post-execution evidence, audit trails, compliance logging
         formats, and non-repudiation mechanisms.

     5.  Billing, accounting, reputation, benchmarking, and other business
         frameworks.

     6.  Naming and bootstrap mechanisms beyond locating an ARDP
         authority.  DNS-based discovery, well-known URIs, or other
         bootstrap mechanisms may be used alongside ARDP.






  Pioli                    Expires 28 August 2026                 [Page 3]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     7.  Centralization requirements.  ARDP supports domain-scoped
         authorities and explicit federation without mandating a single
         global registry.

  4.  Terminology

     The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
     SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be
     interpreted as described in RFC 2119 and RFC 8174.

     *  Agent: Autonomous software entity capable of initiating and
        receiving interactions.

     *  Agent Identifier (AID): Stable, namespaced identifier of the form
        agent:<local-id>@<authority>.

     *  Registrar: Service that accepts agent registrations and maintains
        bindings.

     *  Resolver: Service that resolves an AID to active endpoints.

     *  Endpoint: Network location and protocol tuple through which an
        agent can be reached.

     *  Capability: Declarative description of supported protocols and
        interaction modes.

  5.  Architecture Overview

     ARDP defines a logical control plane composed of registrars and
     resolvers.  Agents register their presence and capabilities with a
     registrar.  Authorized clients query resolvers to obtain endpoint and
     capability information.

  6.  Layering and Composition

     ARDP operates as a control-plane protocol for registration and
     discovery.  It is designed to compose with other layers of the agent
     ecosystem:

     *  Transport Security: ARDP endpoints are typically secured using
        TLS, mTLS, or QUIC.  Transport security is orthogonal to ARDP
        semantics.








  Pioli                    Expires 28 August 2026                 [Page 4]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     *  Identity Governance and Attestation: ARDP uses identity
        attestations as inputs for proof-of-control during registration
        and for authorization decisions.  The issuance, revocation, and
        governance of these attestations are handled by external identity
        frameworks.

     *  Bootstrap Mechanisms: Clients may use DNS-based discovery, well-
        known URIs, or other mechanisms to locate ARDP registrars and
        resolvers.  ARDP does not prescribe a specific bootstrap method.

     *  Interaction Protocols: Once an agent's endpoint and capabilities
        are discovered via ARDP, clients select an appropriate interaction
        protocol (MCP, A2A, HTTP, gRPC) based on the advertised
        capabilities.  ARDP does not define interaction semantics.

     ARDP does not specify runtime enforcement mechanisms, session
     semantics, or evidence/audit systems.  These concerns are delegated
     to the appropriate layers.

  7.  Agent Identity

     Each agent SHALL have a unique AID.  The authority component denotes
     the administrative authority responsible for the identity.

     Agents MUST prove control of an AID during registration using
     cryptographic credentials bound to that identity.

  7.1.  AID Syntax

     An ARDP Agent Identifier (AID) MUST follow this grammar (ABNF per RFC
     5234):

  aid              = "agent:" local-id "@" authority
  local-id         = 1*( ALPHA / DIGIT / "_" / "-" / "." / "/" )
  authority        = dns-name / internal-name / opaque-authority
  dns-name         = 1*( ALPHA / DIGIT / "-" / "." )  ; see IDNA2008 notes
  internal-name    = 1*( ALPHA / DIGIT / "-" / "." )
  opaque-authority = "tenant-" 1*( ALPHA / DIGIT / "-" )

     Note: When internationalized domain names are used, implementers
     should follow the IDNA2008 RFC series.

  7.2.  Canonical Form

     The canonical AID string is:

     1.  The literal prefix agent: in lowercase.




  Pioli                    Expires 28 August 2026                 [Page 5]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     2.  The authority normalized to lowercase (including IDNA2008
         normalization where applicable); internal-name is lowercased as-
         is.

     3.  local-id is case-sensitive and MUST be preserved as sent.

     4.  AIDs MUST be compared using the canonical form.

  8.  Registration Model

  8.1.  REGISTER

     A REGISTER request includes: AID; one or more endpoints; capability
     document (versioned); TTL; and cryptographic proof.

     Registrations are soft-state and MUST be refreshed before expiration.
     Refresh is performed by sending a new REGISTER request with the same
     (aid, binding_id) pair.

  8.2.  DEREGISTER

     An agent MAY explicitly remove its registration.

  8.3.  Registration Semantics

     Registration is idempotent on (aid, binding_id).  If a client sends
     the same (aid, binding_id), the server MUST treat it as a refresh.

     If a client sends the same aid with a different binding_id, the
     server MUST return a conflict error unless the client has
     registry:override scope.

  8.4.  TTL and Refresh

     The server MUST be authoritative for expires_at and SHOULD return it
     in responses.

     Clients SHOULD refresh at <= 0.5 * ttl with random jitter.

     The server MUST define and enforce TTL bounds and advertise them in a
     metadata resource (recommended: /.well-known/ardp/meta).

  8.5.  Meta Resource

     This section defines a metadata resource for deployments using HTTPS
     bindings.

     Path: GET /.well-known/ardp/meta



  Pioli                    Expires 28 August 2026                 [Page 6]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     The response advertises server capabilities, TTL bounds, supported
     protocols, and proof-of-control requirements:

     {
       "version": "1.0",
       "registrar_id": "ardp.example.com",
       "min_ttl": 30,
       "max_ttl": 3600,
       "default_ttl": 300,
       "supported_protocols": ["MCP", "A2A", "HTTP", "gRPC"],
       "supported_auth_methods": ["jws-proof-of-control"],
       "jws_required": true,
       "nonce_endpoint": "/.well-known/ardp/nonce",
       "supported_schema_versions": ["v0"],
       "compliance_mode": "standard"
     }

     When jws_required is true, the nonce_endpoint field indicates where
     clients acquire nonces for proof-of-control.

  9.  Discovery and Resolution

  9.1.  RESOLVE

     RESOLVE maps an AID to active endpoints and capabilities.  Access
     MUST be authorized via the registry:resolve scope.

  9.2.  QUERY

     QUERY allows authorized discovery by capability or namespace.
     Results SHOULD be minimized to prevent metadata leakage.

     Access MUST be authorized via the registry:query scope.

  9.3.  Privacy Defaults and Redaction

     By default, QUERY returns only aid and status.  Clients MAY request
     full details via a detail=full parameter.

     If redaction applies, the server MUST omit restricted fields and
     include "redacted": true in the response.

  10.  Capabilities

     Capability documents MAY include supported protocols (MCP, A2A, HTTP,
     gRPC), transport bindings, authentication mechanisms, modalities,
     rate or cost hints, and protocol-specific metadata.  Capabilities are
     declarative and do not imply authorization.



  Pioli                    Expires 28 August 2026                 [Page 7]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


  10.1.  Capability Bindings

     Capabilities MUST include protocol-specific bindings when a protocol
     is declared.

  11.  Presence and Health

     Presence is limited to: online, offline, degraded.

  12.  Security Considerations

     Threats include identity spoofing, registration poisoning,
     unauthorized discovery, replay and downgrade attacks, and registrar
     compromise.

     Mitigations include cryptographic identity proof, signed
     registrations, strict authorization, rate limiting, and audit
     logging.

  12.1.  Proof of Control

     Proof-of-control is REQUIRED for REGISTER and refresh operations.
     RESOLVE and QUERY do not use proof-of-control; they are authorized
     via scopes (see Authorization Scopes below).

  12.1.1.  Signed Payload

     Clients MUST present a JWS-signed proof when registering or
     refreshing.  The signed payload consists of:

     *  The registration body, serialized as deterministic JSON

     *  A server-provided nonce

     *  An issued_at timestamp in RFC 3339 format

  12.1.2.  Deterministic JSON Serialization

     The registration body MUST be serialized using deterministic JSON
     with the following rules:

     *  Object keys are sorted lexicographically (Unicode code point
        order)

     *  No insignificant whitespace between tokens

     *  Array element order is preserved




  Pioli                    Expires 28 August 2026                 [Page 8]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     *  Strings are encoded as UTF-8

     *  Numbers use minimal representation without trailing zeros

  12.1.3.  Nonce Acquisition

     Clients acquire nonces via:

     GET /.well-known/ardp/nonce

     The response is a JSON object:

     {
       "nonce": "abc123...",
       "expires_in": 300
     }

     Nonces are single-use or have a narrow replay window.  The
     recommended TTL is 300 seconds.  The nonce endpoint is advertised in
     the /meta response when JWS proof-of-control is required.

  12.1.4.  Verification

     Servers MUST verify the JWS using a JWKS key set (RFC 7517) or a
     configured trust store.

     Servers MUST enforce replay windows and clock skew tolerances.

  12.1.5.  Algorithm Support

     Implementations MUST support ES256 (ECDSA using P-256 and SHA-256).

     Implementations MAY additionally support: RS256, RS384, RS512, PS256,
     PS384, PS512, ES384, ES512.

     EdDSA is not currently supported.

  12.2.  Authorization Scopes

     Proof-of-control is used for REGISTER and refresh operations.
     Authorization scopes apply to all operations and are the primary
     access control mechanism for RESOLVE and QUERY.

     Operations require the following scopes:

     *  registry:register - required for REGISTER





  Pioli                    Expires 28 August 2026                 [Page 9]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     *  registry:refresh - required for refresh (re-REGISTER with same
        binding_id)

     *  registry:resolve - required for RESOLVE

     *  registry:query - required for QUERY

     *  registry:deregister - required for DEREGISTER

     *  registry:override - allows registering with a different binding_id
        for an existing AID

  13.  Federation

     Registrars MAY federate across domains via explicit trust
     relationships and policy agreements.

  13.1.  Federation Profile (Minimum)

     Federation is allowed only between explicit trust anchors.

     Responses from remote registrars MUST include provenance fields:
     origin_authority, origin_registrar_id, origin_signature.

     Caches MUST honor remote TTL and mark records as federated.

  14.  Relationship to Existing Protocols

     ARDP complements, and does not replace, agent interaction protocols
     such as MCP and A2A.

  15.  Wire Format Sketch (Non-Normative)

     JSON over HTTPS is shown as an example binding.  Alternative
     encodings (e.g., CBOR, gRPC) are possible.

  15.1.  Minimal HTTPS Binding

     This section describes a minimal HTTPS binding for ARDP operations.
     All endpoints are under the /.well-known/ardp/ path prefix.

     *  GET /.well-known/ardp/meta - Returns server metadata including TTL
        bounds, supported protocols, and proof-of-control requirements.

     *  GET /.well-known/ardp/nonce - Returns a JSON object with nonce and
        expires_in fields for use in proof-of-control.





  Pioli                    Expires 28 August 2026                [Page 10]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     *  POST /.well-known/ardp/register - Registers or refreshes an agent.
        Refresh is performed by re-registering with the same (aid,
        binding_id).

     *  POST /.well-known/ardp/deregister - Removes an agent registration.

     *  GET /.well-known/ardp/resolve?aid={aid} - Resolves an AID to
        endpoints and capabilities.

     *  GET /.well-known/ardp/query - Queries for agents by capability or
        namespace.  Supports parameters: protocol, schema, limit, offset,
        detail.  Default returns minimal data; use detail=full to request
        complete records.

  15.2.  Error Model

     Servers MUST return errors with: code (stable error code), message
     (human-readable), and correlation_id (for tracing).

     Required codes: invalid_aid, unauthorized, forbidden, conflict,
     not_found, expired.

  16.  IANA Considerations

  16.1.  Well-Known URI

     IANA is requested to register the following URI suffix per RFC 8615
     in the "Well-Known URIs" registry:

     URI suffix: ardp

     Change controller: IETF

     Specification document(s): This document

  16.2.  Agent Identifier Namespace

     The agent: prefix is used as an internal identifier namespace and is
     not registered as a URI scheme in this version.

  17.  Capability Schema v0

     A minimal JSON schema for capability documents is provided as a
     companion artifact in the GitHub mirror.







  Pioli                    Expires 28 August 2026                [Page 11]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


  18.  Open Issues

     *  Capability schema evolution

     *  Privacy-preserving discovery

     *  Federation bootstrapping

     *  Consider adopting RFC 8785 (JSON Canonicalization Scheme) for
        deterministic JSON serialization in a future revision

  19.  References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, 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, 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                Timestamps", RFC 3339, 2002,
                <https://www.rfc-editor.org/rfc/rfc3339>.

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

     [RFC5890]  Klensin, J., "Internationalized Domain Names for
                Applications (IDNA): Definitions and Document Framework",
                RFC 5890, 2010, <https://www.rfc-editor.org/rfc/rfc5890>.

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

     [RFC7517]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Key
                (JWK)", RFC 7517, 2015,
                <https://www.rfc-editor.org/rfc/rfc7517>.

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

  Author's Address





  Pioli                    Expires 28 August 2026                [Page 12]


  Internet-Draft  Agent Registration and Discovery Protoco   February 2026


     Roberto Pioli
     Independent
     Email: roberto.pioli@gmail.com
















































  Pioli                    Expires 28 August 2026                [Page 13]


name: draft-yue-anima-agent-recovery-networks
rev: 00
title: Task-Oriented Multi-Agent Recovery Framework for High-Reliability in Converged Mobile Networks
time: 2026-02-06T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-02-06T04:11:23Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659072+00:00
source: ietf
abstract:
  This document defines a task-oriented, agent-based method for fault
     recovery in converged public-private mobile networks.  The proposed
     method introduces a multi-agent collaboration framework that enables
     autonomous failure detection, scoped diagnosis, inter-domain
     coordination, and intent-driven policy reconfiguration.  It is
     particularly applicable in complex 5G/6G network deployments, such as
     Multi-Operator Core Networks (MOCN) and Standalone Non-Public
     Networks (SNPN), where traditional centralized management is
     insufficient for ensuring high service reliability and dynamic
     recovery.  The document also specifies protocol requirements for
     inter-agent communication, state consistency, and secure
     coordination, aiming to support interoperability and resilience
     across heterogeneous network domains.

full_text:
  anima                                                        Y. Yue, Ed.
  Internet-Draft                                             X. Zhang, Ed.
  Intended status: Standards Track                            China Unicom
  Expires: 5 February 2026                                   4 August 2025


    Task-Oriented Multi-Agent Recovery Framework for High-Reliability in
                         Converged Mobile Networks
                 draft-yue-anima-agent-recovery-networks-00

  Abstract

     This document defines a task-oriented, agent-based method for fault
     recovery in converged public-private mobile networks.  The proposed
     method introduces a multi-agent collaboration framework that enables
     autonomous failure detection, scoped diagnosis, inter-domain
     coordination, and intent-driven policy reconfiguration.  It is
     particularly applicable in complex 5G/6G network deployments, such as
     Multi-Operator Core Networks (MOCN) and Standalone Non-Public
     Networks (SNPN), where traditional centralized management is
     insufficient for ensuring high service reliability and dynamic
     recovery.  The document also specifies protocol requirements for
     inter-agent communication, state consistency, and secure
     coordination, aiming to support interoperability and resilience
     across heterogeneous network domains.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 5 February 2026.

  Copyright Notice

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




  Yue & Zhang              Expires 5 February 2026                [Page 1]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
     3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Dynamic Fault Recovery in Shared 5G MOCN
             Infrastructure  . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Autonomous Recovery in Enterprise SNPN  . . . . . . . . .   4
       3.3.  Cross-Domain Policy Conflict Resolution . . . . . . . . .   4
       3.4.  SLA-Aware Remediation in AI-Driven RAN  . . . . . . . . .   5
     4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Protocol Requirements . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Agent Communications Interface  . . . . . . . . . . . . .   6
       5.2.  Message Semantics and Encoding  . . . . . . . . . . . . .   6
       5.3.  Reliability, Ordering, and Timeout Handling . . . . . . .   7
       5.4.  Security and Trust Requirements . . . . . . . . . . . . .   7
       5.5.  Behavior and State Consistency  . . . . . . . . . . . . .   7
       5.6.  Interoperability Considerations . . . . . . . . . . . . .   7
     6.  Task-Oriented Agent-Based Recovery Method for High-Reliability
             Assurance . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Objectives  . . . . . . . . . . . . . . . . . . . . . . .   8
       6.2.  Agent Roles and Responsibilities  . . . . . . . . . . . .   8
       6.3.  Recovery Workflow . . . . . . . . . . . . . . . . . . . .   9
         6.3.1.  Scoped Fault Correlation  . . . . . . . . . . . . . .   9
         6.3.2.  Intent-Driven Recovery Evaluation . . . . . . . . . .   9
         6.3.3.  Inter-Domain Coordination . . . . . . . . . . . . . .   9
         6.3.4.  Execution and Safety Enforcement  . . . . . . . . . .  10
         6.3.5.  Feedback Loop and Adaptive Monitoring . . . . . . . .  10
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10










  Yue & Zhang              Expires 5 February 2026                [Page 2]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


  1.  Introduction

     As mobile networks evolve toward 5G and 6G architectures, new
     deployment paradigms such as Multi-Operator Core Networks (MOCN),
     Shared RAN, and Standalone Non-Public Networks (SNPN) have emerged to
     support both public and enterprise services.  These converged
     deployments introduce unprecedented complexity in terms of topology,
     administrative boundaries, resource sharing, and dynamic service
     intent management.

     Ensuring high reliability in such networks is increasingly difficult
     using traditional centralized network management systems, which often
     suffer from limited scalability, slow responsiveness, and single
     points of failure.  These limitations are particularly critical in
     enterprise and industrial environments, where service-level
     agreements (SLAs) mandate deterministic latency, availability, and
     adaptability.

     This document introduces a task-oriented, agent-based recovery method
     that enables distributed fault detection, context-aware correlation,
     inter-agent negotiation, and closed-loop policy execution.  Agents
     operate at various roles — including telemetry monitoring, domain
     coordination, policy interpretation, and action enforcement — and
     communicate through a structured Agent Communication Interface (ACI).
     The method is designed to autonomously localize faults, assess
     recovery strategies based on service intents, and coordinate recovery
     actions across administrative domains, with minimal human
     intervention.

     In addition to describing the recovery workflow and agent roles, this
     document outlines the associated protocol requirements to ensure
     secure, consistent, and interoperable interactions among agents.
     These requirements cover communication semantics, message formats,
     transport assumptions, and behavioral guarantees.  The goal is to
     enable standards-compliant, intent-aware, and autonomous fault
     management in future mobile network infrastructures.

  2.  Conventions and Terminology

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

     Abbreviations and definitions used in this document: *ACI: Agent
     Communication Interface. *DCA: Domain Coordination Agent. *EA:
     Execution Agent. *FDA: Fault Detection Agent. *FSM: Finite State



  Yue & Zhang              Expires 5 February 2026                [Page 3]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


     Machine. *LLM: Large Language Model. *MOCN: Multi-Operator Core
     Network. *MTTR: Mean Time to Recovery. *PIA: Policy Interpretation
     Agent. *SLA: Service-Level Agreement. *SNPN: Standalone Non-Public
     Network. *URI: Uniform Resource Identifier.

  3.  Use Cases

     The method defined in this document applies to several real-world use
     cases in future mobile network environments:

  3.1.  Dynamic Fault Recovery in Shared 5G MOCN Infrastructure

     In Multi-Operator Core Network (MOCN) deployments, multiple mobile
     network operators (MNOs) share the same RAN and transport
     infrastructure.  A node failure or link degradation in the shared
     segment can affect multiple tenant slices simultaneously.  With
     agent-based coordination, local agents at affected nodes can detect
     the fault, and domain-level agents from each operator can negotiate
     temporary recovery strategies (e.g., re-routing or resource
     reallocation) without requiring centralized orchestration or full-
     stack configuration reloading.

  3.2.  Autonomous Recovery in Enterprise SNPN

     Standalone Non-Public Networks (SNPN) are often deployed by
     enterprises to support on-site applications such as industrial
     automation, AGV coordination, or safety monitoring.  In these
     environments, recovery must be both low-latency and intent-aware.
     For example, if a compute node hosting a real-time controller fails,
     the agent system can trigger service migration to a backup node based
     on the intent to maintain <10ms latency for URLLC traffic, without
     requiring manual administrator intervention.

  3.3.  Cross-Domain Policy Conflict Resolution

     In hybrid deployments where a public network operator provides
     managed service slices to enterprises, misaligned policies across
     administrative domains may cause service disruptions (e.g., route
     loops, priority mismatches).  With inter-domain agent negotiation,
     agents can exchange scoped views of current state and intent,
     evaluate compatibility, and agree on a temporary policy contract to
     preserve service continuity until a global policy reconciliation
     occurs.








  Yue & Zhang              Expires 5 February 2026                [Page 4]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


  3.4.  SLA-Aware Remediation in AI-Driven RAN

     With the rise of AI-native RAN optimization, agents embedded within
     distributed units (DU/CU) or edge compute nodes may detect
     performance anomalies (e.g., increased jitter, burst loss).  Rather
     than waiting for offline model retraining, the system can dynamically
     adapt configuration (e.g., buffer allocation, scheduler adjustment)
     using the agent-based recovery workflow to preserve SLA requirements
     in real time.

  4.  Problem Statement

     In converged public-private mobile networks, ensuring service
     continuity and network reliability in the event of failures is a
     fundamental requirement, particularly for enterprise and critical
     infrastructure scenarios.  Traditional centralized network management
     systems often suffer from single points of failure and delayed
     recovery, which are unacceptable in contexts where deterministic
     availability and ultra-low downtime are essential.  Multi-agent
     systems enable fault-tolerant operation through distributed
     intelligence and redundancy.  When a failure occurs—such as link
     disconnection, node crash, or policy conflict—a well-coordinated
     group of agents can dynamically detect, localize, and mitigate the
     issue through real-time communication and cooperative decision-
     making.  This distributed resilience mechanism reduces mean time to
     recovery (MTTR) and minimizes the impact radius of failures.
     Moreover, in cross-domain environments (e.g., MOCN with multiple
     operators or SNPN with enterprise-hosted infrastructure), fault
     management becomes more complex due to administrative isolation and
     heterogeneous control planes.  Intelligent agents deployed at domain
     boundaries can negotiate fallback strategies, synchronize state
     across domains, and maintain policy consistency during partial
     outages.  For example, upon detecting performance degradation in a
     tenant slice, the agents can proactively rebalance traffic, reassign
     resources, or trigger intent re-interpretation without waiting for
     centralized orchestration.  Without agent-based failure
     collaboration, the system risks becoming fragmented, with isolated
     components unable to respond effectively to cascading failures.
     Therefore, enabling resilient, autonomous coordination among agents
     in failure scenarios is essential to support high-availability SLAs,
     enhance robustness against dynamic network threats, and reduce
     operational overhead in complex network environments.









  Yue & Zhang              Expires 5 February 2026                [Page 5]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


  5.  Protocol Requirements

     To support the efficient and intelligent transmission of sensing data
     in 6G environments, enhancements to the MoQ protocol are proposed.
     These enhancements aim to enrich MoQ metadata or header extensions to
     include key information required for intelligent routing, data
     classification, service mapping, and QoS-aware scheduling in sensing-
     centric applications.

  5.1.  Agent Communications Interface

     This section specifies the protocol-level requirements to support the
     agent-based recovery method defined in Section 5.  These requirements
     cover message formats, communication interfaces, timing constraints,
     behavioral consistency, and inter-domain negotiation semantics.  The
     goal is to ensure interoperability, reliability, and intent-aware
     execution of fault recovery workflows across diverse network domains
     and agent implementations.  REQ-1: The system SHOULD define a
     structured Agent Communication Interface (ACI) to support
     asynchronous and event-driven communication among agents.  REQ-2: ACI
     SHOULD support the following core message types: FAULT_EVENT: Sent
     from FDA to DCA; conveys detected fault condition.
     SCOPE_CORRELATION_QUERY/REPLY: Between DCAs; used for inter-domain
     fault localization.  INTENT_REQUEST/RESPONSE: Between DCA and PIA;
     conveys service-level intent and policy goals.  RECOVERY_PROPOSAL:
     Sent from initiating DCA to peer DCA(s); contains proposed joint
     recovery actions.  RECOVERY_CONTRACT: Formalizes agreement among
     domains on resource reallocation and rollback.

     EXECUTION_COMMAND: Sent from DCA to EA to enact recovery actions.
     EXECUTION_STATUS: Sent from EA to DCA to report outcome and
     validation results.  REQ-3: All ACI messages SHOULD include: Agent
     identity and role Timestamp Message type and version Unique
     transaction/session ID Integrity protection (e.g., signature or HMAC)
     REQ-4: The ACI protocol SHOULD support both push and pull modes for
     event dissemination and agent querying.

  5.2.  Message Semantics and Encoding

     REQ-5: Protocol messages SHOULD be encoded using a format that is
     both human-readable and machine-processable.  JSON and CBOR are
     RECOMMENDED; protocol buffers MAY be used in constrained
     environments.  REQ-6: Each message type SHOULD conform to a pre-
     defined schema, including required and optional fields.  REQ-7:
     Message payloads involving intent retrieval or policy proposals
     SHOULD include a service identifier that maps to a known SLA or
     intent profile.




  Yue & Zhang              Expires 5 February 2026                [Page 6]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


  5.3.  Reliability, Ordering, and Timeout Handling

     REQ-8: Protocol exchanges involving recovery workflows MUST support
     acknowledgment and retry mechanisms.  REQ-9: Agents participating in
     a recovery transaction MUST support: Timers for detecting negotiation
     or execution timeout Fallback strategies upon failure to reach
     consensus or apply action REQ-10: ACI message transport MUST
     guarantee in-order delivery of messages within a session context,
     particularly for multi-step negotiation sequences.

  5.4.  Security and Trust Requirements

     REQ-11: All ACI communications MUST be secured using mutually
     authenticated channels.  REQ-12: Agents MUST maintain a local trust
     registry of peer agents and their associated roles, identities, and
     access policies.  REQ-13: Inter-domain messages MUST be
     cryptographically signed and include domain-level identifiers to
     prevent spoofing or replay.  REQ-14: Sensitive data in intent
     evaluation MUST be protected during transit and only exposed to
     authorized agents.

  5.5.  Behavior and State Consistency

     REQ-15: Agents MUST implement finite state machines (FSMs) to ensure
     correct handling of message sequences and recovery states.  REQ-16:
     In case of multi-agent execution, agents MUST agree on task status
     codes to track workflow progress consistently.  REQ-17: Feedback and
     learning data SHOULD be stored in a common, queryable knowledge base
     accessible to policy training agents.

  5.6.  Interoperability Considerations

     REQ-18: Implementations MUST support version negotiation for ACI
     messages to ensure forward compatibility.  REQ-19: Domain-specific
     extensions (e.g., for 5G MOCN, SNPN) MUST be encapsulated using an
     optional extension field, and MUST NOT interfere with baseline schema
     validation.  REQ-20: Recovery workflows MUST be idempotent where
     possible, allowing repeated execution without unintended side effects
     in failure or retry scenarios.












  Yue & Zhang              Expires 5 February 2026                [Page 7]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


  6.  Task-Oriented Agent-Based Recovery Method for High-Reliability
      Assurance

     This part defines a distributed, agent-based recovery method that
     supports high-reliability service assurance in converged public-
     private mobile networks.  The method enables autonomous failure
     detection, scoped diagnosis, and intent-driven policy adaptation
     through coordination among multiple intelligent agents.  It is
     designed to address both intra-domain and inter-domain failure
     scenarios while maintaining SLA compliance.

  6.1.  Objectives

     The method is designed to fulfill the following objectives: (1)
     Resilience through distribution: Eliminate single points of failure
     by decentralizing failure detection and recovery logic across agents.
     (2) Scoped collaboration: Allow agents to reason over localized
     context while supporting inter-agent negotiation for broader fault
     scenarios. (3) Intent consistency: Ensure that all recovery decisions
     align with user or service-level intents registered in the system.
     (4) Closed-loop adaptability: Continuously monitor recovery outcomes
     and feed them into learning or policy refinement processes. (5) The
     method is applicable in deployment environments such as 5G MOCN,
     SNPN, or 6G hybrid infrastructures involving multiple tenants and
     administrative domains.

  6.2.  Agent Roles and Responsibilities

     The method introduces four distinct roles for intelligent agents,
     each fulfilling a key functional responsibility in the recovery
     workflow: (1) Fault Detection Agent (FDA): Resides at network or
     compute nodes; performs real-time telemetry monitoring.  Upon
     threshold violation, constructs a structured fault event including
     metadata such as event ID, node ID, timestamp, metric type, and
     severity. (2) Domain Coordination Agent (DCA): Aggregates events from
     multiple FDAs to determine failure scope and severity.  Responsible
     for intra-domain coordination and inter-domain negotiation when
     needed. (3) Policy Interpretation Agent (PIA): Retrieves and parses
     registered service intents.  Evaluates recovery options and generates
     adaptive policy updates based on current state and available
     resources. (4) Execution Agent (EA): Applies the reconfiguration
     actions (e.g., rerouting, resource migration, parameter adjustment)
     and performs post-configuration checks to ensure compliance and
     stability.  All agents communicate over an Agent Communication
     Interface (ACI), which provides structured messaging primitives for
     event reporting, status querying, negotiation, and command dispatch.





  Yue & Zhang              Expires 5 February 2026                [Page 8]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


  6.3.  Recovery Workflow

     The recovery method consists of the following task-oriented workflow:
     ### Fault Detection and Event Generation FDA continuously monitors
     key performance metrics (e.g., latency, packet loss, CPU
     utilization).  On violation, FDA emits a structured fault event:
     +-------------------+-----------------------------+ | Field | Value |
     +-------------------+-----------------------------+ | event_id |
     e12345 | | node_id | node-A | | timestamp | 2025-07-21T08:00:00Z | |
     metric | link_loss | | value | 15.2 | | threshold | 10.0 | |
     severity | major |
     +-------------------+-----------------------------+ This event is
     transmitted to the local DCA via ACI.

  6.3.1.  Scoped Fault Correlation

     DCA aggregates fault reports from FDAs and analyzes temporal-spatial
     correlations.  If patterns emerge indicating a localized or
     distributed failure domain, DCA maps the affected logical services
     (e.g., slices, functions, access nodes).  If the impact likely
     crosses domain boundaries (e.g., MOCN core or shared RAN), the DCA
     initiates inter-domain state queries.

  6.3.2.  Intent-Driven Recovery Evaluation

     DCA invokes PIA with a fault-context descriptor.  PIA queries the
     intent registry and retrieves the affected service's constraints and
     goals, such as:
     +---------------------+----------------------------+ | Field |
     Value | +---------------------+----------------------------+ |
     intent_id | tenant-001-intent | | sla.latency | < 20ms | |
     sla.availability | 99.99% | | fallback_policy | [reroute,
     degrade_qos] | | priority | critical |
     +---------------------+----------------------------+ PIA evaluates
     multiple recovery strategies (e.g., traffic shift, resource
     migration, service downgrade) and scores them against SLA compliance
     and resource availability.

  6.3.3.  Inter-Domain Coordination

     When faults span across domains, the DCA of the initiating domain
     sends a Recovery Proposal Message to peer DCAs.  Each DCA evaluates
     local resource availability and responds with either: Acceptance of
     shared recovery effort (with constraints), or Negotiation of a
     fallback agreement (with time limits and rollback conditions).  Upon
     consensus, a Recovery Execution Contract is established, which
     includes scope, roles, time windows, and validation checkpoints.




  Yue & Zhang              Expires 5 February 2026                [Page 9]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


  6.3.4.  Execution and Safety Enforcement

     DCA dispatches a recovery command to EA, which applies configurations
     (e.g., policy updates, slice rerouting, traffic prioritization).  EA
     performs pre- and post-checks to verify: Policy consistency
     Compliance with intent System stability post-update

  6.3.5.  Feedback Loop and Adaptive Monitoring

     After execution, FDA switches to enhanced monitoring mode in affected
     areas (e.g., higher-frequency sampling, link probing).  DCA collects
     performance data and sends summary logs to a shared knowledge base
     for: Post-mortem analysis Learning model refinement (e.g.,
     reinforcement learning agent tuning) If instability persists, PIA may
     auto-trigger policy reevaluation or escalate to supervisory agent
     layer.

  7.  Security Considerations

     TBD

  8.  IANA Considerations

     TBD

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

  Authors' Addresses

     Yi Yue (editor)
     China Unicom
     Beijing
     China
     Email: yuey80@chinaunicom.cn








  Yue & Zhang              Expires 5 February 2026               [Page 10]


  Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


     Xuebei Zhang (editor)
     China Unicom
     Beijing
     China
     Email: zhangxb170@chinaunicom.cn














































  Yue & Zhang              Expires 5 February 2026               [Page 11]


name: draft-diaconu-agents-authz-info-sharing
rev: 00
title: Cross-Domain AuthZ Information sharing for Agents
time: 2026-02-06T14:58:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-10T14:58:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:05.659076+00:00
source: ietf
abstract:
  Distributed Multi-Agent Systems consist of Agents and MCP Servers
     operating across multiple administrative domains, each with its own
     Identity Providers (IdPs) and Authorization Servers (AS).

     This document discusses the challenges and solution approaches for
     sharing authorization information securely and flexibly across
     domains, including the use of dynamic identity, interoperable claims,
     and verifiable credentials.

full_text:
  Internet Engineering Task Force                               J. Diaconu
  Internet-Draft                                               M. Yannuzzi
  Intended status: Standards Track                                H. Muyal
  Expires: 10 August 2026                                     F. Brockners
                                                                   N. Kale
                                                                     Cisco
                                                                A. Agarwal
                                                                   Skyfire
                                                                J. Hickman
                                                                  Ory Corp
                                                                    A. Lal
                                                                       AWS
                                                           6 February 2026


             Cross-Domain AuthZ Information sharing for Agents
                 draft-diaconu-agents-authz-info-sharing-00

  Abstract

     Distributed Multi-Agent Systems consist of Agents and MCP Servers
     operating across multiple administrative domains, each with its own
     Identity Providers (IdPs) and Authorization Servers (AS).

     This document discusses the challenges and solution approaches for
     sharing authorization information securely and flexibly across
     domains, including the use of dynamic identity, interoperable claims,
     and verifiable credentials.

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






  Diaconu, et al.          Expires 10 August 2026                 [Page 1]


  Internet-Draft          AuthZ Sharing for Agents           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.  Conventions Used in This Document . . . . . . . . . . . . . .   4
     3.  Abbreviations / Definitions . . . . . . . . . . . . . . . . .   4
     4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Cross-Domain Tool Invocation  . . . . . . . . . . . . . .   5
       4.2.  Enterprise Partnership Integration  . . . . . . . . . . .   5
       4.3.  Multi-Vendor Workflow Orchestration . . . . . . . . . . .   5
       4.4.  Supply Chain Data Exchange  . . . . . . . . . . . . . . .   6
       4.5.  Regulatory Compliance Across Jurisdictions  . . . . . . .   6
     5.  Requirements Summary  . . . . . . . . . . . . . . . . . . . .   7
     6.  Solution Approaches . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  Solution Approach 1: Dynamic Client Registration (RFC
             7591) . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       6.2.  Solution Approach 2: SCIM extensions  . . . . . . . . . .   8
       6.3.  Solution Approach 3: Client-ID Metadata . . . . . . . . .   9
       6.4.  Solution Approach 4: Client-ID Metadata + W3C Verifiable
             Credentials Extension . . . . . . . . . . . . . . . . . .  11
         6.4.1.  Delegation Semantics for Cross-Domain Multi-Agent
                 Workflows . . . . . . . . . . . . . . . . . . . . . .  13
         6.4.2.  Agent Authorization Verifiable Credential Profile . .  18
     7.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       7.1.  Client-ID Metadata Example  . . . . . . . . . . . . . . .  21
       7.2.  Verifiable Credential Example . . . . . . . . . . . . . .  21
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
       8.1.  Security Considerations . . . . . . . . . . . . . . . . .  23
         8.1.1.  Threat Model for Cross-Domain Authorization
                 Sharing . . . . . . . . . . . . . . . . . . . . . . .  23
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
       10.1.  Informative References . . . . . . . . . . . . . . . . .  28
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29




  Diaconu, et al.          Expires 10 August 2026                 [Page 2]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  1.  Introduction

     Distributed Multi-Agent Systems, consisting of Agents and Model
     Context Protocol (MCP) Servers, are increasingly deployed across
     multiple administrative domains.  Each domain typically operates its
     own Identity Providers (IdPs) and Authorization Servers (AS),
     creating a fundamental challenge: how can an agent from Organization
     A securely prove its identity and authorization to resources in
     Organization B?

     While OAuth 2.0 and related specifications provide robust
     authorization frameworks for human users and pre-registered clients,
     the emergence of autonomous agent systems operating across
     organizational boundaries presents new challenges that existing
     mechanisms do not fully address.

     This challenge is distinct from traditional cross-domain identity
     federation for human users.  Humans rarely delegate authority through
     multiple organizational boundaries.  Agents routinely do so--an
     orchestrator agent in Domain X may invoke a tool agent in Domain Y,
     which accesses an MCP server in Domain Z.  Existing authorization
     mechanisms such as OAuth 2.0 Dynamic Client Registration [RFC7591]
     and Token Exchange [RFC8693] assume single-domain operation or pre-
     established relationships, and do not address the dynamic, multi-hop
     delegation patterns that characterize modern agentic systems.

     This document analyzes the cross-domain agent authorization problem
     and evaluates solution approaches.  The proposed solution extends
     OAuth 2.0 Client-ID Metadata
     [I-D.ietf-oauth-client-id-metadata-document] with W3C Verifiable
     Credentials [W3C.VCDM2.0] to enable dynamic identity establishment
     without pre-registration across domains, cryptographically verifiable
     authorization claims that travel with the agent, multi-hop delegation
     with monotonic scope narrowing and accountability chains, and
     selective disclosure of sensitive authorization attributes.

     The document is structured as follows: Section 3 defines key
     terminology.  Section 4 presents use cases demonstrating cross-domain
     scenarios.  Section 8.1.1 identifies threats specific to cross-domain
     authorization sharing.  Section 5 establishes requirements and
     evaluates solution approaches.  Section 8.1 covers security
     considerations.









  Diaconu, et al.          Expires 10 August 2026                 [Page 3]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  2.  Conventions Used in This Document

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

  3.  Abbreviations / Definitions

     Agent  An autonomous entity that performs tasks on behalf of a user
        or another program within a multi-agent system.

     MCP Server  A program that exposes specific capabilities, like data
        access or tools, to AI models through the Model Context Protocol
        (MCP).

     AS (Authorization Server)  A server that issues authorization tokens
        to clients after successfully authenticating them.

     IdP (Identity Provider)  A service that creates, manages, and
        verifies digital identities for users and service users, often for
        accessing multiple applications and services.

     Subject  The principal (user or service).

     Claim  Essentially a piece of information asserted about a subject.

     Domain  Scope over which a specific, uniform set of security policies
        and user management rules are enforced.

     VCDM 2.0  Verifiable Credentials Data Model 2.0, a W3C standard for
        expressing verifiable credentials on the web.

     VC  Verifiable Credential, a digital credential that is
        cryptographically secure and can be verified independently.

     SD-JWT  Selective Disclosure JSON Web Token, a JWT that allows the
        holder to disclose only specific parts of the token.

     DID  Decentralized Identifier, a new type of identifier that enables
        verifiable, self-sovereign digital identities.

  4.  Use Cases

     The following use cases demonstrate scenarios where cross-domain
     agent authorization presents challenges not addressed by existing
     single-domain mechanisms.



  Diaconu, et al.          Expires 10 August 2026                 [Page 4]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  4.1.  Cross-Domain Tool Invocation

     A coding assistant agent operated by Developer Tools Inc. needs to
     invoke a code review tool provided by Code Analysis Corp.  The tool
     is exposed as an MCP Server protected by Code Analysis Corp's
     Authorization Server.

     Cross-Domain Challenge  Developer Tools Inc.'s agent must present
        credentials that Code Analysis Corp's AS can verify, despite
        having no pre-existing trust relationship.  The AS must determine
        what operations the agent may perform based on claims issued by a
        foreign domain.

     Requirements  Verifiable agent and MCP server identity across domain
        boundaries, authorization claims that are interpretable by the
        receiving domain.

  4.2.  Enterprise Partnership Integration

     Company A partners with Company B to provide integrated customer
     support services.  Company A deploys a support agent that needs to
     access Company B's customer ticketing system and knowledge base to
     resolve customer issues.

     Cross-Domain Challenge  Company A's agent authenticates using Company
        A's IdP and holds a Verifiable Credential issued by Company A.
        Company B's Authorization Server has no trust relationship with
        Company A's IdP--it cannot verify Company A's tokens.  Company B
        needs a mechanism to verify the agent's identity and authorization
        claims without requiring bilateral federation setup for every
        partner.

     Requirements  Dynamic identity verification across domains,
        verifiable compliance attestations, and scope restrictions that
        Company B's AS can enforce based on Company A's authorization
        grants.

  4.3.  Multi-Vendor Workflow Orchestration

     A security operations workflow involves agents from multiple vendors:
     an orchestrator agent from Security Vendor X coordinates a threat
     intelligence agent from Vendor Y and a remediation agent from Vendor
     Z.  The orchestrator must delegate appropriate permissions to each
     specialized agent.

     Cross-Domain Challenge  The orchestrator in Domain X must delegate





  Diaconu, et al.          Expires 10 August 2026                 [Page 5]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


        authority to agents in Domains Y and Z.  Each receiving domain
        must verify the delegation chain, ensure the delegated scope does
        not exceed what the originating principal authorized, and maintain
        an auditable record of the delegation chain.  Receiving domains
        must ensure that the authorization decisions do not rely on
        revoked, suspended, or superseded delegations by performing
        runtime delegation chain verification according to the local
        policy.

     Requirements  Multi-hop delegation with scope narrowing, cross-domain
        accountability chains, privacy-preserving identity claims, and
        domain-specific policy enforcement at each trust boundary
        crossing.

  4.4.  Supply Chain Data Exchange

     A manufacturer's inventory management agent needs to query suppliers'
     availability systems.  Multiple suppliers operate their own
     authorization infrastructure.  The agent must access each supplier's
     MCP servers with appropriate credentials.

     Cross-Domain Challenge  Each supplier's AS must verify the
        manufacturer's agent without requiring manual pre-registration.
        Dynamic Client Registration [RFC7591] would require the agent to
        register separately with each supplier's AS, creating operational
        overhead and not providing cryptographic verification of the
        agent's authorization claims from its home domain.  The agent may
        need different permission levels at different suppliers based on
        partnership agreements.  Suppliers must be able to audit which
        manufacturer agents accessed their data.

     Requirements  Dynamic agent provisioning across multiple foreign
        domains, verifiable identity without pre-registration, and domain-
        specific scope mappings.

  4.5.  Regulatory Compliance Across Jurisdictions

     A financial services agent operating in the EU needs to access data
     from a partner institution in the US.  Both jurisdictions have
     different regulatory requirements.

     Cross-Domain Challenge  The receiving domain's AS must verify that
        the requesting agent's compliance attestations meet local policy
        requirements.  The VC issued by the originating domain asserts
        compliance with GDPR; the receiving domain must determine whether
        this satisfies its own data handling requirements without assuming
        equivalence of compliance frameworks.




  Diaconu, et al.          Expires 10 August 2026                 [Page 6]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     Requirements  Verifiable compliance attestations that receiving
        domains can evaluate against local policies, and data sensitivity
        clearance, verification across regulatory boundaries.

  5.  Requirements Summary

     A system for cross-domain sharing of authorization information of
     agents needs to meet the following set of requirements:

     *  *Dynamic Identity for Agents and MCP Servers:* The Agents and MCP
        Servers can onboard dynamically and get an assigned identity in
        the IdP.

     *  *Interoperability Across Domains:* The system must enable seamless
        interaction between Agents across different domains.

     *  *Flexible Definition of Claims:* Claims should be adaptable as
        they may vary from organization to organization.  They may include
        information related to authorization, compliance requirements,
        chains of delegation, and other domain-specific concerns.

     *  *Dynamic Management of Authorization Information:* The system must
        allow creation, removal, updating, and deletion of authorization
        information for agents, as agents can be highly dynamic.

     *  *Security and Privacy:* Ensuring secure and private sharing of
        authorization information across domains.

     *  *Compliance and Auditability:* Support for compliance with
        regulatory standards and auditability of authorization exchanges.

  6.  Solution Approaches

  6.1.  Solution Approach 1: Dynamic Client Registration (RFC 7591)

     *Description:* Dynamic Client Registration as outlined in [RFC7591]
     allows clients to register with an AS dynamically, facilitating the
     management of client credentials and metadata.

     *Discussion:*











  Diaconu, et al.          Expires 10 August 2026                 [Page 7]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     +==================+===============================+================+
     | Requirement      | Met or Partially Met          | Not Met        |
     +==================+===============================+================+
     | Dynamic Identity | Met                           |                |
     | for Agents and   |                               |                |
     | MCP Servers      |                               |                |
     +------------------+-------------------------------+----------------+
     | Interoperability | Partially Met (Granted by     |                |
     | Across Domains   | the Dynamic Registration,     |                |
     |                  | however no common ground      |                |
     |                  | between AS)                   |                |
     +------------------+-------------------------------+----------------+
     | Flexible         |                               | Not Met        |
     | Definition of    |                               | (OAuth2 claims |
     | Claims           |                               | only)          |
     +------------------+-------------------------------+----------------+
     | Dynamic          |                               | Not Met        |
     | Management of    |                               | (Delete or     |
     | Authorization    |                               | Update not     |
     | Information      |                               | supported)     |
     +------------------+-------------------------------+----------------+
     | Security and     |                               | Not Met        |
     | Privacy          |                               | (Claims are    |
     |                  |                               | shared but no  |
     |                  |                               | common schema) |
     +------------------+-------------------------------+----------------+
     | Compliance and   | Partially Met (Claims are     |                |
     | Auditability     | shared, APIs are auditable,   |                |
     |                  | but no regulatory standards   |                |
     |                  | are defined for the schema)   |                |
     +------------------+-------------------------------+----------------+

                                    Table 1

  6.2.  Solution Approach 2: SCIM extensions

     [I-D.abbey-scim-agent-extension] proposes extending the SCIM (System
     for Cross-Domain Identity Management) protocol to standardize the
     provisioning, management, and governance of AI agents and other
     digital workers.

     [I-D.wahl-scim-agent-schema] is a companion document to the draft-
     abbey-scim-agent-extension.  Its purpose is to define the specific
     SCIM schema and attributes required to represent AI agents (digital
     workers) and agentic applications within the SCIM framework.

     *Description:* Provision Agents / MCP Servers through a SCIM
     extension.



  Diaconu, et al.          Expires 10 August 2026                 [Page 8]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     *Discussion:*

       +==================+======================================+=====+
       | Requirement      | Met or Partially Met                 | Not |
       |                  |                                      | Met |
       +==================+======================================+=====+
       | Dynamic Identity | Partially Met (SCIM support is       |     |
       | for Agents and   | limited and with constraints,        |     |
       | MCP Servers      | example for Azure: “Subsequent syncs |     |
       |                  | are triggered every 20-40 minutes”.) |     |
       +------------------+--------------------------------------+-----+
       | Interoperability | Partially Met (SCIM is supported and |     |
       | Across Domains   | schema is well defined)              |     |
       +------------------+--------------------------------------+-----+
       | Flexible         | Met (Defined by the schema)          |     |
       | Definition of    |                                      |     |
       | Claims           |                                      |     |
       +------------------+--------------------------------------+-----+
       | Dynamic          | Partially Met (SCIM support is       |     |
       | Management of    | limited and with constraints,        |     |
       | Authorization    | example for Azure: “Subsequent syncs |     |
       | Information      | are triggered every 20-40 minutes”.) |     |
       +------------------+--------------------------------------+-----+
       | Security and     | Partially Met (A schema is defined   |     |
       | Privacy          | but Selective Disclosure not         |     |
       |                  | supported)                           |     |
       +------------------+--------------------------------------+-----+
       | Compliance and   | Partially Met (Claims are shared,    |     |
       | Auditability     | APIs are auditable, but no           |     |
       |                  | regulatory standards are defined for |     |
       |                  | the schema)                          |     |
       +------------------+--------------------------------------+-----+

                                    Table 2

  6.3.  Solution Approach 3: Client-ID Metadata

     *Description:* Client ID Metadata
     [I-D.ietf-oauth-client-id-metadata-document] is a method for OAuth
     clients to identify themselves using a URL, which points to a JSON
     file containing their OAuth metadata.  Instead of requiring pre-
     registration, an authorization server can fetch this JSON document at
     the client's provided URL to provision the identity.

     *Discussion:*






  Diaconu, et al.          Expires 10 August 2026                 [Page 9]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     +==================+==========================+=====================+
     | Requirement      | Met or Partially Met     | Not Met             |
     +==================+==========================+=====================+
     | Dynamic Identity | Met                      |                     |
     | for Agents and   |                          |                     |
     | MCP Servers      |                          |                     |
     +------------------+--------------------------+---------------------+
     | Interoperability | Met                      |                     |
     | Across Domains   |                          |                     |
     +------------------+--------------------------+---------------------+
     | Flexible         |                          | Not Met*            |
     | Definition of    |                          | (client_id is       |
     | Claims           |                          | common, all the     |
     |                  |                          | rest is limited     |
     |                  |                          | to OAuth2 claims)   |
     +------------------+--------------------------+---------------------+
     | Dynamic          | Met                      |                     |
     | Management of    |                          |                     |
     | Authorization    |                          |                     |
     | Information      |                          |                     |
     +------------------+--------------------------+---------------------+
     | Security and     | Partially Met** (A       |                     |
     | Privacy          | schema is defined but    |                     |
     |                  | Selective Disclosure not |                     |
     |                  | supported)               |                     |
     +------------------+--------------------------+---------------------+
     | Compliance and   | Partially Met** (Claims  |                     |
     | Auditability     | are shared, APIs are     |                     |
     |                  | auditable, but no        |                     |
     |                  | regulatory standards are |                     |
     |                  | defined for the schema)  |                     |
     +------------------+--------------------------+---------------------+

                                    Table 3

     **Flexible Definition of Claims:* The OAuth claims in the draft
     follow the claims exposed and defined by IANA OAuth Parameters.
     Hence, the metadata fields are limited to a fixed set of claims.
     This makes it difficult to convey richer features about the client,
     including provenance details, compliance attestations, or contextual
     trust scores without introducing vendor-specific extensions, thereby
     reducing portability and interoperability.









  Diaconu, et al.          Expires 10 August 2026                [Page 10]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     ***Security and Privacy, Compliance and Auditability:* All metadata
     is published to a publicly accessible endpoint.  There is no native
     ability to keep certain attributes private, apply selective
     disclosure, or restrict visibility based on trust relationships.
     Sensitive operational data or compliance-related data must be handled
     outside the metadata framework, leading to fragmented trust models.
     There is no mechanism for revocation and expiration.

  6.4.  Solution Approach 4: Client-ID Metadata + W3C Verifiable
        Credentials Extension

    Agent (Client)             AuthZ Server (AS)         Metadata Endpoint
          |                            |                      |
          | 1. Authorization Request   |                      |
          |    (client_id = URL)       |                      |
          |--------------------------->|                      |
          |                            |                      |
          |                            | 2. HTTP GET (URL)    |
          |                            |--------------------->|
          |                            |                      |
          |                            | 3. Returns Metadata  |
          |                            |    (JWKS + "vc+jwt") |
          |                            |<---------------------|
          |                            |                      |
          |                            | 4. Validate Metadata |
          |                            |    & Verify VC Signature (JWKS)
          |                            |                      |

            Figure 1: Client-ID Metadata with VC Verification Flow

     *Description:* The proposed solution is based on Solution 3, but
     enhances the supported claims with a new claim, "vc+jwt", based on
     the Verifiable Credentials Data Model 2.0 from W3C.

     vc+jwt  A standard method used in decentralized identity to package
        and secure a digital credential.  The Verifiable Credential
        (VC)—the actual data proving a fact (e.g., identity or degree)—is
        encapsulated within a JSON Web Token (JWT), which provides a
        cryptographic signature from the issuer.  This signature allows
        any third party (the Verifier) to instantly confirm the
        credential's authenticity and integrity.  Modern formats like SD-
        JWT VC further enhance this by enabling the holder to share only
        specific parts of the credential (Selective Disclosure) to protect
        privacy.

     *Discussion:*





  Diaconu, et al.          Expires 10 August 2026                [Page 11]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


        +===========================+======================+=========+
        | Requirement               | Met or Partially Met | Not Met |
        +===========================+======================+=========+
        | Dynamic Identity for      | Met                  |         |
        | Agents and MCP Servers    |                      |         |
        +---------------------------+----------------------+---------+
        | Interoperability Across   | Met (1)              |         |
        | Domains                   |                      |         |
        +---------------------------+----------------------+---------+
        | Flexible Definition of    | Met (2)              |         |
        | Claims                    |                      |         |
        +---------------------------+----------------------+---------+
        | Dynamic Management of     | Met                  |         |
        | Authorization Information |                      |         |
        +---------------------------+----------------------+---------+
        | Security and Privacy      | Met (3)              |         |
        +---------------------------+----------------------+---------+
        | Compliance and            | Met (4)              |         |
        | Auditability              |                      |         |
        +---------------------------+----------------------+---------+

                                   Table 4

     *Detailed explanations:*

     The W3C Verifiable Credentials Data Model 2.0 addresses the
     shortcomings of the previous Solution 3, by introducing a
     cryptographically verifiable and standards-based way to assert
     identities, capabilities, and compliance attestations.  It supports
     selective disclosure to protect sensitive information, enables time-
     bound and revocable authorizations, and ensures provenance tracking
     for audit and regulatory compliance.  They are part of a broader
     decentralized identity (DID) specification.

     Using the W3C Verifiable Credentials Data Model 2.0 for Agents, MCP
     Clients, and MCP Servers provides a standardized, cryptographically
     secure way to establish trust, delegate authority, and ensure
     interoperability across different systems.

     It enables Agents, MCP Clients, and MCP Servers to prove, among other
     things, their identities, identity issuers and provenance, supported
     skills and permitted actions through verifiable proofs, including
     support for fine-grained and time-bound access control, while
     maintaining transparency enabling audit trails for compliance.

     Additionally, it enhances privacy through selective disclosure and
     privacy-preserving proofs (e.g., allowing Agents to prove skills and
     authorized actions without exposing unnecessary details).



  Diaconu, et al.          Expires 10 August 2026                [Page 12]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     The Verifiable Credentials Data Model 2.0 is a W3C standard that fits
     the needs expressed above:

     *(1) Enhanced Interoperability:* VCDM 2.0 provides a standardized,
     extensible way to express identities, capabilities, and compliance
     data across different systems.  Its use of DIDs and schema-governed
     claims ensures that Agents, MCP Clients, and MCP Servers can verify
     and exchange trust information, enabling consistent interoperability
     across domains and platforms.

     *(2) Flexible Definition of Claims:* VCDM 2.0 allows arbitrary,
     schema-governed claims that can represent complex concepts such as
     provenance, software supply-chain attestations (e.g., SLSA), security
     posture, audit certifications (SOC2, ISO-27001), or dynamic trust
     signals.  These claims can be extended without breaking
     interoperability, thanks to widely adopted JSON-LD and schema
     registries.

     *(3) Security and Privacy:* Credentials are signed using verifiable
     cryptographic proofs (e.g., JSON Web Signatures, Data Integrity
     proofs).  This ensures that Agents, MCP clients, and MCP servers can
     verify the authenticity of claims without relying solely on HTTPS
     endpoints or centralized registries.  Through techniques like BBS+
     signatures, holders can disclose only the subset of claims required
     for a given authorization flow.  This is essential for scenarios
     where Agents must prove capabilities (e.g., "I'm allowed to execute
     this skill") without revealing unnecessary or sensitive identity
     attributes.

     *(4) Compliance and Auditability:* VCDM 2.0 enables cryptographically
     verifiable audit trails by binding each credential to an issuer,
     timestamp, and revocation status.  Compliance attestations can be
     embedded directly in credentials, and real-time revocation checks
     ensure they remain valid.  This provides trustworthy provenance,
     regulatory-grade accountability, and reliable lifecycle tracking
     across distributed systems.

  6.4.1.  Delegation Semantics for Cross-Domain Multi-Agent Workflows

     Multi-agent systems frequently involve chains of delegation where
     Agent A invokes Agent B, which may invoke Agent C—potentially
     spanning multiple administrative domains.  This section defines
     authorization semantics for such delegation chains, addressing the
     novel challenges of cross-domain delegation.







  Diaconu, et al.          Expires 10 August 2026                [Page 13]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     Humans rarely delegate authority through multiple levels across
     organizational boundaries.  Agents routinely do so.  Existing
     delegation mechanisms ([RFC8693] Token Exchange 'act' claims) assume
     single-domain operation and do not address cross-domain VC-based
     delegation with verifiable accountability chains.

  6.4.1.1.  Delegation Models

     This specification supports two delegation models:

     Direct Invocation  Agent A directly invokes MCP Server M using A's
        own credentials.  No delegation occurs; authorization is based
        solely on A's VC.

     Delegated Invocation (Cross-Domain)  Agent A in Domain X invokes
        Agent B in Domain Y to perform a task.  B acts on A's behalf (and
        transitively, on behalf of A's originating principal) when
        accessing resources.  The authorization decision considers both
        A's delegation grant and B's own credentials, applying Domain Y's
        policies.

     Domain X                          |  Domain Y
                                       |
     +-----------+   +---------+       |  +---------+   +--------------+
     | Principal |   | Agent A |       |  | Agent B |   | MCP Server M |
     |     P     |   |         |       |  |         |   |              |
     +-----------+   +---------+       |  +---------+   +--------------+
           |              |            |       |               |
           | 1. Task      |            |       |               |
           |------------->|            |       |               |
           |              |            |       |               |
           |              | 2. Delegate + VC(A)|               |
           |              |------------|------>|               |
           |              |            |       |               |
           |              |            |       | 3. Request    |
           |              |            |       |    + VC(B)    |
           |              |            |       |    + Deleg(A) |
           |              |            |       |-------------->|
           |              |            |       |               |
           |              |            |       |  4. Verify chain
           |              |            |       |  5. Apply local policy
           |              |            |       |  6. Authorize

                     Figure 2: Cross-Domain Delegation Flow







  Diaconu, et al.          Expires 10 August 2026                [Page 14]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  6.4.1.2.  Scope Derivation Rules

     When Agent A delegates to Agent B (potentially across domains), B's
     effective scope MUST be computed as the intersection of:

     1.  A's delegatable scope: The subset of A's permissions that A is
         authorized to delegate

     2.  B's intrinsic scope: The permissions B holds in its own VC

     3.  Explicit delegation grant: What A actually delegated to B for
         this invocation

     4.  Receiving domain policy: The maximum scope the receiving domain
         permits for this cross-domain delegation

     Effective_Scope(B) = A.delegatable_scope
                          INTERSECT B.intrinsic_scope
                          INTERSECT Delegation.granted_scope
                          INTERSECT Receiving_Domain_Policy

                       Figure 3: Scope Derivation Formula

     This ensures:

     *  B cannot exceed A's authority (no privilege amplification)

     *  B cannot exceed its own authority (intrinsic limits apply)

     *  A can further restrict B for specific tasks (explicit grant)

     *  The receiving domain retains sovereignty over its resources (local
        policy)

     Implementations MUST enforce monotonic scope narrowing: at each
     delegation step, effective scope can only decrease or remain the
     same, never increase.

     This intersection semantics aligns with capability-based security
     principles (see: Mark Miller's Principle of Least Authority, Google
     Macaroons, Biscuit authorization tokens) and extends [RFC8693] Token
     Exchange delegation semantics to cross-domain VC-based scenarios.









  Diaconu, et al.          Expires 10 August 2026                [Page 15]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  6.4.1.3.  Accountability Chain Construction

     Each delegation step MUST produce a verifiable record enabling cross-
     domain forensic reconstruction.To support revocation and scope-change
     handling, delegation records SHOULD enable downstream verifiers to
     identify and validate upstream delegation elements so that
     authorization decisions do not depend on revoked or superseded
     delegation claims.  The delegation record MUST include:

      +==================+=================+===========================+
      | Field            | Description     | Cross-Domain Relevance    |
      +==================+=================+===========================+
      | delegator_id     | Agent A's id    | Enables tracing to        |
      |                  | from its VC     | originating domain        |
      +------------------+-----------------+---------------------------+
      | delegator_domain | Domain that     | Identifies trust          |
      |                  | issued A's VC   | relationship to verify    |
      +------------------+-----------------+---------------------------+
      | delegatee_id     | Agent B's id    | Identifies receiving      |
      |                  | from its VC     | agent                     |
      +------------------+-----------------+---------------------------+
      | delegatee_domain | Domain that     | Identifies receiving      |
      |                  | issued B's VC   | domain                    |
      +------------------+-----------------+---------------------------+
      | timestamp        | Time of         | Temporal ordering for     |
      |                  | delegation      | forensics                 |
      +------------------+-----------------+---------------------------+
      | granted_scope    | Scopes          | Audit of intended         |
      |                  | delegated       | authorization             |
      +------------------+-----------------+---------------------------+
      | expiration       | Delegation      | MUST NOT exceed           |
      |                  | validity period | delegator's VC expiration |
      +------------------+-----------------+---------------------------+
      | chain_hash       | Cryptographic   | Ensures chain integrity   |
      |                  | binding to      | across domains            |
      |                  | prior chain     |                           |
      +------------------+-----------------+---------------------------+

                      Table 5: Delegation Record Fields

     The complete accountability chain enables:

     1.  Cross-domain attribution: Determining which principal originated
         a request that traversed multiple domains

     2.  Forensic reconstruction: Rebuilding the sequence of delegations
         across domain boundaries




  Diaconu, et al.          Expires 10 August 2026                [Page 16]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     3.  Coordinated revocation: Identifying downstream delegations in
         other domains that must be invalidated

  6.4.1.4.  Delegation Depth Limits

     Implementations SHOULD enforce maximum delegation depth.  Cross-
     domain delegations SHOULD count toward depth limits regardless of
     whether they're same-domain or cross-domain.

     Receiving domains MAY impose stricter depth limits than the
     originating domain.  When a delegation would exceed the receiving
     domain's depth limit, the AS MUST reject the request with an error
     indicating the depth violation.

  6.4.1.5.  Delegation Claims in VCs

     To express delegation authority in VCs, the following claims are
     defined for credentialSubject:

     {
       "credentialSubject": {
         "id": "https://example.com/agents/agent-a",
         "delegation": {
           "permitted": true,
           "maxDepth": 2,
           "crossDomainDelegation": {
             "permitted": true,
             "allowedDomains": ["partner.example.org"],
             "deniedDomains": ["competitor.example.com"]
           },
           "allowedDelegateeTypes": ["tool-agent", "workflow-agent"],
           "scopeRestrictions": {
             "nonDelegatable": ["admin:*", "pii:write"],
             "crossDomainNonDelegatable": ["internal:*"]
           }
         }
       }
     }

                      Figure 4: Delegation Claims Example

     delegation.permitted  Boolean indicating whether this agent may
        delegate.  Default: false.

     delegation.maxDepth  Maximum additional delegation hops this agent
        may initiate.  Default: 0.

     delegation.crossDomainDelegation.permitted  Whether cross-domain



  Diaconu, et al.          Expires 10 August 2026                [Page 17]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


        delegation is allowed at all.

     delegation.crossDomainDelegation.allowedDomains  Domains to which
        delegation is permitted (wildcards allowed).

     delegation.scopeRestrictions.crossDomainNonDelegatable  Scopes that
        may be delegated within the same domain but MUST NOT be delegated
        across domain boundaries.

  6.4.2.  Agent Authorization Verifiable Credential Profile

     This section defines a Verifiable Credential profile that enables
     interoperable cross-domain agent authorization.  The profile
     specifies claims that Authorization Servers in different domains can
     reliably interpret.

     W3C VCDM 2.0 is intentionally flexible.  For cross-domain
     interoperability, domains must agree on claim semantics.  This
     profile provides that common language.

  6.4.2.1.  Profile Objectives

     The Agent Authorization VC Profile (AAVC) enables:

     *  Cross-domain interoperability: ASs in different domains can parse
        and evaluate the same VC

     *  Semantic clarity: Claim meanings are defined, reducing policy skew
        risk

     *  Extensibility: Organizations can add custom claims without
        breaking base interoperability

     *  Selective disclosure compatibility: Claims are structured to
        support SD-JWT VC presentation

  6.4.2.2.  Required Claims for Cross-Domain Interoperability

     The credentialSubject MUST include these claims for a VC to be
     recognized across domains:

     id (required)  Globally unique identifier for the agent.  SHOULD be a
        dereferenceable URI pointing to client-id metadata.

     agentType (required)  Classification of the agent.  Receiving domains
        use this to apply type-specific policies.  Implementations MUST
        support:




  Diaconu, et al.          Expires 10 August 2026                [Page 18]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


        *  tool-agent: Provides specific tool/skill capabilities

        *  orchestrator-agent: Coordinates other agents

        *  workflow-agent: Executes multi-step workflows

        *  system-agent: Long-running infrastructure agent

        *  ephemeral-agent: Short-lived, single-task

     authorizedScopes (required)  Authorization scopes this agent may
        request.  Receiving domains map these to local authorization
        policies.

     issuerDomain (required)  Administrative domain of the credential
        issuer.  Receiving ASs use this to look up trust relationships and
        policy mappings.

  6.4.2.3.  Recommended Claims for Production Deployments

     dataSensitivityClearance (recommended)  Maximum data sensitivity
        level this agent may access.  Standard values:

        *  public - Publicly available information

        *  internal - Organization-internal, non-sensitive

        *  confidential - Business-sensitive information

        *  restricted - Highly sensitive, need-to-know basis

        *  regulated - Subject to regulatory controls (PII, PHI, PCI)

     complianceAttestations (recommended)  Compliance certifications
        relevant to cross-domain trust decisions.  Should include
        standard, scope, validUntil, and optionally certificationBody.

     operationalConstraints (recommended)  Runtime constraints that
        receiving domains MAY enforce, including maxConcurrentSessions,
        maxRequestsPerMinute, allowedTimeWindows, and geofence
        restrictions.

     delegation (recommended)  Delegation permissions as defined in
        Section 6.4.1.5.







  Diaconu, et al.          Expires 10 August 2026                [Page 19]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  6.4.2.4.  Extension Mechanism

     Organizations MAY extend the profile with additional claims by:

     1.  Defining a JSON-LD context document for the extension

     2.  Including the extension context URI in the VC's @context array

     3.  Adding extension claims under a namespace prefix

     Implementations receiving VCs with unrecognized claims SHOULD:

     *  Ignore unknown claims (do not reject the VC)

     *  Log unrecognized claims for operational visibility

     *  NOT make authorization decisions based on claims they cannot
        interpret

  6.4.2.5.  Interoperability Requirements

     For cross-domain interoperability, implementations:

     MUST:

     *  Support required claims (id, agentType, authorizedScopes,
        issuerDomain)

     *  Recognize the AgentAuthorizationCredential type

     *  Verify the credential proof before processing claims

     *  Reject VCs missing required claims

     SHOULD:

     *  Support recommended claims

     *  Implement selective disclosure for cross-domain presentations

     *  Maintain logs of cross-domain VC presentations

     MAY:

     *  Define and process organization-specific extensions

     *  Implement additional validation beyond profile requirements




  Diaconu, et al.          Expires 10 August 2026                [Page 20]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  7.  Example

     This section provides illustrative examples of how Client-ID Metadata
     can be extended with Verifiable Credentials for agent identity.
     These examples demonstrate the recommended Approach 4 and show how
     the concepts apply to scenarios similar to the travel booking use
     case described earlier.  These examples are non-normative and
     intended to demonstrate the concepts discussed in this document.

  7.1.  Client-ID Metadata Example

     The following example shows OAuth client metadata that includes a
     Verifiable Credential in the "vc+jwt" field:

     {
       "client_id": "https://agents.example.com/agent-001/metadata.json",
       "client_name": "Customer Service Agent 001",
       "jwks_uri": "https://agents.example.com/agent-001/jwks.json",
       "token_endpoint_auth_method": "private_key_jwt",
       "grant_types": ["client_credentials"],
       "scope": "read:orders write:tickets",
       "vc+jwt": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJAY29udGV4dCI6W..."
     }

     The "vc+jwt" field contains a JWT-encoded Verifiable Credential.  The
     actual JWT would be significantly longer and contain the complete
     credential structure shown in the next subsection.

  7.2.  Verifiable Credential Example

     The following example shows the decoded structure of a Verifiable
     Credential for an agent (before JWT encoding):

     {
       "@context": [
         "https://www.w3.org/2018/credentials/v1",
         "https://example.org/agent-credentials/v1"
       ],
       "type": ["VerifiableCredential", "AgentIdentityCredential"],
       "issuer": "did:web:issuer.example.com",
       "issuanceDate": "2025-01-15T10:30:00Z",
       "expirationDate": "2026-01-15T10:30:00Z",
       "credentialSubject": {
         "id": "https://agents.example.com/agent-001/metadata.json",
         "agentName": "Customer Service Agent 001",
         "agentVersion": "2.1.0",
         "agentType": "customer-service",
         "owner": "did:web:example.com",



  Diaconu, et al.          Expires 10 August 2026                [Page 21]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


         "authorizedCapabilities": [
           "order-lookup",
           "ticket-creation",
           "customer-notification"
         ],
         "delegatedCredentials":[
           {
             "id": "https://agents.partner.com/agent-111/metadata.json",
             "agentName":"Sec Agent 111",
             "delegatedBy":"https://agents.example.com/agent-001/metadata.json",
             "delegationChain": [
                     "urn:uuid:*****",
                     "urn:uuid:***"
             ],
             "scope": "read:sec-remediate:isolations",
             "authorizedCapabilities": [
                     "enrichment",
                     "isolation-request"
             ],
         "constraints": {
           "dpopNonceRequired": true
             }
           }
         ],
         "complianceFrameworks": ["SOC2-TypeII", "ISO-27001"],
         "delegationLevel": 1,
         "maxDelegationDepth": 2
       },
       "credentialStatus": {
         "id": "https://issuer.example.com/status/2024/12345",
         "type": "StatusList2021Entry",
         "statusPurpose": "revocation",
         "statusListIndex": "12345",
         "statusListCredential": "https://issuer.example.com/status/2024"
       }
     }

     Note: The actual credential would include a "proof" section with
     cryptographic signatures.  The proof section is omitted here for
     clarity, as it would add significant length to the example.  The
     proof structure varies depending on the signature suite used (e.g.,
     Ed25519Signature2020, JsonWebSignature2020).

  8.  Security Considerations







  Diaconu, et al.          Expires 10 August 2026                [Page 22]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  8.1.  Security Considerations

     This section addresses security considerations specific to cross-
     domain authorization information sharing.  Implementations MUST also
     follow security guidance in [RFC6819], [W3C.VCDM2.0], and
     [I-D.ietf-oauth-client-id-metadata-document].

  8.1.1.  Threat Model for Cross-Domain Authorization Sharing

     This section defines threats specific to sharing authorization
     information across administrative domain boundaries.  General OAuth
     and VC security threats are addressed in [RFC6819] and [W3C.VCDM2.0];
     this section focuses on threats that emerge or are amplified when
     credentials cross domain boundaries.

  8.1.1.1.  Protected Assets in Cross-Domain Scenarios

     Beyond standard authorization assets, cross-domain sharing introduces
     additional assets requiring protection:

     Cross-Domain Trust Relationships  The established trust between
        domains that enables agents to operate across organizational
        boundaries.  Compromise affects all agents relying on that trust
        relationship.

     Shared Authorization Semantics  The agreed-upon meaning of claims,
        scopes, and compliance attestations between domains.  Semantic
        drift or manipulation can cause authorization decisions that
        violate one or both domains' policies.

     Delegation Chains Spanning Domains  When agent A in Domain X
        delegates to agent B in Domain Y, the chain itself becomes an
        asset requiring integrity protection across trust boundaries.

  8.1.1.2.  Cross-Domain Specific Threat Actors

     Rogue Domain  An entire domain that participates in the trust
        federation but issues fraudulent VCs or makes incorrect
        authorization decisions—either through compromise or malicious
        operation.  Unlike a single rogue IdP, a rogue domain may control
        IdP, AS, and metadata endpoints coherently.

     Cross-Domain Insider  An administrator with legitimate access in
        Domain A who abuses cross-domain trust relationships to gain
        unauthorized access to Domain B's resources.

  8.1.1.3.  Cross-Domain Attack Categories




  Diaconu, et al.          Expires 10 August 2026                [Page 23]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  8.1.1.3.1.  Trust Anchor Attacks

     Metadata Endpoint Compromise  An attacker gains control of the URL
        hosting an agent's client-id metadata document and substitutes
        malicious metadata or VCs.  Because the metadata URL is the trust
        anchor for cross-domain identity, compromise enables complete
        identity takeover across all trusting domains.

        Cross-domain amplification: In single-domain scenarios, the AS
        typically has out-of-band trust with clients.  In cross-domain
        scenarios, the metadata endpoint IS the sole trust anchor—there's
        no fallback.

     Metadata Poisoning  Injection of false claims into legitimate
        metadata documents through supply chain attacks, DNS hijacking, or
        exploitation of hosting infrastructure.

        Cross-domain amplification: Poisoned metadata propagates trust
        violations to all domains that fetch and cache the metadata.

  8.1.1.3.2.  Semantic Attacks

     Policy Skew Exploitation  An agent authorized under Domain A's
        policies operates in Domain B where different security policies
        apply.  The agent performs actions that are within Domain A's
        authorized scope but violate Domain B's policies.

     Claim Semantic Drift  Domains interpret the same claim differently,
        leading to authorization decisions that neither domain intended.

     Compliance Attestation Mismatch  Compliance attestations (SOC2, ISO-
        27001, GDPR) in VCs are accepted at face value without verifying
        that the issuing domain's certification scope covers the receiving
        domain's requirements.

  8.1.1.3.3.  Delegation Attacks Across Domains

     Cross-Domain Privilege Amplification  In multi-hop delegation (A to B
        to C) where agents belong to different domains, downstream agents
        in permissive domains accumulate effective permissions that exceed
        what the originating principal intended.

     Accountability Chain Breakage  Delegation chains that cross domain
        boundaries lose forensic continuity.  When incidents occur,
        attribution cannot be reconstructed because each domain only has
        partial visibility.

     Confused Deputy Across Trust Boundaries  An attacker in Domain A



  Diaconu, et al.          Expires 10 August 2026                [Page 24]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


        tricks a trusted agent in Domain B into performing actions on
        their behalf that the attacker couldn't perform
        directly—exploiting the cross-domain trust relationship.  See
        [Hardy1988].

  8.1.1.3.4.  Cross-Domain Lateral Movement

     Using legitimate cross-domain authorization to pivot from a
     compromised position in Domain A to resources in Domain B that would
     not otherwise be accessible.  An attacker compromises a low-privilege
     agent in Domain A.  That agent has cross-domain authorization to
     Domain B.  The attacker uses the agent's credentials to establish a
     foothold in Domain B, then escalates within Domain B.

  8.1.1.3.5.  Correlation and Privacy Attacks

     Linking agent activities across domains using stable identifiers in
     VCs to build profiles of organizational operations, potentially
     revealing sensitive business processes or security postures.

     Cross-domain amplification: In single-domain scenarios, the domain
     controls what's logged.  In cross-domain scenarios, each domain
     receiving the VC can correlate independently, and the agent's home
     domain cannot prevent this.

  8.1.1.4.  Trust Establishment Between Domains

  8.1.1.4.1.  Domain Trust Lists

     Before accepting VCs from another domain, an Authorization Server
     MUST verify that the issuing domain is in an explicitly configured
     trust list.  Implementations MUST NOT implicitly trust domains based
     solely on successful cryptographic verification of the VC.

     Trust list entries SHOULD include:

     *  Domain identifier (issuerDomain claim value)

     *  Accepted VC types from that domain

     *  Scope of trust (which local resources may be accessed)

     *  Expiration or review date for the trust relationship








  Diaconu, et al.          Expires 10 August 2026                [Page 25]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


  8.1.1.4.2.  Cross-Domain Policy Mapping

     Implementations MUST NOT assume semantic equivalence of claims across
     domains.  Before accepting a VC from another domain, the AS SHOULD
     verify:

     1.  Explicit mapping exists between the foreign domain's claim
         semantics and local policy requirements

     2.  Compliance attestations in the VC meet local regulatory
         requirements (not just the issuing domain's)

     3.  Scope values have been mapped to local authorization semantics

  8.1.1.4.3.  Trust Relationship Lifecycle

     Cross-domain trust relationships MUST have defined lifecycles:

     *  Periodic review and re-validation

     *  Documented procedures for trust relationship termination

     *  Immediate revocation capability when a trusted domain is
        compromised

     *  Notification mechanisms between domains for security events

  8.1.1.5.  Metadata Endpoint Security for Cross-Domain Trust

     Because the client-id metadata endpoint is the sole trust anchor for
     cross-domain agent identity, it requires enhanced protection beyond
     typical endpoint security.

  8.1.1.5.1.  Endpoint Integrity Beyond Transport

     Metadata documents SHOULD be signed independently of the transport
     layer, allowing verification even if TLS is compromised or if the
     document is cached by intermediaries.

  8.1.1.5.2.  Change Detection for Cached Metadata

     Authorization Servers SHOULD:

     *  Cache fetched metadata documents with appropriate TTLs

     *  Detect and alert on unexpected changes to critical fields
        (jwks_uri, vc+jwt, token_endpoint_auth_method)




  Diaconu, et al.          Expires 10 August 2026                [Page 26]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     *  Implement anomaly detection for metadata that changes more
        frequently than expected

  8.1.1.5.3.  Cross-Domain Availability Dependencies

     When metadata endpoints are unavailable, cross-domain authorization
     fails.  Implementations SHOULD:

     *  Cache validated metadata with TTLs appropriate to the sensitivity
        of protected resources

     *  Implement circuit breakers to prevent cascading failures

     *  Define graceful degradation policies

  8.1.1.6.  Delegation Security Across Domain Boundaries

  8.1.1.6.1.  Domain Boundary Checkpoints

     When a delegation chain crosses a domain boundary, the receiving
     domain's AS MUST:

     *  Fully verify the upstream delegation chain before accepting

     *  Apply local policy to the delegation

     *  Log the domain boundary crossing for audit purposes

     Receiving domains SHOULD consider the status of delegated credentials
     and, where status information is available, avoid making
     authorization decisions that rely on revoked,suspended, or suspended
     delegation chain elements, according to local policy.

     Deployments concerned with stale delgations MAY apply bounded caching
     and periodic revalidation of delegation status appropriate to the
     sensitivity of protected resources.

  8.1.1.6.2.  Monotonic Scope Narrowing Across Domains

     Implementations MUST enforce that effective scope can only decrease
     (or remain the same) at each delegation step, including when crossing
     domain boundaries.  The receiving domain MUST apply its local policy
     as an additional constraint on effective scope.

  8.1.1.6.3.  Accountability Chain Preservation

     Delegation chains spanning domains MUST maintain cryptographically
     verifiable accountability.  Each domain SHOULD:



  Diaconu, et al.          Expires 10 August 2026                [Page 27]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     *  Preserve the incoming delegation chain in its audit logs

     *  Add its own delegation record when extending the chain

     *  Provide APIs for authorized forensic queries from upstream domains

  8.1.1.7.  Privacy Considerations for Cross-Domain Sharing

  8.1.1.7.1.  Selective Disclosure for Cross-Domain Presentations

     Agents presenting VCs across domain boundaries SHOULD use selective
     disclosure mechanisms (SD-JWT VC, BBS+ signatures) to reveal only
     claims necessary for the specific cross-domain authorization request.

  8.1.1.7.2.  Correlation Risk Assessment

     Organizations SHOULD assess cross-domain correlation risks before
     establishing trust relationships, including whether agent identifiers
     enable activity tracking by foreign domains.

  9.  IANA Considerations

     This document introduces a new OAuth client metadata parameter
     "vc+jwt" as described in the Solution Analysis section (Approach 4).
     If this approach is standardized, the following registration would be
     required:

     *  *Registry:* IANA [`OAuth Dynamic Client Registration
        Metadata`](https://www.iana.org/assignments/oauth-parameters/
        oauth-parameters.xhtml#client-metadata) registry

     *  *Client Metadata Name:* vc+jwt

     *  *Client Metadata Description:* JWT-encoded Verifiable Credential

     *  *Change Controller:* TBD

     *  *Reference:* https://www.w3.org/TR/vc-data-model-2.0

     This informational document does not make a formal request for IANA
     registration at this time.  Registration would be appropriate if this
     approach is adopted and progresses to a standards track
     specification.

  10.  References

  10.1.  Informative References




  Diaconu, et al.          Expires 10 August 2026                [Page 28]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
                P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
                July 2015, <https://www.rfc-editor.org/info/rfc7591>.

     [I-D.abbey-scim-agent-extension]
                Abbey, J., "SCIM Extensions for Agents", 2025.

     [I-D.wahl-scim-agent-schema]
                Wahl, M., "SCIM Schema for Agents", 2025.

     [I-D.ietf-oauth-client-id-metadata-document]
                Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Client
                Identity Metadata Document", 2025.

     [W3C.VCDM2.0]
                W3C, "Verifiable Credentials Data Model v2.0", 2024,
                <https://www.w3.org/TR/vc-data-model-2.0/>.

     [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
                Threat Model and Security Considerations", January 2013,
                <https://www.rfc-editor.org/info/rfc6819>.

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

     [Hardy1988]
                Hardy, N., "The Confused Deputy: (or why capabilities
                might have been invented)", ACM SIGOPS Operating Systems
                Review Volume 22, Issue 4, 1988.

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

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

  Authors' Addresses

     Jean Diaconu
     Cisco Systems, Inc.
     Av. des Uttins 5
     CH-1180 ROLLE
     Switzerland
     Email: jdiaconu@cisco.com




  Diaconu, et al.          Expires 10 August 2026                [Page 29]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     Marcelo Yannuzzi
     Cisco Systems, Inc.
     Av. des Uttins 5
     CH-1180 ROLLE
     Switzerland
     Email: mayannuz@cisco.com


     Herve Muyal
     Cisco Systems, Inc.
     Av. des Uttins 5
     CH-1180 ROLLE
     Switzerland
     Email: hmuyal@cisco.com


     Frank Brockners
     Cisco Systems, Inc.
     Hansaallee 249, 3rd Floor
     40549 DUESSELDORF
     Germany
     Email: fbrockne@cisco.com


     Nik Kale
     Cisco Systems, Inc.
     170 W Tasman Dr
     SAN JOSE, CA,  95134
     United States of America
     Email: nikkal@cisco.com


     Ankit Agarwal
     Skyfire, Inc.
     Kentfield, CA,
     United States of America
     Email: ankit@skyfire.xyz


     Jeffrey Hickman
     Ory Corp, Inc.
     15169 N Scottsdale Rd Suite 205
     Scottsdale, AZ,  85254
     United States of America
     Email: jeff.hickman@ory.com






  Diaconu, et al.          Expires 10 August 2026                [Page 30]


  Internet-Draft          AuthZ Sharing for Agents           February 2026


     Amritha Lal
     Amazon Web Services
     Seattle, WA,
     United States of America
     Email: amrithak@amazon.com














































  Diaconu, et al.          Expires 10 August 2026                [Page 31]


