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

doug foiles <doug.foiles@gmail.com> Tue, 12 June 2012 00:13 UTC

Return-Path: <doug.foiles@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9714321F8559 for <oauth@ietfa.amsl.com>; Mon, 11 Jun 2012 17:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.288
X-Spam-Level:
X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ejCq0rdYMQw for <oauth@ietfa.amsl.com>; Mon, 11 Jun 2012 17:13:54 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3B221F8551 for <oauth@ietf.org>; Mon, 11 Jun 2012 17:13:54 -0700 (PDT)
Received: by yhq56 with SMTP id 56so3569335yhq.31 for <oauth@ietf.org>; Mon, 11 Jun 2012 17:13:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dtVX0f9jXkb+igMdv5rGmF/iR9I++Xth6xd27d/omp0=; b=Hjpr/e8HTo3giwnpIUKR5dFSK2BYxwjks9XAHIldOWpHqyyRGVkzOw70tlvPLpqQGv 6EwK+ezYLR7jGTNhYKXAsKWxlj7HTgI2kEDm8bRKMOVotROv9epN519hILzRD9NR/mvc dK8YZtJ6gFAXLxynt+0GWnp2wQQO06l5379jSEl4NvCo9xzChOisVzaTUNSLg2/nYjuX Sp++uUuPreIgIKajyGk8DyqpDS2BS0HQa6qXaEcr1bRZkSfPg5xePWQ8Iiq4UILc9SER CccHmZwMishpRhfggNBxUHapSwVDmkeQcLU6vu3+1G1UYjPvyjzhlR/vXibeBGGo15Wd 1Xlg==
MIME-Version: 1.0
Received: by 10.50.169.33 with SMTP id ab1mr7341722igc.73.1339460033622; Mon, 11 Jun 2012 17:13:53 -0700 (PDT)
Received: by 10.231.199.135 with HTTP; Mon, 11 Jun 2012 17:13:53 -0700 (PDT)
In-Reply-To: <EA05C2C5-4472-4EC8-92EC-92700BBD25E8@gmail.com>
References: <CAA=QE7P_Mmak9_OvqQ4V33e-UHP-n_8oPNiHiYsx=P4syeDz-Q@mail.gmail.com> <4FD65080.9040305@gmail.com> <4FD65ED8.6000507@aol.com> <EA05C2C5-4472-4EC8-92EC-92700BBD25E8@gmail.com>
Date: Mon, 11 Jun 2012 17:13:53 -0700
Message-ID: <CAA=QE7PeMYb8mkqG+d_27NNDM+01OynoWZBAaSHdKPT4_K-VOQ@mail.gmail.com>
From: doug foiles <doug.foiles@gmail.com>
To: Paul Madsen <paul.madsen@gmail.com>
Content-Type: multipart/alternative; boundary="e89a8f3ba8717eb2ee04c23b579c"
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2012 00:13:55 -0000

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.madsen@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 <gffletch@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
>
>
>