Re: [OAUTH-WG] Refresh Tokens

Eran Hammer-Lahav <eran@hueniverse.com> Thu, 11 August 2011 23:28 UTC

Return-Path: <eran@hueniverse.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 CEC5A11E809B for <oauth@ietfa.amsl.com>; Thu, 11 Aug 2011 16:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level:
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 JdDiMwV6vJPh for <oauth@ietfa.amsl.com>; Thu, 11 Aug 2011 16:28:56 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7BC3411E8099 for <oauth@ietf.org>; Thu, 11 Aug 2011 16:28:56 -0700 (PDT)
Received: (qmail 25594 invoked from network); 11 Aug 2011 23:29:18 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 23:29:18 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 11 Aug 2011 16:28:58 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "William J. Mills" <wmills@yahoo-inc.com>
Date: Thu, 11 Aug 2011 16:28:53 -0700
Thread-Topic: [OAUTH-WG] Refresh Tokens
Thread-Index: AcxYfnGgpKpm7AifR6ieoU/L7DU5yg==
Message-ID: <D76A379A-A43F-4742-9488-D64FF2A931AE@hueniverse.com>
References: <B26C1EF377CB694EAB6BDDC8E624B6E723B89DBF@SN2PRD0302MB137.namprd03.prod.outlook.com> <CA698D45.17CCD%eran@hueniverse.com> <B26C1EF377CB694EAB6BDDC8E624B6E723B89F11@SN2PRD0302MB137.namprd03.prod.outlook.com> <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <B26C1EF377CB694EAB6BDDC8E624B6E723B8A115@SN2PRD0302MB137.namprd03.prod.outlook.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <B26C1EF377CB694EAB6BDDC8E624B6E723B8A1F6@SN2PRD0302MB137.namprd03.prod.outlook.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com>
In-Reply-To: <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D76A379AA43F47429488D64FF2A931AEhueniversecom_"
MIME-Version: 1.0
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Refresh Tokens
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: Thu, 11 Aug 2011 23:28:57 -0000

I strongly agree. I don't see what value there is in discussing anonymity which brings identity into the spec without any justification.

EHL

On Aug 11, 2011, at 19:26, "William J. Mills" <wmills@yahoo-inc.com<mailto:wmills@yahoo-inc.com>> wrote:

It's implementation specific.  You can choose to make them anonymous or you can issue signed plaintext tokens that conceal nothing.  The spec doesn't care.  It's a security consideration of the end implementation, just like the need for tamper protection.  The spec needs only to define them as opaque blobs with a particular syntax.  We are not specifying what encryption you have to use here, and we should not.



________________________________
From: Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>
To: Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>>
Cc: "OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)" <oauth@ietf.org<mailto:oauth@ietf.org>>
Sent: Thursday, August 11, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Refresh Tokens

Disagree, this was our rational and this is one way it’s used today with our scenarios. This needs to be assigned an issue.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>)
Subject: Re: [OAUTH-WG] Refresh Tokens

The text is wrong. This is not why refresh tokens were introduced (originally by Yahoo then in WRAP). And is also technically unfounded. Refresh tokens have no special anonymity properties.

EHL

On Aug 11, 2011, at 18:18, "Anthony Nadalin" <<mailto:tonynad@microsoft.com>tonynad@microsoft.com<mailto:tonynad@microsoft.com>> wrote:
I’m raising the issue on the current text, I already provided text if the original append.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]<mailto:[mailto:eran@hueniverse.com]>
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)
Subject: Re: [OAUTH-WG] Refresh Tokens

1. Process-wise it does. This is a brand new concept *here* and was not mentioned in the charter or any use cases. Therefore, out of scope.

2. The current text provides all the information needed to imement. No one raised an implementation issue on the current text.

3. Refresh token do not provide anonymity. An implementation could but this was never considered in the design.

4. If you have suggested text, present it before the WGLC is over. I am not adding issues to my list without suggested text and wg consensus.

EHL

On Aug 11, 2011, at 17:44, "Anthony Nadalin" <<mailto:tonynad@microsoft.com>tonynad@microsoft.com<mailto:tonynad@microsoft.com>> wrote:
There are no use cases at all in WRAP to help explain choices taken, it does not matter if there were or were not previous issues raised, it is being raised now.

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]<mailto:[mailto:eran@hueniverse.com]>
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)
Subject: Re: [OAUTH-WG] Refresh Tokens

That's irrelevant given WRAP does not mention anonymity or anything else about refresh token not explicitly addressed already by v2. Your email is the very first time this has been raised on this list.

EHL

From: Anthony Nadalin <<mailto:tonynad@microsoft.com>tonynad@microsoft.com<mailto:tonynad@microsoft.com>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav <<mailto:eran@hueniverse.com>eran@hueniverse.com<mailto:eran@hueniverse.com>>, Dick Hardt <<mailto:dick.hardt@gmail.com>dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" <<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [<mailto:eran@hueniverse.com>mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)
Subject: Re: [OAUTH-WG] Refresh Tokens

Section 1.5 already covers refresh tokens. There are many use cases for refresh tokens. They are basically a protocol feature used to make scalability and security more flexible. Anonymity was never part of their design, and by the nature of this protocol, is more in the domain of the resource server (based on what information it exposes via its API). In fact, your email if the first such suggestion of anonymity.

EHL

From: Anthony Nadalin <<mailto:tonynad@microsoft.com>tonynad@microsoft.com<mailto:tonynad@microsoft.com>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt <<mailto:dick.hardt@gmail.com>dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>>
Cc: "OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)" <<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Refresh Tokens

Many reasons, but none are explained in the specification

From: Dick Hardt [<mailto:dick.hardt@gmail.com>mailto:dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (<mailto:oauth@ietf.org>oauth@ietf.org<mailto:oauth@ietf.org>)
Subject: Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked by not issuing new access tokens. A resource does not need to query the authorization server to see if the access token is valid.This simplifies access token validation and makes it easier to scale and support multiple authorization servers.  There is a window of time when an access token is valid, but authorization is revoked.



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:






Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but not tell the client the user's identity. By issuing the refresh token as an 'identifier' for the user (as well as other context data like the resource) it's possible now to let the client get access without revealing anything about the user. Recommend that the above explanation be included so developers understand why the refresh tokens are there.
_______________________________________________
OAuth mailing list
<mailto:OAuth@ietf.org>OAuth@ietf.org<mailto:OAuth@ietf.org>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
<mailto:OAuth@ietf.org>OAuth@ietf.org<mailto:OAuth@ietf.org>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth