A motivation of the 2.1 spec is that an AS or client would declare they are compliant with 2.1 and not have a piecemeal set of features. IE there is a bar for compliance and an AS or client does not cherry pick the ones they like.
I might be wrong, but features that drive security are not optional -- and that is a key driver of 2.1 compliance. On Tue, Sep 16, 2025 at 11:29 AM Neil Madden <neil.e.mad...@runbox.eu> wrote: > > > > On 16 Sep 2025, at 10:36, Dick Hardt <dick.ha...@gmail.com> wrote: > > > > > > > Is the intent of this change to workaround this by having the client > only attempt PKCE when the AS advertises that it supports 2.1? I feel like > this will only result in a net reduction of use of PKCE — at least until > 2.1 support in servers becomes very widespread. > > > > No. > > > > > Can you clarify if that is the problem this change is intended to > address? > > > > We are solving how protocol version support is handled in automatic > client registration. > > > > The AS metadata advertises that the AS supports OAuth 2.1 -- nothing more > > > > The client metadata informs the AS that the client will conform to OAuth > 2.1. An AS that only supports 2.1 may reject registration of a client that > does not support 2.1. > > > > An AS that supports both 2.0 and 2.1 MUST track which clients are 2.1 > compliant, and will enforce 2.1 for those clients. > > > > An AS that only supports 2.1 will enforce 2.1 for all clients. > > > > An existing AS does nothing new. Existing clients do nothing new. > > > > Ok, so if the intent is to enforce PKCE for 2.1 clients then I think I’m > more in favour of the client advertising a code_challenge_methods metadata > (array of “plain” and/or “S256” values) and the AS enforcing if the client > supports a method that the server also supports. (And similar for other > features - I know this isn’t just about PKCE). > > That seems more extensible (after all it’s rare that an AS will only > support OAuth 2.1 and nothing else) and it also better handles things that > are optional in the spec. Full conformance to the OAuth 2.1 spec still > leaves quite a lot of room for variation of features. > > — Neil
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
