> On 2. Sep 2020, at 05:58, William Denniss > <[email protected]> wrote: > > +1 to drop the "third party", there are valid first party use-cases. > > On the subject, in first party cases the access may not be all that > "limited", I wonder if it should read more genericly "an application to > obtain access to an HTTP service"?
I suggest to stick with “limited” since privilege restriction is always a good idea. > > On Tue, Sep 1, 2020 at 5:20 PM Dima Postnikov <[email protected]> wrote: > Good point Denis, thanks > > The OAuth 2.1 authorization framework enables an 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. > > 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 an 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. >> >> 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 >> <[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 > > > _______________________________________________ > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
