Subject: Re: [OAUTH-WG] third party applications

From: Dima Postnikov <[email-masked]>
Date: Tue, 1 Sep 2020 23:59:15 +1000

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

---

From: Denis <[email-masked]>
Date: Tue, 1 Sep 2020 16:57:24 +0200

Hello Dima,

Not exactly.

Change :

    or by allowing the third-party application

into:

or by allowing the application

Denis

> The OAuth 2.1 authorization framework enables a*n**third-party*     application to obtain limited access to an HTTP service, either on
>     Framework described inRFC 6749  <https://tools.ietf.org/html/rfc6749>.
> On Sat, Aug 29, 2020 at 2:37 AM Aaron Parecki <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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-masked]
>     <mailto:[email-masked]>> wrote:
>
>         > On 28. Aug 2020, at 05:26, Dima Postnikov
>         <[email-masked] <mailto:[email-masked]>> wrote:
>         >
>         > Hi,
>         >
>         > 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
>         >
>         > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Dima Postnikov <[email-masked]>
Date: Wed, 2 Sep 2020 10:19:58 +1000

Good point Denis, thanks

   *third-party* application to obtain access on its own behalf.  This

On Wed, Sep 2, 2020 at 12:57 AM Denis <[email-masked]> wrote:

> The OAuth 2.1 authorization framework enables a*n* *third-party*   application to obtain limited access to an HTTP service, either on
>  And an additional section is required to describe scenarios where this framework works well and scenarios when it doesn't.
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: William Denniss <[email-masked]>
Date: Tue, 1 Sep 2020 20:58:18 -0700

+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"?

On Tue, Sep 1, 2020 at 5:20 PM Dima Postnikov <[email-masked]> wrote:

>>>> applications that act on behalf of a resource owner, too (internal,
>>>> "first-party" and etc).
>>>> >
>>>> > Regards,
>>>> >
>>>> > Dima
>>>> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 2 Sep 2020 15:53:24 +0200

> On 2. Sep 2020, at 05:58, William Denniss <wdenniss=[email-masked]> wrote:
> 
> 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. 

> The OAuth 2.1 authorization framework enables an third-party
> third-party
>  application to obtain access on its own behalf.  This
>> The OAuth 2.1 authorization framework enables an third-party
>> 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-masked]> wrote:
>> > 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
>> >

---

From: Jeff Craig <[email-masked]>
Date: Wed, 2 Sep 2020 09:32:52 -0500

> I suggest to stick with “limited” since privilege restriction is always a

I'm inclined to agree, scopes are a key part of the OAuth model, and while
nothing precludes a "full account access" scope, I do think that the idea
of privilege restriction is worth infusing the document with.

---

From: Dima Postnikov <[email-masked]>
Date: Thu, 3 Sep 2020 01:05:07 +1000

I agree, "limited access" makes sense. I am happy to create a PR, if required.

Current wording is: