]> Nokia

k.tirumaleswar_reddy@nokia.com

Nokia

Sweden zaheduzzaman.sarker@nokia.com

Applications and Real-Time Workload Identity in Multi System Environments agent dialog WIMSE transaction token AI agents and tools that take part in a dialog carry a dialog context with each request and response. This document specifies how the dialog context is bound to WIMSE and OAuth credentials. It extends the WIMSE profile of HTTP Message Signatures, for requests and responses, and the WIMSE Proof Token, for requests, to cover the dialog context, records the dialog identifier in OAuth transaction tokens, and describes how a new dialog at a trust boundary aligns with OAuth identity chaining. A receiver can then verify who sent a request or response, which dialog it belongs to, and, for a request, what it may do, and that the answers agree.

Introduction The use cases and requirements for agent dialogs describe how users, agents, and tools interact over the course of a task, in a dialog. Among them, a receiver needs to verify who sent a request or response, who initiated the dialog, and that no hop altered the dialog context it carries. Authorization granted in one dialog also needs to be limited to that dialog. These requirements lead to an agent communication architecture , an agent communication protocol, and security mechanisms such as those in this document. This document meets them with existing WIMSE and OAuth credentials: the WIMSE HTTP signature or WPT covers the dialog context, and the transaction token records the dialog identifier. A participant can initiate a linked dialog within a trust domain. At a trust boundary, it always initiates one, and authorization moves to the other domain through identity chaining. An agent communication protocol carries a dialog context with each request and response, which identifies the dialog and the participant that initiated it. This document uses Dialog-Context as a placeholder name for the HTTP field that carries the dialog context. Its name and format will be aligned with the agent communication protocol once that protocol is defined. The goal of this document is to show how the dialog context is bound to WIMSE and OAuth credentials, not to define the dialog context itself. The agent communication protocol defines no credentials, signatures, or authorization model of its own. It relies on WIMSE for workload identity and message integrity , and on OAuth for authorization. The WIMSE framework for AI agents composes these for agent authentication and authorization. Today none of these mechanisms covers the dialog context:

• A WIMSE HTTP signature or WIMSE Proof Token (WPT) does not cover the Dialog-Context field. A hop can change the dialog context without breaking the proof.
• A transaction token does not record the dialog. A token obtained in one dialog can be presented in another.

TLS protects each hop between adjacent endpoints . Where two participants connect directly with mutual TLS, TLS already authenticates the peer and protects the messages on that hop. An application-layer proof, made with the sender's WIT key over the message, adds two properties:

Protection across intermediaries:

The receiver verifies the proof itself, even when an intermediary on the path, such as a gateway, terminates TLS. It learns which workload sent the message, not only which intermediary it connected to.

Provenance:

Each hop that forwards a request or response adds its proof, starting with the initiator, and the proofs travel together with the message. A receiver several hops away can then verify which participant initiated the dialog, and that no hop altered the dialog context.

Provenance matters for agents because a request or response can pass through several agents before it reaches its destination. For example, A1 initiates a dialog with A2, and A2 sends a new request to a tool. TLS and A2's proof show the tool only that A2 sent the request, not that A1 initiated the dialog. The proofs of earlier hops show that (). This document closes both gaps. A receiver can then answer three questions about a request from three independent sources, and check that the answers agree:

• Who sent it: the WIMSE proof.
• What it may do: the transaction token.
• Which dialog it belongs to: the dialog context, covered by the WIMSE proof and recorded in the transaction token.

Transaction tokens are optional. Without them, the WIMSE proof still binds the dialog context to the request and its sender.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms:

• Workload Identity Token (WIT), defined in .
• WIMSE Proof Token (WPT), defined in .
• Transaction Token and Transaction Token Service (TTS), defined in .
• Dialog and Dialog Context, defined in .
• Dialog Identifier, defined in as the Agentic Dialog Identifier (ADID).

It also defines the following terms:

Participant:

An agent or tool that takes part in a dialog. Each participant is a workload with its own WIT.

Initiator:

