Hello Emelia, Thanks for the kind words and feedback!
You do have a point that for ath specifically one could imagine a more generic approach, but practically we're unlikely to be registering hash method variants frequently, we're going from one to two and even doing so reluctantly. The straightforward "new claim per method/algorithm" approach feels appropriate for the scale of the problem and avoids the complexity of restructuring how DPoP Proof binding to the Access Token works. Same for Proof of Possession confirmation claims such x5t#S512 and jkt#S512. S pozdravem, *Filip Skokan* On Fri, 27 Feb 2026 at 00:20, Emelia S. <[email protected]> wrote: > Hi Filip, > > This draft looks great, the only thing that gives me a moment of concern > is the defining of two additional claims for DPoP: jkt#S512 confirmation > method and ath#S512 access token hash claim. I'm wondering if there's a way > to do extensibility here that doesn't later require more additional claims > but rather just variants on existing claims? > > That's the only comment I have, besides it would be good to link to > cross-link a few of the sections so you can jump to the defining part of > the spec for a given thing. > > — Emelia Smith > > On 26 Feb 2026, at 22:51, Filip Skokan <[email protected]> wrote: > > Hi all, > > Just in time for monday's I-D submission cut-off I'd like to introduce a > new individual draft: > > *Additional Hash Algorithms for OAuth 2.0 PKCE and Proof-of-Possession* > <https://datatracker.ietf.org/doc/draft-skokan-oauth-additional-hashes> > > *Problem:* Several OAuth 2.0 mechanisms, namely PKCE (RFC 7636), > mutual-TLS certificate-bound access tokens (RFC 8705), and DPoP (RFC 9449) > exclusively mandate SHA-256 as their hash algorithm, with no alternative > and possibly even no extension point. Security policies such as the US CNSA > 2.0 Suite prohibit the use of SHA-256 entirely and require SHA-384 or > SHA-512 instead. This means that deployments operating under such policies > cannot use any of these mechanisms. > > *For deployments that prohibit SHA-256, this draft defines:* > > - *PKCE*: An S512 code challenge method (registered via the existing > PKCE Code Challenge Methods registry). > - *Mutual-TLS*: An x5t#S512 confirmation method. > - *DPoP*: A jkt#S512 confirmation method and ath#S512 access token > hash DPoP Proof claim, along with a dpop_jkt_method authorization request > parameter for specifying which hash is used in the JWK Thumbprint > calculation for authorization code binding. > - Various RS and AS metadata such that *if* called for, a gradual > migration would be possible. > > I want to be very clear about what this draft *is not*: > > - It is *not* a deprecation of SHA-256 in PKCE, DPoP, or MTLS. The > SHA-256 based methods remain the widely deployed, interoperable, and > recommended defaults for all mechanisms this document addresses. > - It is *not* a call for migration. Deployments that are not subject > to restrictive security policies have no reason to adopt the SHA-512 > alternatives and in my opinion should not offer or use them. > > Feedback is welcome. Thank you > > S pozdravem, > *Filip Skokan* > > A new version of Internet-Draft draft-skokan-oauth-additional-hashes-01.txt >> has been successfully submitted by Filip Skokan and posted to the >> IETF repository. >> >> Name: draft-skokan-oauth-additional-hashes >> Revision: 01 >> Title: Additional Hash Algorithms for OAuth 2.0 PKCE and >> Proof-of-Possession >> Date: 2026-02-26 >> Group: Individual Submission >> Pages: 14 >> URL: >> https://www.ietf.org/archive/id/draft-skokan-oauth-additional-hashes-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-skokan-oauth-additional-hashes/ >> HTML: >> https://www.ietf.org/archive/id/draft-skokan-oauth-additional-hashes-01.html >> HTMLized: >> https://datatracker.ietf.org/doc/html/draft-skokan-oauth-additional-hashes >> >> Abstract: >> >> This document defines SHA-512 as an additional hash algorithm for >> OAuth 2.0 Proof Key for Code Exchange (PKCE), mutual-TLS certificate- >> bound access tokens, and Demonstrating Proof of Possession (DPoP), >> for use in deployments operating under security policies that >> prohibit the use of SHA-256, which is otherwise mandated or the only >> option in these mechanisms. > > _______________________________________________ > 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]
