That works for me Torsten, thanks.
The “SHOULD”s make it interesting for the clients. It seems that the
client developer will need to know how the individual AS’s are handling it.
I pasted a couple of examples below where the terms “SHOULD” and “SHOULD
NOT” are used. Both of these indicate to
agree that it'd be preferable to refer to the higher level grant
related, the spec stipulates
'The client MUST NOT make any assumptions about the timing and MUST NOT
use the token again.'
So what does the client do with it's existing access token when it
revokes the associated refresh token?
Hi all,
we should probably adopt the wording to refer to the access grant underlying
all tokens? Something like: "based on the same access grant ...".
What do you think?
regards,
Torsten.
doug foiles schrieb:
Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to comment on
wh
Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to comment
on what was intended for this ... and would be much appreciated.
On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer wrote:
> I agree with Doug and George's reading: nuking the refresh token gets rid
> of all access tokens ass
I agree with Doug and George's reading: nuking the refresh token gets
rid of all access tokens associated with that refresh token's lifetime.
This includes both simultaneous issuance as well as derived issuance.
-- Justin
On 06/11/2012 08:13 PM, doug foiles wrote:
Hi Paul and George,
Even th
Hi Paul and George,
Even though the Access Token is short lived, I would still like to revoke
it immediately if the user chooses to revoke the Refresh Token. And I
would love for the client application to only have to make one web service
call to accomplish that and not one for the Refresh Token
Hi George, perhaps it depends on the reason for the refresh token being
revoked. If because the user removed their consent then yes I agree that *all*
tokens should be revoked
Sent from my iPhone
On 2012-06-11, at 5:10 PM, George Fletcher wrote:
> Paul,
>
> I think I came to a different con
Paul,
I think I came to a different conclusion...
If I use the Resource Owner Password Credential flow and get back both
an access_token and a refresh_token then I would assume that the issued
access_token is tied in some way to the refresh_token. If the
refresh_token is revoked, then my expe
Hi Doug, my interpretation is that 'for that refresh token' means those
access tokens issued in exchange for that refresh token.
Consequently, for the cases you cite below, the access tokens at the
same time as a given refresh token need not be invalidated when that
refresh token is 'processed
Hi all,
I was hoping to get some clarity on a statement in section 2.0 of
draft-ietf-oauth-revocation-00.
If the processed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
10 matches
Mail list logo
