I agree. While the original motivations for OAuth were to support third-party apps, it's proven to be useful in many other kinds of situations as well, even when it's a "first-party" app but the OAuth server is operated by a different organization than the APIs. I don't think the abstract needs any qualification on this and would only confuse people further. Any clarifications of which situations are appropriate for using OAuth could be explored in a different section in the spec.
Aaron Parecki 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
