Dick, > On Sep 16, 2025, at 1:40 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > > 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.
Funny, my impression from implementing a generic client and developing an extension to IPP to use OAuth/OIDC is the interop is not only possible but feasible. The three key issues for "full" interop on the server side are: - Metadata - Choice of authorization flow (mainly web redirect or device authorization) - Client registration/configuration We have metadata and there are a LOT of AS implementations that support multiple authorization flows, so those are "solved" things. I've mentioned the issue with client registration. Configuration also has separate UX/policy issues that are "out of scope"... > Also, most clients are developed specific to an AS and resource -- so it has > not been a barrier to adoption for most deployments. That hasn't been my experience - applications often depend on generic client implementations that are configured to use a particular AS (largely because of that client registration/configuration issue...) > Capabilities > > We do NOT want an AS to pick and choose capabilities that are REQUIRED in > OAuth 2.1 I wasn't suggesting that, merely that for interoperability you want a way for the client to discover and adapt to the capabilities/configuration of the server. > There is the question about where the optionality lies. Stuff that is critical for interop/security should be required. Stuff that might be tailored to a specific purpose/configuration can be optional, at least from the server side. ________________________ Michael Sweet _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
