I am for including a versioning of some type, this worked well for SAML “ProtocolSupportEnumeration” which was required as of 2.0.
@Thomas - I dont think it will mean it is fully “compliant" but I think it means dont complain if the AS does comply :) Phil > On 16 Sep 2025, at 5:29 am, Dick Hardt <[email protected]> wrote: > > There are more things than PKCE — the intent would be that if the server > advertises 2.1 it would be fully compliant > > On Mon, Sep 15, 2025 at 8:00 PM Thomas Broyer <[email protected] > <mailto:[email protected]>> wrote: >> 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 <[email protected] >> <mailto:[email protected]>> 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 -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> > _______________________________________________ > 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]
