Good point Denis, thanks 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 Wed, Sep 2, 2020 at 12:57 AM Denis <[email protected]> wrote: > Hello Dima, > > Not exactly. > > Change : > > or by allowing the third-party application > > into: > > or by allowing the application > > > Denis > > 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 [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
