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 _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
