Thanks Watson. In practical deployments, TLS is never end-to-end - it is between intermediaries e.g. microservice to microservice, microservice to api gateway
BTW, how this idea can easily integrate with service mesh sidecars is described in Appendix B. Thanks, Ramki On Wed, May 20, 2026 at 8:13 AM Watson Ladd <[email protected]> wrote: > On Wed, May 20, 2026 at 12:44 AM Ramki Krishnan <[email protected]> > wrote: > > > > 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. > > Back when I was in grad school, people proposed using TLS Exporter > bound WebAuthn tokens. Early in my career though certificate client > auth could be fixed in HTTP/2 via signing exporter values. Later on I > think we had another bright idea to tie things to exporters. All of > this foundered on a basic architectural issue: TLS and HTTP don't line > up. HTTP requests end up using different sessions all the time, and > intermediary software that terminates TLS on each side often can't be > modified to pass on the exporter information that's required. As > people build things like service meshes and the like, this becomes a > bigger problem. > > IMHO we should be able to solve this "once and for all" by defining a > notion of initial TLS termination point that sends back an exporter > value sufficient for derivation of all exporters other things down the > chain can use, but that's a lot of work. > > Sincerely, > Watson > > > > > > > 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] > > > > -- > Astra mortemque praestare gradatim > -- Thanks, Ramki
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
