The last text that has been proposed on the list about this thread is
the following:
Implementers should be aware that a token introspection request lets the
AS know when the client is accessing the RS,
which can also indicate when the user is using the client. If
this implication is not
But if you want to handle revocation (and you do), then the alternative is
short-lived access tokens with frequent refreshing, which also informs the AS
of activity. So is this any better?
If an org running an RS decides to use a 3rd-party AS (eg cloud hosted) then
there are privacy implication
I'm not sure how to word it exactly but I think Dick has landed on what we
ultimately want this to say. Basically that the "request_uri" is intended
to be used only once, the client MUST not use it more than once, and that
the AS should also treat it as one-time use but may make reasonable
accommod
Another approach to address the privacy implications of a token refresh
is a client can obfuscate usage by the user by doing regular token
refreshes independent of user activity.
ᐧ
On Mon, Aug 31, 2020 at 10:41 AM Jeff Craig wrote:
> I think that the argument is that token refreshing isn't as s
> On 31 Aug 2020, at 18:41, Jeff Craig wrote:
>
>
> I think that the argument is that token refreshing isn't as strong a signal
> about usage patterns as introspection calls would be, which I agree with.
It’s usually pretty similar in my experience (see below).
> I also think that if a RS
Hi all,
On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote:
> The last text that has been proposed on the list about this thread is
> the following:
>
> Implementers should be aware that a token introspection request lets the
> AS know when the client is accessing the RS,
> which can
