[OAUTH-WG] Re: [WIMSE] New Version Notification for draft-mw-oauth-tls-session-bound-tokens-07.txt

[KARTHIK RAMPALLI <[e-mail]>]

Hi Ramki, Songbo, all,

Supporting Songbo's request-target-binding point, with one vocabulary
suggestion from the mapping discussion elsewhere on this list: the two
configurations of this draft are two different rows of a verifier's
decision table, and naming them separately avoids overclaim in both
directions.

Without htm/htu, the Session-Binding Proof is a possession-row entry: it
proves the presenter holds the mTLS key on this connection, which is a real
and useful property, and exactly the possession-proving transport
that draft-rampalli-cross-org-delegation-mapping-00 records as the shared
dependency of the delegation-chain and human-authorization layers. What it
does not do in that configuration is bind any single request: as Songbo
says, the same proof authorizes any token-valid request on the connection,
which matters under HTTP/2 and HTTP/3 multiplexing where one connection
carries many logical tasks.

With htm/htu, or a comparable per-request binding, the mechanism starts
contributing to the authorization-inputs row as well: this operation, on
this target, within these bounds. For agentic multi-hop deployments that is
the configuration that matters, because the unit of authorization is the
action, not the connection. Per-request context binding is also the design
point of draft-rampalli-suradar-00, which binds each request to its action
context rather than to the session; I read the two as compatible points on
the same axis, with session binding as the floor and per-request binding as
the profile agent deployments should pin.

Songbo's verifier-order point (workload identity first, then token and
session binding, then resource authorization) is the same
diagnostically-separate-rows structure the mapping records, and stating it
in the draft would make the composition with WIT/WPT concrete to implement.

Karthik Rampalli
Glyphzero, Inc.

On Sun, Jun 21, 2026 at 6:09 PM Songbo Bu <[e-mail]> wrote:

> 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 <[e-mail]>
> 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: <[e-mail]>
> > 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 <[e-mail]>, A Prasad <
> [e-mail]>, Ramki Krishnan <[e-mail]>, Srinivasa
> Addepalli <[e-mail]>
> >
> > 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
>
> --
> WIMSE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>