Re: [OAUTH-WG] third party applications

[Dima Postnikov <[e-mail]>]

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