The participant that proposes the dialog context in the request that establishes the dialog. It is the principal of the dialog . The dialog context identifies it by its WIMSE workload identifier.

Linked Dialog:

A new dialog, with a new dialog context, that a participant initiates to continue a dialog it received.

This document applies to participants that are WIMSE workloads. How a client without a WIT, such as a user application, is identified in the dialog context is left to the agent communication protocol.

Security Architecture

Security architecture

The figure shows three bindings:

1. The signature or WPT covers the dialog context.
2. The transaction token records the same dialog identifier as the dialog context.
3. The signature or WPT covers the transaction token.

The agent communication protocol defines no credentials or signatures of its own. It reuses WIMSE for workload identity and message integrity, and OAuth for authorization. Each answers a different question about a request: the WIMSE HTTP signature or WPT says who sent it, the transaction token says what it may do, and the dialog context says which dialog it belongs to. Each participant holds a WIT issued by its domain's WIT issuer. Each hop proves possession of its WIT key for the message it sends, using either the WIMSE HTTP signature , for requests and responses, or the WPT , for requests only. Because the signature or WPT covers the dialog context, a receiver can verify that the dialog context it received is the one the sender signed, and that it was not changed in transit. The dialog context therefore needs no signature of its own. Both proofs protect a single hop. For a receiver to verify which participant initiated the dialog, the proofs of earlier hops need to travel with the message (). Where a deployment uses transaction tokens, the Transaction Token Service records the dialog identifier in the token. Participants forward the token within the trust domain, and a receiver rejects a token issued for another dialog. At a trust boundary, a participant initiates a linked dialog, and authorization moves to the other domain through identity chaining . Neither the dialog identifier nor the transaction token of the original domain crosses the boundary.

Assumed Dialog Context Content This document relies on the following information in the dialog context. The agent communication protocol defines the encoding and any further content.

Dialog identifier (dlg):

Identifies the dialog. The initiator proposes it, and the server that creates the dialog accepts it. The transaction token records it in tctx.dlg ().

Initiator:

The WIMSE workload identifier of the participant that initiated the dialog. A receiver checks that the first proof in the chain was made by this workload ().

The agent communication protocol will add more meta-data to the dialog context. The WIMSE proof covers the whole Dialog-Context field, so it also covers any meta-data added in the base spec and future extensions. The dialog context does not carry credentials or tokens, which travel in their own fields, nor the context an agent builds over the dialog. Each participant knows only the hops it exchanges messages with; the dialog context does not list participants.

Dialog Establishment The initiator proposes a dialog context in its first request: a Dialog-Context field with a new dialog identifier and the initiator's WIMSE workload identifier, covered by the initiator's WIMSE proof. The server checks that the initiator named in the field equals the sub claim of the WIT used to verify the proof, and that the dialog identifier is not already in use. It then creates the dialog, or rejects the request. When it creates the dialog, the server returns the accepted dialog context in its response, and the initiator checks that it matches the proposed one. With the WIMSE HTTP signature, the server signs the response, and the signature covers Dialog-Context (). The WPT defines no response proof, so with the WPT the response is not authenticated. The request can carry the first input of the dialog, so establishing a dialog adds no round trip. The initiator proposes the dialog context so that its own proof covers it from the first request, and a receiver several hops away can verify that the initiator started the dialog (). The server still decides whether to create the dialog, and maintains its state. A participant that maintains no dialog state, such as a stateless tool, creates no dialog. It receives the dialog context of the caller with each request.

Overview shows the agents in the example. All three are in domain A. Agent A1 initiates dialog D1 with agent A2 () and delegates a task to A2, which calls a tool in D1.

Agents in the example | A2 |-------------+ | | +--------+ +--------+ | | | (initiator) v | | +------+ | | | Tool | | | +------+ | +--------------------------------------------------------+ ]]>

shows the request from A2 to the tool.

A request bound to its dialog Content-Digest: sha-256=:: Workload-Identity-Token: Signature-Input: wimse=("@method" "@path" "dialog-context" "txn-token" "content-digest" "workload-identity-token");... Signature: wimse=:: ]]>

Values are shown informally. The Dialog-Context syntax is a placeholder (). The Signature-Input field lists what the signature covers: the method, the path, the dialog context, the transaction token, the body digest, and A2's WIT. The tool verifies the WIMSE proof with A2's WIT. The proof covers the Dialog-Context field, so the dialog context has not changed on this hop. The tool validates the transaction token and checks that its dialog identifier equals the one in Dialog-Context. A token issued for another dialog fails this check. The proof of a single hop shows who sent the request. It does not show who initiated the dialog when the sender is not the initiator. Verifying the initiator at a later hop requires the proofs of earlier hops, as described in .

Dialog Context in WIMSE HTTP Signatures When a request carries the Dialog-Context field, the WIMSE HTTP signature of the request , a profile of HTTP Message Signatures , MUST include dialog-context in its covered components. This adds Dialog-Context to the fields that the profile requires to be covered when present. When a response carries the Dialog-Context field and is signed, the signature of the response MUST include dialog-context in its covered components. The response signature also covers the method, path, and nonce of the request it answers , so it cannot be moved to another request. The requester MUST verify that the Dialog-Context value in the response matches the one in its request. A receiver MUST reject a request that carries Dialog-Context and a WIMSE HTTP signature that does not cover it. A participant that forwards a request in the same dialog MUST NOT change the Dialog-Context field, so that the proofs of earlier hops verify against it (). A repeated or malformed Dialog-Context field is handled as specified for covered fields in and .

Dialog Context in the WIMSE Proof Token This document defines the following claim for the WPT:

dth:

The hash of the Dialog-Context field value, computed as specified for the oth claim . It is REQUIRED when the request carries the Dialog-Context field.

The WPT is signed with the sender's WIT key, and the signature covers the dth claim. The dialog context is therefore part of what the sender signs. When a request carries both a WPT and the Dialog-Context field, the receiver verifies the WPT signature and checks that dth matches the hash of the Dialog-Context field in the request. If the signature does not verify, dth is missing, or the hash does not match, the receiver MUST reject the request.

Multi-hop Provenance A WIMSE HTTP signature and a WPT each protect a single hop. A receiver verifies the hop that sent the message. To verify which participant initiated the dialog, and that no earlier hop altered the dialog context, the receiver needs the proof of the initiator and of each participant that forwarded the message. specifies how the WIMSE HTTP signatures of earlier hops travel with a message, and how they can be aggregated into one signature as an optimization. Each of those signatures covers the same Dialog-Context value, so a change by any hop breaks the chain. Without the proofs of earlier hops, a receiver verifies only the participant that sent the message. If that participant is not the initiator, the receiver cannot tell whether the dialog context it received is the one the initiator used. For example, the tool in can verify that A2 sent D1, but not that A1 initiated D1. A transaction token, if used, does not help here: it shows that the request is authorized for dialog D1, not who initiated D1.

Dialog Identifier in Transaction Tokens This section applies to deployments that use transaction tokens.

The dlg Member of tctx This document defines the following member of the tctx claim of a transaction token:

dlg:

The dialog identifier of the dialog in which the transaction token is used, as carried in the dlg field of the dialog context. String.

The dialog identifier is part of the authorization context, and stays unchanged for the life of the transaction. The transaction token records only the dialog identifier, because it stays the same for the life of the dialog. The rest of the dialog context, such as its state, can change, and the WIMSE proof protects it instead.

Transaction token recording the dialog

Requesting the Token To get a transaction token for a dialog, a participant includes the dialog identifier as a dlg member of the request_details parameter of its token exchange request . The TTS checks the request against its local policy. If the check succeeds, the TTS issues a transaction token with the dialog identifier in tctx.dlg.

Forwarding Participants forward the transaction token down the call chain together with the dialog context. They do not forward access tokens . A transaction token does not leave its trust domain. A transaction token is short-lived, which limits how long a stale authorization can be used. Revocation within that lifetime is signaled through Shared Signals ().

