Hey Emelia, remind me what IPP is? On Wed, Sep 17, 2025 at 2:51 AM emelia <[email protected]> wrote:
> 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. > > [image: default-social-card.png] > > OAuth <https://atproto.com/specs/oauth> > atproto.com <https://atproto.com/specs/oauth> > <https://atproto.com/specs/oauth> > > > 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= > [email protected]> wrote: > > Dick, > > On Sep 16, 2025, at 1:40 PM, Dick Hardt <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
