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]
