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:". 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 { "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:") 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 { "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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, . [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, . 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, . [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, . [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, . [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, . [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, . [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, . [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, . 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, . 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", . [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [IANA.JWT.Claims] IANA, "JSON Web Token Claims", . [IANA.Extensions.Error] IANA, "JSON Web Token Claims", . 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]