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