Receiver Check A receiver of a request that carries both a transaction token and a Dialog-Context field MUST check that tctx.dlg equals the dlg field of the dialog context, and MUST reject the request if it does not. A receiver MUST reject a request that carries Dialog-Context and a transaction token without tctx.dlg, or a transaction token with tctx.dlg and no Dialog-Context field.

Trust Boundaries and Identity Chaining A participant can initiate a linked dialog within a trust domain, where local policy calls for it, and always initiates one at a trust boundary, since a dialog does not cross a trust boundary. At the boundary, authorization moves to the other domain through identity chaining , so the dialog and the authorization reset at the same point. In , A1 initiates dialog D1 with A2 and sends a request in D1 (step 0, ). A2 holds a domain A transaction token that records D1.

Linked dialog D2 at the domain boundary | | : | | | | | | : | | | | | (1) txn token (D1) | : | | | | |------------------->| : | | | | | JWT grant | : | | | | |<-------------------| : | | | | | | : | | | | | (2) JWT grant | : | | | | |----------------------------->| | | | | access token | : | | | | |<-----------------------------| | | | | | : | | | | | (3) request, access token, | | | | | Dialog-Context: D2 : | | | | |------------------------------------------>| | | | | : | [B1 creates D2] | | | | : | | | | | | : | | (4) access | | | | : | | token (D2) | | | | : | |------------>| | | | : | | txn token, | | | | : | | tctx.dlg=D2 | | | | : | |<------------| ]]>

1. A2 needs to call B1 in domain B. A dialog does not cross a trust boundary, so A2 initiates a linked dialog D2 with B1. A2 sends its transaction token, which records D1, to the authorization server of domain A (AS A) and asks for a JWT authorization grant for domain B. If the transaction token is valid, AS A issues the grant.
2. A2 sends the grant to the authorization server of domain B (AS B) . AS B returns an access token for domain B.
3. A2 sends a signed request to B1 carrying the access token, its task, and a Dialog-Context field that proposes D2, with A2 as initiator. B1 verifies A2's WIT and proof; this requires B1 to trust the WIT issuer of domain A. B1 then checks the proposal and creates D2 ().
4. B1 sends the access token to the Transaction Token Service of domain B (TTS B), with D2 in request_details. TTS B returns a transaction token for domain B that records D2 in tctx.dlg. B1 uses this token for its own calls in domain B.

Neither D1 nor the transaction token of domain A reaches domain B. The JWT authorization grant is exchanged for an access token of domain B, and A2 establishes D2 in domain B with itself as initiator. Only A2 knows that D2 continues D1.

Receiver Verification A receiver of a request that carries Dialog-Context:

1. Verifies the WIT and WIMSE proof of the sending hop, and that the proof covers Dialog-Context (, ).
2. If proofs of earlier hops are present, verifies each of them, and that the sub of the WIT at the origin of the chain equals the initiator named in the dialog context ().
3. If a transaction token is present, validates it and checks tctx.dlg ().

If a check fails or cannot be completed, the receiver rejects the request. Its error says which of the two happened. The error format is defined by the agent communication protocol.

Security Properties The binding in this document gives the dialog context the following properties:

Origin:

A receiver can verify which participant initiated the dialog ().

Integrity:

A hop cannot change the dialog context without breaking a WIMSE proof.

Sender binding:

A receiver learns which workload presented the transaction token, and a party without a WIT cannot provide a valid WIMSE proof for it.

Dialog-bound authorization:

A transaction token issued for one dialog is rejected in another.

Response binding:

A signed response cannot be moved to another request, and it carries the dialog context of its request.

Domain separation:

Neither the dialog identifier nor the transaction token of one domain crosses a trust boundary.

Security Considerations

Dialog Binding The WIMSE proof covers Dialog-Context, so a hop cannot change the dialog context without detection. The transaction token records the dialog identifier, so a token issued for one dialog cannot be used in another. Both are needed to bind a request, its authorization, and its dialog. This document does not define additional replay protection. Deployments rely on the replay protection of the WIMSE proof mechanism they use. The dialog identifier is not a secret; it grants nothing on its own.

