> 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
