Hi Michael, Dick, I think perhaps what might be desired here is actually a profile of OAuth 2.1 for IPP, that is to say IPP won't be interoperable with all AS's, but it would be interoperable with all AS's that implement or are compatible with the profile for IPP.
For instance, we have the "OAuth Profile" for AT Proto (I use that term loosely), but that enables many different OAuth clients and Authorization Server implementations to be interoperable with AT Proto. https://atproto.com/specs/oauth OAuth atproto.com There's similar other OAuth Profiles, but I can't remember them off top of my head. — Emelia > On 16 Sep 2025, at 21:17, Michael Sweet <msweet=40msweet....@dmarc.ietf.org> > wrote: > > 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
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
