Re: [OAUTH-WG] third party applications

[Dima Postnikov]

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


Current wording is:


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 .


On Thu, Sep 3, 2020 at 12:33 AM Jeff Craig  wrote:

> On Wed, Sep 2, 2020 at 8:53 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> > On 2. Sep 2020, at 05:58, William Denniss > 40google@dmarc.ietf.org> 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.
>>
>
> 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.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

> On 2. Sep 2020, at 05:58, William Denniss 
>  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  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  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  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 
>>  wrote:
>> I agree. OAuth works for 3rd as well as 1st parties as well. 
>> 
>> > On 28. Aug 2020, at 05:26, Dima Postnikov  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
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> 
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Dima Postnikov]

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 .


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  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 .
>
>  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  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 > 40lodderstedt@dmarc.ietf.org> wrote:
>>
>>> I agree. OAuth works for 3rd as well as 1st parties as well.
>>>
>>> > On 28. Aug 2020, at 05:26, Dima Postnikov  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
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Denis]

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 inRFC 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 > 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
mailto:40lodderstedt@dmarc.ietf.org>> wrote:

I agree. OAuth works for 3rd as well as 1st parties as well.

> On 28. Aug 2020, at 05:26, Dima Postnikov
mailto:d...@postnikov.net>> 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
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Dima Postnikov]

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 .


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

Re: [OAUTH-WG] third party applications

[Aaron Parecki]

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  wrote:

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

Re: [OAUTH-WG] third party applications

[Jim Manico]

It does not make sense to use OAuth in most single party situations. These 
single-party OAuth use cases are frequently a complete misuse of the framework. 
I +1 the language “3rd party” in an effort to steer implementors in the right 
direction.

--
Jim Manico
@Manicode


> On Aug 28, 2020, at 5:07 AM, Torsten Lodderstedt 
>  wrote:
> 
> 
>> On 28. Aug 2020, at 16:56, Dick Hardt  wrote:
>> 
>> Well, OAuth is not very useful in a monolithic application. No need for an 
>> interoperable protocol for that kind of application.
> 
> I don’t know why we need to make any assumptions about the application that 
> uses OAuth. A lot of assumptions might turn out to be wrong. So if me make 
> assumptions they must be relevant for the protocol design. 
> 
> So again, why is “independent” or “third-party” relevant for the protocol 
> design? 
> 
>> 
>> And in separating functions, you are creating separate trust domains. Yes, 
>> it is still all internal, but it enables a separation of concerns.
>> ᐧ
>> 
>> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt 
>>  wrote:
>> In my experience OAuth is used in 1st party scenarios as means to separate 
>> functions (e.g. central user management vs. different products) within the 
>> same trust domain thus enabling architectural flexibility. 
>> 
>> I would just remove any constraint on the kind of applications OAuth can be 
>> used for. I don’t see how this governs the protocol design.  
>> 
 On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
>>> 
>>> The driver in my opinion for first-party use of OAuth is to separate the 
>>> trust domains so that the application is scoped in what it can do vs an 
>>> application that has full access to all resources. I agree that third-party 
>>> can indicate that internal use does not apply. How about the following?
>>> 
>>>   The OAuth 2.1 authorization framework enables an independent
>>>   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
>>>   application to obtain access on its own behalf.  This
>>>   specification replaces and obsoletes the OAuth 2.0 Authorization
>>>   Framework described in RFC 6749.
>>> ᐧ
>>> 
 On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
  wrote:
>>> I agree. OAuth works for 3rd as well as 1st parties as well. 
>>> 
 On 28. Aug 2020, at 05:26, Dima Postnikov  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
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

> On 28. Aug 2020, at 16:56, Dick Hardt  wrote:
> 
> Well, OAuth is not very useful in a monolithic application. No need for an 
> interoperable protocol for that kind of application.

I don’t know why we need to make any assumptions about the application that 
uses OAuth. A lot of assumptions might turn out to be wrong. So if me make 
assumptions they must be relevant for the protocol design. 

So again, why is “independent” or “third-party” relevant for the protocol 
design? 

