Workload Identity in Multi System Environments T. Reddy Internet-Draft Z. Sarker Intended status: Standards Track Nokia Expires: 3 May 2027 30 October 2026 Binding Agent Dialogs to WIMSE and OAuth Credentials draft-reddy-wimse-oauth-dialog-binding-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Reddy & Sarker Expires 3 May 2027 [Page 1] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Security Architecture . . . . . . . . . . . . . . . . . . . . 5 4. Assumed Dialog Context Content . . . . . . . . . . . . . . . 7 5. Dialog Establishment . . . . . . . . . . . . . . . . . . . . 8 6. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Dialog Context in WIMSE HTTP Signatures . . . . . . . . . . . 9 8. Dialog Context in the WIMSE Proof Token . . . . . . . . . . . 10 9. Multi-hop Provenance . . . . . . . . . . . . . . . . . . . . 10 10. Dialog Identifier in Transaction Tokens . . . . . . . . . . . 11 10.1. The dlg Member of tctx . . . . . . . . . . . . . . . . . 11 10.2. Requesting the Token . . . . . . . . . . . . . . . . . . 11 10.3. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 11 10.4. Receiver Check . . . . . . . . . . . . . . . . . . . . . 12 11. Trust Boundaries and Identity Chaining . . . . . . . . . . . 12 12. Receiver Verification . . . . . . . . . . . . . . . . . . . . 14 13. Security Properties . . . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 14.1. Dialog Binding . . . . . . . . . . . . . . . . . . . . . 15 14.2. Responses . . . . . . . . . . . . . . . . . . . . . . . 15 14.3. Earlier Hops . . . . . . . . . . . . . . . . . . . . . . 15 14.4. Revocation . . . . . . . . . . . . . . . . . . . . . . . 15 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 16.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . 16 16.2. Transaction Token Context . . . . . . . . . . . . . . . 16 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 17.1. Normative References . . . . . . . . . . . . . . . . . . 16 17.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Comparison with the A2A Context . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The use cases and requirements for agent dialogs [I-D.agentic-ai-usecases-requirements] 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 Reddy & Sarker Expires 3 May 2027 [Page 2] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 limited to that dialog. These requirements lead to an agent communication architecture [I-D.manyfolks-agentproto-arch], 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 [I-D.ietf-wimse-arch], and on OAuth for authorization. The WIMSE framework for AI agents [I-D.ietf-wimse-aims] composes these for agent authentication and authorization. Today none of these mechanisms covers the dialog context: * A WIMSE HTTP signature [I-D.ietf-wimse-http-signature] or WIMSE Proof Token (WPT) [I-D.ietf-wimse-wpt] does not cover the Dialog- Context field. A hop can change the dialog context without breaking the proof. * A transaction token [I-D.ietf-oauth-transaction-tokens] does not record the dialog. A token obtained in one dialog can be presented in another. TLS protects each hop between adjacent endpoints [I-D.ietf-wimse-arch]. 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. Reddy & Sarker Expires 3 May 2027 [Page 3] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 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 (Section 9). 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. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following terms: * Workload Identity Token (WIT), defined in [I-D.ietf-wimse-workload-creds]. * WIMSE Proof Token (WPT), defined in [I-D.ietf-wimse-wpt]. * Transaction Token and Transaction Token Service (TTS), defined in [I-D.ietf-oauth-transaction-tokens]. * Dialog and Dialog Context, defined in [I-D.agentic-ai-usecases-requirements]. Reddy & Sarker Expires 3 May 2027 [Page 4] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 * Dialog Identifier, defined in [I-D.manyfolks-agentproto-arch] 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 [I-D.manyfolks-agentproto-arch]. 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. 3. Security Architecture Reddy & Sarker Expires 3 May 2027 [Page 5] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 +------------+ +-----------------+ +----------------------+ | WIT issuer | | Transaction | | Authorization server | | | | Token Service | | | +------------+ +-----------------+ +----------------------+ | | | | WIT | transaction token | grant for | | (tctx.dlg = D1) | another domain v v v +--------------------------------------------------------------+ | Participant A2 (sender) | +--------------------------------------------------------------+ | | Request, over TLS v +--------------------------------------------------------------+ | Dialog-Context: dlg = D1 <--------------------------(1)--+ | | initiator = wimse://a.example/agent/a1 | | | ^ | | | (2) equal | | | v | | | Txn-Token: tctx.dlg = D1 <--------------------------(3)--+ | | Workload-Identity-Token: sub = wimse://a.example/agent/a2 | | | Signature or WPT, made with A2's WIT key -----------------+ | +--------------------------------------------------------------+ | v +--------------------------------------------------------------+ | Next participant or tool | +--------------------------------------------------------------+ Figure 1: 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. Reddy & Sarker Expires 3 May 2027 [Page 6] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 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 [I-D.ietf-wimse-http-signature], for requests and responses, or the WPT [I-D.ietf-wimse-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 (Section 9). 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 [I-D.ietf-oauth-identity-chaining]. Neither the dialog identifier nor the transaction token of the original domain crosses the boundary. 4. 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 (Section 10.1). Initiator: The WIMSE workload identifier [I-D.ietf-wimse-identifier] of the participant that initiated the dialog. A receiver checks that the first proof in the chain was made by this workload (Section 12). 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. Reddy & Sarker Expires 3 May 2027 [Page 7] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 5. 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 (Section 7). 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 (Section 9). 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. 6. Overview Figure 2 shows the agents in the example. All three are in domain A. Agent A1 initiates dialog D1 with agent A2 (Section 5) and delegates a task to A2, which calls a tool in D1. Domain A +--------------------------------------------------------+ | | | +--------+ request, D1 +--------+ request, D1 | | | A1 |---------------->| A2 |-------------+ | | +--------+ +--------+ | | | (initiator) v | | +------+ | | | Tool | | | +------+ | +--------------------------------------------------------+ Figure 2: Agents in the example Reddy & Sarker Expires 3 May 2027 [Page 8] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 Figure 3 shows the request from A2 to the tool. POST /invoke HTTP/1.1 Dialog-Context: dlg=D1; initiator=wimse://a.example/agent/a1 Txn-Token: Content-Digest: sha-256=:: Workload-Identity-Token: Signature-Input: wimse=("@method" "@path" "dialog-context" "txn-token" "content-digest" "workload-identity-token");... Signature: wimse=:: Figure 3: A request bound to its dialog Values are shown informally. The Dialog-Context syntax is a placeholder (Section 1). 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 Section 9. 7. Dialog Context in WIMSE HTTP Signatures When a request carries the Dialog-Context field, the WIMSE HTTP signature of the request [I-D.ietf-wimse-http-signature], a profile of HTTP Message Signatures [RFC9421], 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 [I-D.ietf-wimse-http-signature], 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. Reddy & Sarker Expires 3 May 2027 [Page 9] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 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 (Section 9). A repeated or malformed Dialog-Context field is handled as specified for covered fields in [I-D.ietf-wimse-http-signature] and [I-D.ietf-wimse-wpt]. 8. 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 [I-D.ietf-wimse-wpt]. 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 [I-D.ietf-wimse-wpt] 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. 9. 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. [I-D.reddy-wimse-aggregate-signatures] 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 Figure 2 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. Reddy & Sarker Expires 3 May 2027 [Page 10] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 10. Dialog Identifier in Transaction Tokens This section applies to deployments that use transaction tokens. 10.1. 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. { "txn": "97053963-771d-49cc-a4e3-20aad399c312", "sub": "user@a.example", "aud": "a.example", "scope": "trip.book", "tctx": { "dlg": "7f3c9a2e-5b1d-4e8a-9c6f-0d2b8e4a1f37" }, "req_wl": "wimse://a.example/agent/a1" } Figure 4: Transaction token recording the dialog 10.2. 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 [RFC8693]. 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. 10.3. Forwarding Participants forward the transaction token down the call chain together with the dialog context. They do not forward access tokens [I-D.ietf-wimse-aims]. A transaction token does not leave its trust domain. Reddy & Sarker Expires 3 May 2027 [Page 11] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 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 (Section 14.4). 10.4. 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. 11. 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 [I-D.ietf-oauth-identity-chaining], so the dialog and the authorization reset at the same point. In Figure 5, A1 initiates dialog D1 with A2 and sends a request in D1 (step 0, Section 5). A2 holds a domain A transaction token that records D1. Reddy & Sarker Expires 3 May 2027 [Page 12] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 Domain A : Domain B : A1 A2 AS A : AS B B1 TTS B | | | : | | | | (0) | | : | | | | D1 | | : | | | |------>| | : | | | | | | : | | | | | (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 | | | | : | |<------------| Figure 5: Linked dialog D2 at the domain boundary 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) [RFC7523]. 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 (Section 5). Reddy & Sarker Expires 3 May 2027 [Page 13] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 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. 12. 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 (Section 7, Section 8). 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 (Section 9). 3. If a transaction token is present, validates it and checks tctx.dlg (Section 10.4). 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. 13. Security Properties The binding in this document gives the dialog context the following properties: Origin: A receiver can verify which participant initiated the dialog (Section 9). 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. Reddy & Sarker Expires 3 May 2027 [Page 14] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 Domain separation: Neither the dialog identifier nor the transaction token of one domain crosses a trust boundary. 14. Security Considerations 14.1. 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. 14.2. 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 [I-D.ietf-wimse-http-signature]. 14.3. 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 (Section 9). 14.4. Revocation When the authorization behind a dialog is revoked, for example through Shared Signals [I-D.ietf-wimse-aims], participants stop relying on transaction tokens and cached authorization decisions for that dialog. 15. 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 (Section 11). Reddy & Sarker Expires 3 May 2027 [Page 15] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 When the proofs of earlier hops travel with a message (Section 9), 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. 16. IANA Considerations 16.1. JSON Web Token Claims IANA is requested to register the following claim in the "JSON Web Token Claims" registry established by [RFC7519]: * Claim Name: dth * Claim Description: Hash of the Dialog-Context HTTP field * Change Controller: IETF * Specification Document(s): Section 8 of this document 16.2. Transaction Token Context The dlg member of tctx is defined in Section 10.1. No registry for tctx members exists at the time of writing. 17. References 17.1. Normative References [I-D.ietf-oauth-identity-chaining] Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, . [I-D.ietf-oauth-transaction-tokens] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, . Reddy & Sarker Expires 3 May 2027 [Page 16] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 [I-D.ietf-wimse-http-signature] Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-08, 20 October 2026, . [I-D.ietf-wimse-identifier] Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse- identifier-04, 23 October 2026, . [I-D.ietf-wimse-workload-creds] Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft- ietf-wimse-workload-creds-02, 2 July 2026, . [I-D.ietf-wimse-wpt] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf- wimse-wpt-02, 27 August 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . Reddy & Sarker Expires 3 May 2027 [Page 17] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . 17.2. Informative References [A2A] "Agent2Agent (A2A) Protocol Specification", n.d., . [I-D.agentic-ai-usecases-requirements] Reddy.K, T., Sarker, Z., and K. Yao, "Agentic AI Use Cases and Requirements", Work in Progress, Internet-Draft, draft-agentic-ai-usecases-requirements-05, 27 October 2026, . [I-D.ietf-wimse-aims] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, 15 September 2026, . [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [I-D.manyfolks-agentproto-arch] Rosenberg, J., Sarker, Z., Reddy.K, T., Yao, K., Liu, D., and S. Krishnan, "Architecture for AI Agent Communications on the Internet", Work in Progress, Internet-Draft, draft- manyfolks-agentproto-arch-00, 30 October 2026, . [I-D.reddy-wimse-aggregate-signatures] Reddy.K, T., Tschofenig, H., and Y. Sheffer, "Authenticated Provenance for WIMSE Delegation Chains", Work in Progress, Internet-Draft, draft-reddy-wimse- aggregate-signatures-01, 28 September 2026, . Reddy & Sarker Expires 3 May 2027 [Page 18] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . Appendix A. Comparison with the A2A Context This appendix compares the context of A2A [A2A] with the dialog context. Reddy & Sarker Expires 3 May 2027 [Page 19] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 +===============+======================+========================+ | | A2A contextId | Dialog context | +===============+======================+========================+ | What it is | An opaque string | An identifier and the | | | grouping related | initiator | | | tasks and messages | | +---------------+----------------------+------------------------+ | Who creates | The server; a | The initiator proposes | | it | client-supplied | it; the server checks | | | value is discouraged | the proposal and | | | | creates the dialog | +---------------+----------------------+------------------------+ | Scope | One client and one | Spans hops, or | | | server, a single hop | continues through a | | | | linked dialog | +---------------+----------------------+------------------------+ | Delegation | A new, unrelated | The same dialog, or a | | | context with the | linked dialog | | | next agent | | +---------------+----------------------+------------------------+ | Across | No defined behavior; | Continues through a | | domains | each agent starts a | linked dialog, with | | | new context | authorization moved by | | | | identity chaining | +---------------+----------------------+------------------------+ | Lifecycle | None at the context | Dialog-level | | | level; per task | | +---------------+----------------------+------------------------+ | Integrity | Not covered by a | Covered by each hop's | | | signature | WIMSE proof | +---------------+----------------------+------------------------+ | Origin | Does not name the | Names the initiator, | | | client that started | verified against the | | | it | first proof | +---------------+----------------------+------------------------+ | Authorization | Not tied to tokens | Recorded in the | | | | transaction token | +---------------+----------------------+------------------------+ Table 1: A2A context and dialog context Acknowledgments TODO. Authors' Addresses Reddy & Sarker Expires 3 May 2027 [Page 20] Internet-Draft Dialog Binding for WIMSE and OAuth October 2026 Tirumaleswar Reddy Nokia Email: k.tirumaleswar_reddy@nokia.com Zaheduzzaman Sarker Nokia Sweden Email: zaheduzzaman.sarker@nokia.com Reddy & Sarker Expires 3 May 2027 [Page 21]