Dick, I'm assuming IPP in the thread refers to https://en.wikipedia.org/wiki/Internet_Printing_Protocol — for which there's https://www.pwg.org/ipp/everywhere.html, but as far as I can tell, it's not actually defining a OAuth profile, just specifying that OAuth can be used with IPP. That's also what this thread seems to hint at.
— Emelia > On 17 Sep 2025, at 07:43, Dick Hardt <dick.ha...@gmail.com> wrote: > > Hey Emelia, remind me what IPP is? > > On Wed, Sep 17, 2025 at 2:51 AM emelia <eme...@brandedcode.com > <mailto:eme...@brandedcode.com>> 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. >> >> <default-social-card.png> >> OAuth >> atproto.com >> <https://atproto.com/specs/oauth>OAuth <https://atproto.com/specs/oauth> >> atproto.com <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=40msweet....@dmarc.ietf.org >>> <mailto:40msweet....@dmarc.ietf.org>> wrote: >>> >>> Dick, >>> >>>> On Sep 16, 2025, at 1:40 PM, Dick Hardt <dick.ha...@gmail.com >>>> <mailto: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 <mailto:oauth@ietf.org> >>> To unsubscribe send an email to oauth-le...@ietf.org >>> <mailto:oauth-le...@ietf.org> >>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
