I'm not a fan of versionned specs. If the only difference that cannot be discovered is mandatory pkce, then add a field to metadata telling whether it's mandatory or not.
Adding a version field won't tell the whole story: if the server advertises OAuth 2.1 support, does it means it's fully compliant? (does it validates redirect uris as OAuth 2.1 or the more lenient OAuth 2.0?) or only that it incorporates some breaking changes from OAuth 2.1 so clients should treat is a OAuth 2.1 despite not implementing all of it? (given they are only restrictions from 2.0, so a 2.0 client might just work if configured correctly, i.e. using pkce already) Thomas Broyer /tɔ.ma.bʁwa.je/ <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu> Le lun. 15 sept. 2025, 19:59, Dick Hardt <dick.ha...@gmail.com> a écrit : > Hey everyone, > > A key decision in adopting the OAuth 2.1 work was that there would be no > new normative text. As it turns out, we do need to add the ability for the > AS and client to discover if the other party supports OAuth 2.1. > > There are a number of protocol features that are valid in OAuth 2.0 that > are not valid in OAuth 2.1. For example, the code_challenge is REQUIRED in > OAuth 2.1 > > We are proposing the following normative additions to support version > support discovery between the AS and the client. > > For a client to know if an AS supports 2.1, the AS metadata contains a new > "oauth_versions_supported" property that is an array of version strings. > > example: > > "oauth_versions_supported": ["2.0","2.1"] > > > This indicates the AS supports both OAuth 2.0 and OAuth 2.1 > > For an AS to learn that a client supports 2.1, the client would include in > its metadata the "oauth_version" property which would contain the string > "2.1" > > example: > > "oauth_version": "2.1" > > > Note that there is no explicit signal from the client or server at runtime > if a given request or response is conforming with OAuth 2.0 vs OAuth 2.1 > > > https://github.com/oauth-wg/oauth-v2-1/issues/120 > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
