Binding Agent Dialogs to WIMSE and OAuth Credentials

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

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

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].¶

• 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

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 [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.¶

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

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: <transaction token with tctx.dlg = D1>
Content-Digest: sha-256=:<hash of the body>:
Workload-Identity-Token: <WIT with sub = wimse://a.example/agent/a2>
Signature-Input: wimse=("@method" "@path" "dialog-context"
    "txn-token" "content-digest" "workload-identity-token");...
Signature: wimse=:<signature made with A2's WIT key>:

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

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

10. Dialog Identifier in Transaction Tokens

This section applies to deployments that use transaction tokens.¶

{
  "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"
}

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

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).¶

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

Domain separation:

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

14. Security Considerations

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).¶

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

17. References

Appendix A. Comparison with the A2A Context

This appendix compares the context of A2A [A2A] with the dialog context.¶

Acknowledgments

TODO.¶

Authors' Addresses