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*
Here is a crisper revision.
Implementers should be aware that a token introspection request lets the AS
know when the client
is accessing the RS, which may indicate when the user is using
the client. If this implication is not acceptable, implementers can use
other means to carry
That is not correct.
The authorization code one-time-use is directly between the client and the
AS. The client has a number of mechanisms to ensure it only presents the
authorization code to the AS once, such as a session that was set when the
user started at the client.
In contrast, in a
+1
On Thu, Aug 27, 2020 at 8:20 AM Justin Richer wrote:
> I would clarify that this doesn’t necessarily say that the user’s there,
> and remove the normative requirement (which doesn’t have enforceable teeth
> in this context):
>
> Implementers should be aware that a token introspection request
I would clarify that this doesn’t necessarily say that the user’s there, and
remove the normative requirement (which doesn’t have enforceable teeth in this
context):
Implementers should be aware that a token introspection request lets the AS
know when the client
(and potentially the user)
We already have this same property with authorization codes, and it’s managed
today reasonably well (in my opinion). If you submit the same request URI twice
in the same browser (the refresh you’re talking about), it shouldn’t start two
separate authorization requests, but it would be
Will the following text work for you?
Implementers should be aware that a token introspection request lets the AS
know when the client
(and potentially the user) is accessing the RS, which is also an
indication of when the user is using
the client. If this impliction is not
