Re: [OAUTH-WG] third party applications

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 <dick.hardt@gmail.com> 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 <torsten=40lodderstedt.net@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 <dima@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