]> Huawei

liuchunchi@huawei.com

Huawei

niyuan1@huawei.com

Transaction Tokens Agent to Agent 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.

Introduction The OAuth Transaction Tokens specification 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 , 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.

Terminology This document uses terms from both the OAuth Transaction Tokens and Agent-to-Agent specifications.

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

Transaction Token Request In , 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.
  • This data field carry the original A2A request call from the user, which MUST NOT change throughout the whole call chain.
  • This will encapsulate the "User Input" in the "Message" struct from the A2A Protocol.
• request_context OPTIONAL. This parameter contains a base64url encoded JSON object which represents the context of this transaction.
  • This data field carry appended observations/contexts/decisions that can be changed by each hop of AI Agent.
  • This will encapsulate all other fields in the "Message" struct from the A2A Protocol, such as "Agent Thinking", "Status Updates", "Metadata"...

Transaction Token Claims

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

Security Considerations This document has no further security considerations.

IANA Considerations This document has no IANA actions.

Informative References SGNL Practical Identity LLC SPIRL Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity and authorization context across workloads within a trusted domain during the processing of external programmatic requests, such as API calls. They ensure that this context is preserved throughout the call chain, even when new transactions are initiated internally, thereby enhancing security and consistency in complex, multi-service architectures.