| Internet-Draft | oauth-a2a-profile | October 2025 |
| Liu & Ni | Expires 23 April 2026 | [Page] |
This document defines a profile for using OAuth Transaction Tokens in Agent-to-Agent (A2A) communication scenarios. The profile specifies how A2A call chain context can be embedded within Transaction Tokens to maintain agent identity, authorization context, and execution flow across distributed agent workloads within trusted domains.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2026.¶
Copyright (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.¶
The OAuth Transaction Tokens specification [I-D.ietf-oauth-transaction-tokens] provides a mechanism for propagating user identity and authorization context across workloads during the processing of programmatic requests. This capability aligns naturally with the requirements of Agent-to-Agent (A2A) communication systems [A2A-SPEC], where autonomous agents coordinate through call chains while maintaining security of the call context.¶
This document explores the relationship between these two specifications and proposes a profile that enables Transaction Tokens to carry A2A-specific context information.¶
This document uses terms from both the OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens] and Agent-to-Agent [A2A-SPEC] specifications.¶
A2A systems involve complex call chains where autonomous agents invoke other agents to accomplish tasks. These call chains require:¶
Preservation of original requestor identity and original authorization context¶
Propagation of execution context across agent boundaries¶
Auditability and traceability of the entire call chain¶
Security boundaries between different agent capabilities¶
The Transaction Token framework addresses similar concerns for API/workload call chains within trusted domains. Transaction Tokens are short-lived, signed JWTs that assert the identity of a user or a workload and assert an authorization context. There are many benefits if A2A calls are carried by Transaction Tokens:¶
Preserved Call Context and Identity: Transaction tokens are signed JWTs, providing immutable information about the user or workload, certain parameters of the call, and specific contextual attributes of the call. Agentic systems execute multi-step, cross-domain actions where conversational state can sometimes drift from the originally authorized intent, creating "context rot" that undermines least-privilege guarantees and auditability. The use of transaction tokens can preserve the original call context and prevent "context rot".¶
Decreased Scope and Purpose: Transaction tokens enforce that the requested scope and purpose of a transaction are equal to or less than those of the subject token. Agentic systems often divide the main tasks into a sequence of multiple sub-tasks. This mechanism allows for granular permission models that minimize risks associated with overreach and excessive user privacy exposure.¶
Ephemerality: Agentic systems frequently spawn short‑lived, task‑triggered workflows. Transaction Tokens are expected to be short-lived (minutes). The adoption reduces reliance on long‑lived credentials and limits replay and lateral use.¶
In [I-D.ietf-oauth-transaction-tokens], Txn-Token Request defined a set of parameters, in which the following can be used for profiling.¶
subject_token REQUIRED. The value MUST represent the subject of the transaction.¶
This data field carry the orginal OAuth access token issued by the user. It SHOULD be signed by the original user.¶
request_details OPTIONAL. This parameter contains a base64url encoded JSON object which represents additional details of the transaction that MUST remain immutable throughout the processing of the transaction by multiple workloads. The Transaction Token Service uses this information to construct the tctx claim.¶
request_context OPTIONAL. This parameter contains a base64url encoded JSON object which represents the context of this transaction.¶
purp: REQUIRED A String defining the purpose or intent of this transaction. The purp claim captures the exact purpose of this particular transaction.¶
In the A2A profile, this claim will be a String "a2a.Task.id" from the A2A Protocol, as an unique identifier for the task.¶
tctx: OPTIONAL A JSON object that contains values that remain immutable throughout the call chain. The value of this claim is a JSON object that contains name/value pairs (wherein the value could itself be an object), which together assert the details that remain immutable through the call-chain where this Txn-Token is used.¶
This claim will contain the exact contents in the "request_details" of the transaction token request, which will be the "User Input" in the "Message" struct from the A2A Protocol.¶
rctx: OPTIONAL A JSON object that describes the environmental context of the requested transaction.¶
This claim will contain the exact contents in the "request_context" of the transaction token request, which will be all other fields in the "Message" struct from the A2A Protocol, such as "Agent Thinking", "Status Updates", "Metadata"...¶
This document has no further security considerations.¶
This document has no IANA actions.¶