Ah Michael was sharing his experience of versioning and capabilities in IPP so we could learn from what worked there when contemplating how to do it in OAuth — there is no IPP profile for OAuth as far as I know.
On Wed, Sep 17, 2025 at 8:49 AM emelia <eme...@brandedcode.com> wrote: > 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> 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 <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= >> 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
