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