If it was, no one told me. On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote:
> 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
