Subject: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00

From: doug foiles <[email-masked]>
Date: Mon, 11 Jun 2012 12:31:31 -0700

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

---

From: Paul Madsen <[email-masked]>
Date: Mon, 11 Jun 2012 16:09:37 -0400

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:
> 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 list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Mon, 11 Jun 2012 17:10:48 -0400

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.
>
> refresh token had been. But there is no such causal relationship 
> between an access token & refresh token issued at same time
>
> paul
>
>> 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?
>>
>> 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

---

From: Paul Madsen <[email-masked]>
Date: Mon, 11 Jun 2012 18:52:32 -0400

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 <[email-masked]> wrote:

> 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.
> 
> 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
> 
>> 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 
>> 
>>> I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00.
>>> 
>>> 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
>>>

---

From: doug foiles <[email-masked]>
Date: Mon, 11 Jun 2012 17:13:53 -0700

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 <[email-masked]> 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
>
> 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.
>
> 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
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Jun 2012 09:36:46 -0400

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.
> Refresh", we would never have a true parent / child relationship 
> between a Refresh Token and Access Token.
> "associated" as an Access Token generated from a Refresh Token OR 
> generated at the same time of the Refresh Token.
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     Paul,
>>
>>     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.
>>
>>     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
>>
>>>     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
>>>
>>>>     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
>>>>
>>>>
>>>>     [email-masked]  <mailto:[email-masked]>
>>>     [email-masked]  <mailto:[email-masked]>

---

From: doug foiles <[email-masked]>
Date: Tue, 12 Jun 2012 10:09:38 -0700

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 <[email-masked]> 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 Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <[email-masked]>wrote:
>
>> 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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 13 Jun 2012 08:01:26 +0200

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 <[email-masked]> schrieb:

Thanks Justin.  Perhaps we can get Torsten, Stefanie, or Marius to comment on what was intended for this ... and would be much appreciated.

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 

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

Sent from my iPhone

Paul, 

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

Thanks,
George

paul 

Hi all,

Doug Foiles
Intuit

_______________________________________________ OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth 

_______________________________________________ OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth 

_______________________________________________ OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Paul Madsen <[email-masked]>
Date: Wed, 13 Jun 2012 05:43:53 -0400

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?

The rule indicating to the AS that access tokens be revoked as well is 
only a SHOULD, so the client can't be certain that the access token is 'bad'

paul

On 6/13/12 2:01 AM, Torsten Lodderstedt wrote:
> 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.
>
>
>
>     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 <[email-masked]
>     <mailto:[email-masked]>> 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
>
>
>>         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.
>>         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
>>         <[email-masked] <mailto:[email-masked]>> 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
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>             Paul,
>>>
>>>             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
>>>             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
>>>
>>>>             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
>>>>>             I was hoping to get some clarity on a statement in
>>>>>             section 2.0 of draft-ietf-oauth-revocation-00.
>>>>>
>>>>>             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
>>>>>
>>>>>

---

From: doug foiles <[email-masked]>
Date: Thu, 14 Jun 2012 09:50:18 -0700

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 me that the client developer will
need to know the specific implementation in order to process the request
correctly.

   o  Native applications that use the authorization code grant type

      SHOULD do so without using client credentials, due to the native

      application's inability to keep client credentials confidential.

   If the access token request is valid and authorized, the

   authorization server issues an access token as described in

   Section 5.1<http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-5.1>
.  A refresh token SHOULD NOT be included.  If the request

   failed client authentication or is invalid, the authorization server

   returns an error response as described in Section
5.2<http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-5.2>
.

Doug

On Wed, Jun 13, 2012 at 2:43 AM, Paul Madsen <[email-masked]> wrote:

> **
> So what does the client do with it's existing access token when it revokes
> the associated refresh token?
>
> underlying all tokens? Something like: "based on the same access grant ...".
>
> What do you think?
>
> regards,
> Torsten.
>
>
>
> doug foiles <[email-masked]> <[email-masked]> schrieb:
>>
>> comment on what was intended for this ... and would be much appreciated.
>>
>>> 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.
>>>
>>>> being revoked. If because the user removed their consent then yes I agree
>>>> that *all* tokens should be revoked
>>>>
>>>> Sent from my iPhone
>>>>
>>>> refresh token had been. But there is no such causal relationship between an
>>>> access token & refresh token issued at same time
>>>>
>>>> paul
>>>>
>>>> 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.
>>>> 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
>>>>
>>>>