Thank everyone for your feedback. So the abstract could look like this:
The OAuth 2.1 authorization framework enables a*n* *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 <https://tools.ietf.org/html/rfc6749>. And an additional section is required to describe scenarios where this framework works well and scenarios when it doesn't. On Sat, Aug 29, 2020 at 2:37 AM Aaron Parecki <[email protected]> wrote: > 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= > [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
