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

Paul Madsen <paul.madsen@gmail.com> Mon, 11 June 2012 20:09 UTC

Return-Path: <paul.madsen@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 4C53211E809A for <oauth@ietfa.amsl.com>; Mon, 11 Jun 2012 13:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 kf1nbDn60mlt for <oauth@ietfa.amsl.com>; Mon, 11 Jun 2012 13:09:40 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6786711E808F for <oauth@ietf.org>; Mon, 11 Jun 2012 13:09:40 -0700 (PDT)
Received: by vcqp1 with SMTP id p1so2854048vcq.31 for <oauth@ietf.org>; Mon, 11 Jun 2012 13:09:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=k/mUylyJcl3LRsvIXnAQ0twmfsxExFW6the7zYo0H1U=; b=mRI9iBCtB34/Tg2+hLL0I/OZQrHPaqSK+fxhoUN5bQ2Zb/ZHOBpw/nzEy3pwg71WSl 3S1g6CeGhy2+p8IR6vTi66W2gcw4bVIfEkPlCDh653JkrbOvJT2k1prdMZ3lRLcf3B9A BfUrZkY+WuZZZDqW9xvQlkgnRH7MKbfq5D8UVgQytAhnJ2rNqQEqGXFcYrf1H6z88cea mZQg2WBDOMudB9q+ARC6KZMfAt1nGNQHtf+SrjhhFrCogO2kvE63AWmmsDIr2hBaBVoC 3LFF30lckr4u1klOe/ehX/SA46YPNhIqmHaoPFCu4/4oNaIdvfJKHcYR0K41VU79bW4D fh1w==
Received: by 10.52.25.70 with SMTP id a6mr11091805vdg.78.1339445379861; Mon, 11 Jun 2012 13:09:39 -0700 (PDT)
Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id by3sm21525581vdc.17.2012.06.11.13.09.37 (version=SSLv3 cipher=OTHER); Mon, 11 Jun 2012 13:09:38 -0700 (PDT)
Message-ID: <4FD65080.9040305@gmail.com>
Date: Mon, 11 Jun 2012 16:09:37 -0400
From: Paul Madsen <paul.madsen@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: doug foiles <doug.foiles@gmail.com>
References: <CAA=QE7P_Mmak9_OvqQ4V33e-UHP-n_8oPNiHiYsx=P4syeDz-Q@mail.gmail.com>
In-Reply-To: <CAA=QE7P_Mmak9_OvqQ4V33e-UHP-n_8oPNiHiYsx=P4syeDz-Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090002070008090808000906"
Cc: 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: Mon, 11 Jun 2012 20:09:41 -0000

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 list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth