At first blush, this feels very reminiscent of tls token binding. Does this work address, overcome, or avoid the problems faced by that specification which failed to gain traction in industry?
- Justin ________________________________ From: Ramki Krishnan <[email protected]> Sent: Wednesday, May 20, 2026 12:42 AM To: [email protected] <[email protected]> Cc: Ramki Krishnan <[email protected]>; A. Prasad <[email protected]>; diego lopez <[email protected]>; Diego Lopez <[email protected]>; srini addepalli <[email protected]> Subject: [OAUTH-WG] New Work: TLS Session-Bound Access Tokens (draft-mw-oauth-tls-session-bound-tokens) Hi all, We'd like to bring draft-mw-oauth-tls-session-bound-tokens to the WG's attention and gauge interest in adoption. Problem - Bearer token replay remains a live threat, particularly as autonomous AI agents and service mesh architectures chain API calls across multiple hops. In these environments, a stolen token can be replayed on a different TLS connection. RFC 8705 (cert-bound tokens) binds tokens to the client certificate but not the specific session; RFC 9449 (DPoP) provides per-request binding but requires a signature on every request, creating overhead that is prohibitive at scale and difficult in sidecar deployments where the signing key is isolated from the application process. What the draft does - We define a mechanism that binds OAuth 2.0 access tokens to a specific TLS session using the TLS Exporter/EKM value (RFC 5705 / RFC 8446 §7.5). A signed proof JWT — carrying the access token hash (ath) and the EKM value (ekm) — is constructed once per (token, connection) pair and reused across all requests on that connection. This amortizes the cryptographic cost while preventing cross-session replay. - The mechanism fits naturally alongside RFC 8705 and RFC 9449 and helps satisfy the sender-constraining recommendations in RFC 9700. Links * Draft: https://datatracker.ietf.org/doc/draft-mw-oauth-tls-session-bound-tokens/ * Authors: Ramki Krishnan, A Prasad, Diego Lopez, Srinivasa Addepalli We welcome feedback on the approach. Thanks, Ramki (on behalf of the co-authors)
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
