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 <[email protected]> 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 > <[email protected]> wrote: > I agree. OAuth works for 3rd as well as 1st parties as well. > > > On 28. Aug 2020, at 05:26, Dima Postnikov <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
