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 <jric...@mitre.org> wrote:

> 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 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 and another for
> the Access Token.
>
> Given that we always generate a new Refresh Token value during "Token
> Refresh", we would never have a true parent / child relationship between a
> Refresh Token and Access Token.
>
> Is there a case where it is NOT appropriate to revoke an "associated"
> Access Token when explictly revoking a Refresh Token?  I define
> "associated" as an Access Token generated from a Refresh Token OR generated
> at the same time of the Refresh Token.
>
> I do see the AS challenges in trying to manage multiple
> simultaneous "associated" Access Tokens.  For example let's say a client
> generates multiple Access Tokens at the same time while generating new
> Refresh Token values during each "Token Refresh" operation.  However I
> don't really see the useful of this case.
>
> Doug
>
> On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <paul.mad...@gmail.com>wrote:
>
>>  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 <gffle...@aol.com> wrote:
>>
>>  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 expectation is that the simultaneous issued
>> access_token would also be revoked.
>>
>> I read the spec as having a typo that should read...
>>
>> 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
>> *based on* that refresh token.
>>
>> Or maybe better... "invalidate all access tokens associated/tied-to that
>> refresh token".
>>
>> Now in the case that the client is retrieving a new refresh_token and
>> access_token, then the new ones should be valid and the old ones
>> potentially revoked.
>>
>> Thanks,
>> George
>>
>> On 6/11/12 4:09 PM, Paul Madsen wrote:
>>
>> 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'
>>
>> I assume the justification for the rule is that an access token issued in
>> exchange for a given refresh token may have been compromised if the refresh
>> token had been. But there is no such causal relationship between an access
>> token & refresh token issued at same time
>>
>> paul
>>
>> On 6/11/12 3:31 PM, doug foiles wrote:
>>
>> 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
>> for that refresh token.
>>
>> My question is on the statement "access tokens issued for that refresh
>> token". What does it mean to have an Access Token "issued" for a Refresh
>> Token?
>>
>> This specific case is clear to me. I am refreshing an Access Token where
>> I keep the same Refresh Token that I used to generate the new Access Token.
>> I see the new Access Token was issued for that Refresh Token.
>> However these two cases are a bit muddy to me. Let’s say I am using the
>> "Resource Owner Password Credentials Grant" where the Access Token Response
>> returns both an Access Token and Refresh Token. Would the Access Token have
>> been issued for that Refresh Token? And let’s say I am refreshing an Access
>> Token but choose to create a new Refresh Token and immediately revoke the
>> original Refresh Token. Would the newly created Access Token have been
>> issued for the original Refresh Token or the new one that was created.
>> If a client would revoke a Refresh Token … I would like the Access Tokens
>> in all of the above cases to be automatically revoked as well. I just want
>> to make sure I understand the model. Thanks.
>> Doug Foiles
>> Intuit
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to