Re: [OAUTH-WG] Refresh Tokens

[David Recordon <[e-mail]>]

Agreed as well on this being implementation specific. Also don't
remember ever seeing anonymity mentioned as a use case.


On Thu, Aug 11, 2011 at 4:28 PM, Eran Hammer-Lahav <[e-mail]> wrote:
> 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" <[e-mail]> 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 <[e-mail]>
> To: Eran Hammer-Lahav <[e-mail]>
> Cc: "OAuth WG ([e-mail])" <[e-mail]>
> 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:[e-mail]]
> Sent: Thursday, August 11, 2011 3:39 PM
> To: Anthony Nadalin
> Cc: Dick Hardt; OAuth WG ([e-mail])
> 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" <[e-mail]> wrote:
>
> I’m raising the issue on the current text, I already provided text if the
> original append.
>
> From: Eran Hammer-Lahav [mailto:[e-mail]]
> Sent: Thursday, August 11, 2011 3:03 PM
> To: Anthony Nadalin
> Cc: Dick Hardt; OAuth WG ([e-mail])
> 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" <[e-mail]> 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:[e-mail]]
> Sent: Thursday, August 11, 2011 1:46 PM
> To: Anthony Nadalin; Dick Hardt
> Cc: OAuth WG ([e-mail])
> 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 <[e-mail]>
> Date: Thu, 11 Aug 2011 12:41:28 -0700
> To: Eran Hammer-lahav <[e-mail]>, Dick Hardt
> <[e-mail]>
> Cc: "OAuth WG ([e-mail])" <[e-mail]>
> Subject: RE: [OAUTH-WG] Refresh Tokens
>
>
> Anonymity was certainly part of the design for WRAP
>
> From: Eran Hammer-Lahav [mailto:[e-mail]]
> Sent: Thursday, August 11, 2011 12:35 PM
> To: Anthony Nadalin; Dick Hardt
> Cc: OAuth WG ([e-mail])
> 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 <[e-mail]>
> Date: Thu, 11 Aug 2011 11:15:28 -0700
> To: Dick Hardt <[e-mail]>
> Cc: "OAuth WG ([e-mail])" <[e-mail]>
> Subject: Re: [OAUTH-WG] Refresh Tokens
>
>
> Many reasons, but none are explained in the specification
>
> From: Dick Hardt [mailto:[e-mail]]
> Sent: Thursday, August 11, 2011 10:51 AM
> To: Anthony Nadalin
> Cc: OAuth WG ([e-mail])
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>