> 
> And in separating functions, you are creating separate trust domains. Yes, it 
> is still all internal, but it enables a separation of concerns.
> ᐧ
> 
> On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt  
> wrote:
> In my experience OAuth is used in 1st party scenarios as means to separate 
> functions (e.g. central user management vs. different products) within the 
> same trust domain thus enabling architectural flexibility. 
> 
> I would just remove any constraint on the kind of applications OAuth can be 
> used for. I don’t see how this governs the protocol design.  
> 
> > On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
> > 
> > The driver in my opinion for first-party use of OAuth is to separate the 
> > trust domains so that the application is scoped in what it can do vs an 
> > application that has full access to all resources. I agree that third-party 
> > can indicate that internal use does not apply. How about the following?
> > 
> >The OAuth 2.1 authorization framework enables an independent
> >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
> >application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in RFC 6749.
> > ᐧ
> > 
> > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
> >  wrote:
> > I agree. OAuth works for 3rd as well as 1st parties as well. 
> > 
> > > On 28. Aug 2020, at 05:26, Dima Postnikov  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
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > 
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Dick Hardt]

Well, OAuth is not very useful in a monolithic application. No need for an
interoperable protocol for that kind of application.

And in separating functions, you are creating separate trust domains. Yes,
it is still all internal, but it enables a separation of concerns.
ᐧ

On Fri, Aug 28, 2020 at 7:49 AM Torsten Lodderstedt 
wrote:

> In my experience OAuth is used in 1st party scenarios as means to separate
> functions (e.g. central user management vs. different products) within the
> same trust domain thus enabling architectural flexibility.
>
> I would just remove any constraint on the kind of applications OAuth can
> be used for. I don’t see how this governs the protocol design.
>
> > On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
> >
> > The driver in my opinion for first-party use of OAuth is to separate the
> trust domains so that the application is scoped in what it can do vs an
> application that has full access to all resources. I agree that third-party
> can indicate that internal use does not apply. How about the following?
> >
> >The OAuth 2.1 authorization framework enables an independent
> >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
> >application to obtain access on its own behalf.  This
> >specification replaces and obsoletes the OAuth 2.0 Authorization
> >Framework described in RFC 6749.
> > ᐧ
> >
> > On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
> > I agree. OAuth works for 3rd as well as 1st parties as well.
> >
> > > On 28. Aug 2020, at 05:26, Dima Postnikov  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
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

In my experience OAuth is used in 1st party scenarios as means to separate 
functions (e.g. central user management vs. different products) within the same 
trust domain thus enabling architectural flexibility. 

I would just remove any constraint on the kind of applications OAuth can be 
used for. I don’t see how this governs the protocol design.  

> On 28. Aug 2020, at 15:29, Dick Hardt  wrote:
> 
> The driver in my opinion for first-party use of OAuth is to separate the 
> trust domains so that the application is scoped in what it can do vs an 
> application that has full access to all resources. I agree that third-party 
> can indicate that internal use does not apply. How about the following?
> 
>The OAuth 2.1 authorization framework enables an independent
>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
>application to obtain access on its own behalf.  This
>specification replaces and obsoletes the OAuth 2.0 Authorization
>Framework described in RFC 6749.
> ᐧ
> 
> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt 
>  wrote:
> I agree. OAuth works for 3rd as well as 1st parties as well. 
> 
> > On 28. Aug 2020, at 05:26, Dima Postnikov  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
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] third party applications

[Dick Hardt]

The driver in my opinion for first-party use of OAuth is to separate the
trust domains so that the application is scoped in what it can do vs an
application that has full access to all resources. I agree that third-party
can indicate that internal use does not apply. How about the following?

   The OAuth 2.1 authorization framework enables an *independent*
   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
   application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 2.0 Authorization
   Framework described in RFC 6749.
ᐧ

On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt  wrote:

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

Re: [OAUTH-WG] third party applications

[Torsten Lodderstedt]

I agree. OAuth works for 3rd as well as 1st parties as well. 

> On 28. Aug 2020, at 05:26, Dima Postnikov  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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] third party applications

[Dima Postnikov]

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth