Apologies, not sure what was going on with my audio today - the points I was going to make:
I did initially (when reading a previous iteration of the slides) have a similar feeling as Brian that for confidential clients the refresh tokens are already sender constrained so this complexity isn’t necessary, but I did find the explanation given on today’s presentation as at least giving a good reason why adding alternative sender constraining could help. I’m not sure about the addition of DPoP-RT-Nonce - from my understanding of the DPoP nonce (that it’s used to ensure freshness - though as per https://datatracker.ietf.org/doc/html/rfc9449#section-11.1 can help with replay too) it’s not immediately clear to me why you would need different freshness (or replay protection) for the two DPoP proofs? The DPoP nonce mechanism is already pretty painful to implement so I’d not be keen to increase its complexity. I think there’s also a question about how this interacts with the usage of DPoP in PAR ( https://datatracker.ietf.org/doc/html/rfc9449#section-10.1 ). From the description of the security model around the two different DPoP keys it seems like the correct security outcome would be to bind the PAR/authorization code/session to the RT DPoP key rather than the access token one. (Though I’m not sure if this can be cleanly done.) Thanks Joseph > On 14 Oct 2025, at 23:44, Yaroslav Rosomakho > <[email protected]> wrote: > > Dear Oauth enthusiasts, > > We'd like to bring to your attention a proposal to separate DPoP Bindings for > Access and Refresh Tokens. > > This draft specifies a lightweight extension to OAuth 2.0 DPoP that allows > refresh tokens to be bound to a different proof-of-possession key than access > tokens. > > In RFC 9449, both access and refresh tokens are bound to the same key > material, which can be limiting in deployments where tokens are managed in > separate security domains (refresh tokens and their keys stored by a backend > service often backed by HSMs and access tokens used by an ephemeral front-end > instance). > > The draft introduces a new HTTP header, DPoP-RT and an optional DPoP-RT-Nonce > mechanism that enable independent key binding and proof-of-possession for > refresh tokens, while preserving full backward compatibility with existing > DPoP behaviour. > > We are very much looking forward to your feedback and suggestions! > > Best regards, > Yaroslav and Loren > > ---------- Forwarded message --------- > A new version of Internet-Draft draft-rosomakho-oauth-dpop-rt-00.txt has been > successfully submitted by Yaroslav Rosomakho and posted to the > IETF repository. > > Name: draft-rosomakho-oauth-dpop-rt > Revision: 00 > Title: Separating DPoP Bindings for Access and Refresh Tokens > Date: 2025-10-14 > Group: Individual Submission > Pages: 17 > URL: https://www.ietf.org/archive/id/draft-rosomakho-oauth-dpop-rt-00.txt > Status: https://datatracker.ietf.org/doc/draft-rosomakho-oauth-dpop-rt/ > HTML: > https://www.ietf.org/archive/id/draft-rosomakho-oauth-dpop-rt-00.html > HTMLized: https://datatracker.ietf.org/doc/html/draft-rosomakho-oauth-dpop-rt > > > Abstract: > > This document defines an extension to OAuth 2.0 Demonstrating Proof- > of-Possession at the application level (DPoP, RFC 9449) that allows > refresh tokens to be bound to a different proof-of-possession key > than access tokens. In the existing specification, a single DPoP > proof is used to bind both tokens to the same key material. However, > in many deployments, refresh tokens and access tokens are stored and > managed in different security contexts. To support this operational > separation, this document introduces a new HTTP header field, DPoP- > RT, and corresponding DPoP-RT-Nonce mechanism, enabling independent > proof-of-possession for refresh token use while preserving > compatibility with existing DPoP-bound access tokens. > > > > The IETF Secretariat > > > > > This communication (including any attachments) is intended for the sole use > of the intended recipient and may contain confidential, non-public, and/or > privileged material. Use, distribution, or reproduction of this communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your > system._______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
