I maintain my opinion that anonymity be discussed in the security
considerations section. For the purposes of the spec tokens are opaque strings
not intended to be parsed by the client.
________________________________
From: Anthony Nadalin <tony...@microsoft.com>
To: Eran Hammer-Lahav <e...@hueniverse.com>; Dick Hardt <dick.ha...@gmail.com>
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Thursday, August 11, 2011 1:51 PM
Subject: Re: [OAUTH-WG] Refresh Tokens
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:e...@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (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 <tony...@microsoft.com>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav <e...@hueniverse.com>, Dick Hardt <dick.ha...@gmail.com>
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Refresh Tokens
Anonymity was certainly part of the design for WRAP
>
>From:Eran Hammer-Lahav [mailto:e...@hueniverse.com]
>Sent: Thursday, August 11, 2011 12:35 PM
>To: Anthony Nadalin; Dick Hardt
>Cc: OAuth WG (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 <tony...@microsoft.com>
>Date: Thu, 11 Aug 2011 11:15:28 -0700
>To: Dick Hardt <dick.ha...@gmail.com>
>Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
>Subject: Re: [OAUTH-WG] Refresh Tokens
>
>Many reasons, but none are explained in the specification
>>
>>From:Dick Hardt [mailto:dick.ha...@gmail.com]
>>Sent: Thursday, August 11, 2011 10:51 AM
>>To: Anthony Nadalin
>>Cc: OAuth WG (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
>>OAuth@ietf.org
>>https://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
