Hi Ramki, Songbo, all, Supporting Songbo's request-target-binding point, with one vocabulary suggestion from the mapping discussion elsewhere on this list: the two configurations of this draft are two different rows of a verifier's decision table, and naming them separately avoids overclaim in both directions.
Without htm/htu, the Session-Binding Proof is a possession-row entry: it proves the presenter holds the mTLS key on this connection, which is a real and useful property, and exactly the possession-proving transport that draft-rampalli-cross-org-delegation-mapping-00 records as the shared dependency of the delegation-chain and human-authorization layers. What it does not do in that configuration is bind any single request: as Songbo says, the same proof authorizes any token-valid request on the connection, which matters under HTTP/2 and HTTP/3 multiplexing where one connection carries many logical tasks. With htm/htu, or a comparable per-request binding, the mechanism starts contributing to the authorization-inputs row as well: this operation, on this target, within these bounds. For agentic multi-hop deployments that is the configuration that matters, because the unit of authorization is the action, not the connection. Per-request context binding is also the design point of draft-rampalli-suradar-00, which binds each request to its action context rather than to the session; I read the two as compatible points on the same axis, with session binding as the floor and per-request binding as the profile agent deployments should pin. Songbo's verifier-order point (workload identity first, then token and session binding, then resource authorization) is the same diagnostically-separate-rows structure the mapping records, and stating it in the draft would make the composition with WIT/WPT concrete to implement. Karthik Rampalli Glyphzero, Inc. On Sun, Jun 21, 2026 at 6:09 PM Songbo Bu <[email protected]> wrote: > Hi Ramki, all, > > I read the -07 summary with the WIMSE boundary in mind. The split > makes sense to me: WIT/WPT proves workload identity at the application > layer; this draft binds the access token to the concrete TLS > connection, which is a different replay boundary. > > One implementation-facing point I would like to see tightened is > request-target binding. If `htm`/`htu` remain optional and a proof is > reusable for all requests on the same connection, the base profile is > primarily a stolen-token replay defense, not a per-request > authorization proof. That is fine, but for agent/sidecar deployments > with HTTP/2 or HTTP/3 multiplexing, reverse proxies, and multiple > logical tasks on one TLS connection, the draft should be very explicit > about when per-request claims are expected. > > Concretely, I would suggest: > > * Define the canonical form of `htu` precisely if it is used: > scheme/authority/path/query handling, percent-encoding, path > normalization, and whether a relative path is ever sufficient. > * Add guidance that deployments multiplexing distinct resources, > tenants, users, or agent tasks over one connection should use > `htm`/`htu` or a comparable request binding; otherwise the same > session proof can authorize any token-valid request on that > connection. > * In the WIMSE section, say explicitly that the verifier order is > workload identity/attestation first, then token/session binding, then > resource authorization. That makes the composition with WIT/WPT easier > to implement. > > This does not change the core mechanism. It just keeps the security > boundary clear for the agentic multi-hop case that motivates the > draft. > > Best, > Songbo > > > On Sun, 21 Jun 2026 00:30:27 -0700, Ramki Krishnan <[email protected]> > wrote: > > Dear All, > > > > Cross-posting to wimse@: §5 positions this draft as complementary to > WIMSE WIT/WPT — WIT/WPT proves workload identity at the application layer; > this draft binds the OAuth token to the specific TLS connection. > > > > -07 is available: > https://datatracker.ietf.org/doc/draft-mw-oauth-tls-session-bound-tokens/ > > > > What it is. A PoP profile for OAuth 2.0 access tokens, scoped to mTLS > deployments where the verifier is a direct TLS endpoint or co-located > sidecar. The primary motivation is bearer-token replay in autonomous > multi-hop agentic AI workflows, where RFC 8693 delegation chains amplify > the consequences of any single token compromise. The Session-Binding Proof > binds a token to the current TLS connection via the TLS Exporter (RFC 5705 > / RFC 8446 §7.5), amortized to one signature per (token, connection) pair. > > > > What it isn't. Not a revival of TLS Token Binding (RFC 8471–8473): no > new TLS extension, no persistent client keys, binding scoped to the TLS > session. Not for browsers (EKM not exposed to JavaScript). Not for remote > TLS termination. All explicitly out of scope, stated up front in §1. > > > > Why not per-hop DPoP + RFC 8693. Per-hop DPoP can gate chain extension; > this draft doesn't claim otherwise. Session binding is structurally > stronger on three axes (§5.2.1, new in -07): key custody outside the agent > runtime, attestation provenance of the binding key, and N vs. N×M > signatures across multi-hop chains. > > > > Threat model (§6). T1–T5 unchanged. New T6: stolen-token chain extension > at the authorization server (AS) — a stolen session-bound token cannot be > exchanged for a successor without possession of the binding key. Composes > with draft-mw-oauth-actor-chain for the AS-visible prior-hop evidence half > of the multi-hop story. > > > > Implementation Status (RFC 7942) added in §10. Feedback particularly > welcome on §5.2.1, T6, the cross-protocol key reuse analysis (§6), and the > WIMSE/OAuth boundary articulation (§5). > > > > Thanks, Ramki (on behalf of the co-authors) > > > > ---------- Forwarded message --------- > > From: <[email protected]> > > Date: Sat, Jun 20, 2026 at 11:53 PM > > Subject: New Version Notification for > draft-mw-oauth-tls-session-bound-tokens-07.txt > > To: Diego R. Lopez <[email protected]>, A Prasad < > [email protected]>, Ramki Krishnan <[email protected]>, Srinivasa > Addepalli <[email protected]> > > > > A new version of Internet-Draft > draft-mw-oauth-tls-session-bound-tokens-07.txt > > > > has been successfully submitted by ramki krishnan and posted to the > > > > IETF repository. > > > > Name: draft-mw-oauth-tls-session-bound-tokens > > > > Revision: 07 > > > > Title: TLS-Session-Bound Access Tokens for OAuth 2.0 > > > > Date: 2026-06-20 > > > > Group: Individual Submission > > > > Pages: 45 > > > > URL: > https://www.ietf.org/archive/id/draft-mw-oauth-tls-session-bound-tokens-07.txt > > > > Status: > https://datatracker.ietf.org/doc/draft-mw-oauth-tls-session-bound-tokens/ > > > > HTML: > https://www.ietf.org/archive/id/draft-mw-oauth-tls-session-bound-tokens-07.html > > > > HTMLized: > https://datatracker.ietf.org/doc/html/draft-mw-oauth-tls-session-bound-tokens > > > > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-mw-oauth-tls-session-bound-tokens-07 > > > > Abstract: > > > > This document defines a mechanism for binding OAuth 2.0 access tokens > > > > to a specific mutual TLS (mTLS) connection. The binding is achieved > > > > through a proof token that incorporates the TLS Exporter value (RFC > > > > 5705) derived from the current connection and an access token hash, > > > > signed by the client's private key corresponding to its mTLS > > > > certificate. This mechanism prevents stolen bearer tokens from being > > > > replayed on a different TLS connection. The proof is constructed > > > > once per (token, connection) pair and reused across all requests on > > > > that connection, delivering session binding with no per-request > > > > signing overhead and no additional key management beyond what mTLS > > > > already provides. The mechanism is applicable to TLS 1.2, TLS 1.3, > > > > and QUIC transports. While applicable to any OAuth 2.0 access token > > > > presented over mTLS, this specification is primarily motivated by the > > > > OAuth 2.0 Token Exchange protocol (RFC 8693), where multi-hop > > > > delegation chains in autonomous, agent-driven architectures create > > > > elevated replay risk. > > > > The IETF Secretariat > > > > -- > > > > Thanks, > > Ramki > > -- > WIMSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
