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]