Responses An attacker that alters an unsigned response can change its result or move it to another dialog. A response signed with the WIMSE HTTP signature and covering Dialog-Context binds the result to the dialog and to the request it answers. A requester can ask for a signed response .

Earlier Hops Verifying only the sending hop does not detect an earlier hop that changed the dialog context. Deployments that need this assurance use the proofs of earlier hops ().

Revocation When the authorization behind a dialog is revoked, for example through Shared Signals , participants stop relying on transaction tokens and cached authorization decisions for that dialog.

Privacy Considerations The dialog identifier in tctx.dlg is visible to every participant in the trust domain that receives the transaction token, and links the transactions of a dialog. This is the purpose of the dialog identifier within a domain. It does not cross a trust boundary (). When the proofs of earlier hops travel with a message (), each proof carries the WIT of its hop. A receiver then learns the workload identity of every participant that forwarded the message, not only the hop it received the message from.

IANA Considerations

JSON Web Token Claims IANA is requested to register the following claim in the "JSON Web Token Claims" registry established by :

• Claim Name: dth
• Claim Description: Hash of the Dialog-Context HTTP field
• Change Controller: IETF
• Specification Document(s): of this document

Transaction Token Context The dlg member of tctx is defined in . No registry for tctx members exists at the time of writing.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. Zscaler Palo Alto Networks This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. Palo Alto Networks Independent The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. Informative References n.d. Nokia Nokia China Mobile This document describes use cases for agentic AI communication systems and derives protocol requirements from those use cases. The requirements are intended to guide IETF standardization work on protocols in the context of agent-to-agent communication, agent-to- tool communication, with focus on dialog management, transport, multimodal communication, communication security, agent identity and authentication. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Nokia University of the Bundeswehr Munich Intuit A request and its response, passing through a chain of workloads, may need authenticated provenance: proof of which workloads participated and whether each changed the message. The base WIMSE HTTP Message Signatures mechanism ([I-D.ietf-wimse-http-signature]) authenticates one workload's message to its immediate recipient and does not provide this across a chain. This document establishes authenticated provenance using per-hop digests of what each hop received and forwarded; this alone detects an omitted hop that changed the message. An aggregate signature closes the remaining gap, a hop that forwards the message unchanged, and keeps the signature close to the size of one signature regardless of chain length. The mechanism works with any aggregate signature scheme. jdrosen.net Nokia Nokia China Mobile Alibaba Cisco This document defines the terminology and architecture for AI agent communications protocols over the Internet. It provides the foundational architectural elements for the Agent Communications Protocol (ACP) - also known as agentproto - a new protocol to be developed in the IETF. ACP enables communication between user agent clients and AI agents, between AI Agents and other AI Agents, or between AI Agents and tools. All three of these interaction patterns - and the many use cases therein - require a session-like protocol which handles lifecycle management, including creation, modification, deletion and so on - along with the exchange of input and output. These session-like associations can be extremely long lived - running for hours or even days - and span multiple IP hosts used by the both the principal and by the agent. They can also be highly intermittent with asynchronous responses. All of these mean a new type of protocol is needed.

Comparison with the A2A Context This appendix compares the context of A2A with the dialog context. A2A context and dialog context

	A2A contextId	Dialog context
What it is	An opaque string grouping related tasks and messages	An identifier and the initiator
Who creates it	The server; a client-supplied value is discouraged	The initiator proposes it; the server checks the proposal and creates the dialog
Scope	One client and one server, a single hop	Spans hops, or continues through a linked dialog
Delegation	A new, unrelated context with the next agent	The same dialog, or a linked dialog
Across domains	No defined behavior; each agent starts a new context	Continues through a linked dialog, with authorization moved by identity chaining
Lifecycle	None at the context level; per task	Dialog-level
Integrity	Not covered by a signature	Covered by each hop's WIMSE proof
Origin	Does not name the client that started it	Names the initiator, verified against the first proof
Authorization	Not tied to tokens	Recorded in the transaction token

Acknowledgments TODO.