> On 28. Aug 2020, at 16:56, Dick Hardt <dick.ha...@gmail.com> wrote: > > Well, OAuth is not very useful in a monolithic application. No need for an > interoperable protocol for that kind of application.
I don’t know why we need to make any assumptions about the application that uses OAuth. A lot of assumptions might turn out to be wrong. So if me make assumptions they must be relevant for the protocol design. So again, why is “independent” or “third-party” relevant for the protocol design? > > And in separating functions, you are creating separate trust domains. Yes, it > is still all internal, but it enables a separation of concerns. > ᐧ > > On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > In my experience OAuth is used in 1st party scenarios as means to separate > functions (e.g. central user management vs. different products) within the > same trust domain thus enabling architectural flexibility. > > I would just remove any constraint on the kind of applications OAuth can be > used for. I don’t see how this governs the protocol design. > > > On 28. Aug 2020, at 15:29, Dick Hardt <dick.ha...@gmail.com> wrote: > > > > The driver in my opinion for first-party use of OAuth is to separate the > > trust domains so that the application is scoped in what it can do vs an > > application that has full access to all resources. I agree that third-party > > can indicate that internal use does not apply. How about the following? > > > > The OAuth 2.1 authorization framework enables an independent > > application to obtain limited access to an HTTP service, either on > > behalf of a resource owner by orchestrating an approval interaction > > between the resource owner and the HTTP service, or by allowing the > > application to obtain access on its own behalf. This > > specification replaces and obsoletes the OAuth 2.0 Authorization > > Framework described in RFC 6749. > > ᐧ > > > > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt > > <torsten=40lodderstedt....@dmarc.ietf.org> wrote: > > I agree. OAuth works for 3rd as well as 1st parties as well. > > > > > On 28. Aug 2020, at 05:26, Dima Postnikov <d...@postnikov.net> wrote: > > > > > > Hi, > > > > > > Can "third-party" term be removed from the specification? > > > > > > The standard and associated best practices apply to other applications > > > that act on behalf of a resource owner, too (internal, "first-party" and > > > etc). > > > > > > Regards, > > > > > > Dima > > > > > > The OAuth 2.1 authorization framework enables a third-party > > > > > > application to obtain limited access to an HTTP service, either on > > > behalf of a resource owner by orchestrating an approval interaction > > > between the resource owner and the HTTP service, or by allowing the > > > third-party application to obtain access on its own behalf. This > > > specification replaces and obsoletes the OAuth 2.0 Authorization > > > Framework described in > > > RFC 6749. > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
