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]
