*Interop* I hear your pain -- unfortunately, per the title of the spec, OAuth is an authorization framework -- it is something you can use to build something. Given all the different use cases, full interop was not realistic.
Also, most clients are developed specific to an AS and resource -- so it has not been a barrier to adoption for most deployments. There is lots of discussion around automated registration currently -- something may come out of those discussions that drives more interop between client and AS. *Capabilities* We do NOT want an AS to pick and choose capabilities that are REQUIRED in OAuth 2.1 There is the question about where the optionality lies. *Next Steps* This has been a useful discussion for me. We are working on gathering the differences between 2.1 and 2.0 -- and once we have that I'll come back with a refined proposal. Thanks to everyone that has provided feedback! /Dick On Tue, Sep 16, 2025 at 5:03 PM Michael Sweet <msw...@msweet.org> wrote: > Dick, > > > On Sep 16, 2025, at 6:53 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > > > > 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. > > One of the most frustrating things for me as a developer WRT OAuth is that > interoperability and discoverability have never been a high priority. RFC > 8414 went a long way towards solving the discoverability problem and it > looks like OAuth 2.1 will help for interop. > > OIDC obviously has made some different choices but (for now at least) it > is possible to write an OAuth client that also works with OIDC > Authorization Servers. > > The remaining pain point is with client registration - dynamic client > registration remains optional for both OAuth 2.1 and OIDC, which means it > is impossible to write an OAuth client that doesn't require support for > manually entering a client ID and secret for a given AS. This is bad UX and > ultimately bad security. > > ________________________ > Michael Sweet > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
