Justin, Thanks — the comparison is apt and we've addressed it directly in the draft (new "Relationship to Token Binding" subsection in Section 4).
The short answer is that this draft targets the same problem but avoids Token Binding's three main deployment barriers: - *No new TLS extension.* We use the TLS Exporter/EKM (RFC 5705 / RFC 8446 §7.5), already present in every compliant TLS 1.2, 1.3, and QUIC implementation. No browser or TLS stack changes required. - *Session-scoped binding, not persistent client keys.* Token Binding created long-lived client identity keys across connections. EKM binding is per-connection — it lives and dies with the TLS session, creating no persistent identifier. - *Specified for Token Exchange.* Token Binding was never defined for RFC 8693 delegation chains. Multi-hop agentic workflows are the primary motivation here. *On proxy complexity*: rather than define an EKM-forwarding mechanism (analogous to RFC 8473's referred binding) and inherit the associated mediated-trust problems, we explicitly scope the specification to deployments where the verifier is a direct TLS endpoint — the resource server itself or a co-located sidecar. Forwarding EKM over an HTTP header changes the security property from "bound to the TLS session" to "bound to what a proxy claims the session's EKM was," which is a categorically weaker guarantee. We'd rather hold a precise claim over a well-defined deployment model. *What this doesn't solve:* *browsers*. EKM is not exposed to JavaScript today, so browser-based OAuth flows are out of scope and we don't claim otherwise. The target is server-to-server, service-mesh, and agentic AI workloads. Ramki (on behalf of the co-authors) On Sat, May 23, 2026 at 5:25 AM Justin Richer <[email protected]> wrote: > 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) > > -- Thanks, Ramki
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
