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 inter
> 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
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
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 l
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 resourc
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
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:0
> 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 mig
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
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.
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?
Th
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
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*
app
13 matches
Mail list logo