I have been following this thread with my jaw slightly open... As an implementor, the purpose of the refresh token I felt was clear in 1.5. I just don't see the anonymity slant here at all ... any more than any other part of the spec. It all depends on what your service/api or whatever allows for a faceless authorisation session.
I'm with anyone who thinks it belongs well away from the spec. On 12 August 2011 00:28, Eran Hammer-Lahav <e...@hueniverse.com> 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" <wmi...@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 <tony...@microsoft.com> > *To:* Eran Hammer-Lahav <e...@hueniverse.com> > *Cc:* "OAuth WG (oauth@ietf.org)" <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:e...@hueniverse.com] > *Sent:* Thursday, August 11, 2011 3:39 PM > *To:* Anthony Nadalin > *Cc:* Dick Hardt; OAuth WG (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" < <tony...@microsoft.com> > tony...@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:e...@hueniverse.com] > *Sent:* Thursday, August 11, 2011 3:03 PM > *To:* Anthony Nadalin > *Cc:* Dick Hardt; OAuth WG ( <oauth@ietf.org>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" < <tony...@microsoft.com> > tony...@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:e...@hueniverse.com] > *Sent:* Thursday, August 11, 2011 1:46 PM > *To:* Anthony Nadalin; Dick Hardt > *Cc:* OAuth WG ( <oauth@ietf.org>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>tony...@microsoft.com> > *Date: *Thu, 11 Aug 2011 12:41:28 -0700 > *To: *Eran Hammer-lahav < <e...@hueniverse.com>e...@hueniverse.com>, Dick > Hardt < <dick.ha...@gmail.com>dick.ha...@gmail.com> > *Cc: *"OAuth WG ( <oauth@ietf.org>oauth@ietf.org)" < <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 [ <e...@hueniverse.com> > mailto:e...@hueniverse.com <e...@hueniverse.com>] > *Sent:* Thursday, August 11, 2011 12:35 PM > *To:* Anthony Nadalin; Dick Hardt > *Cc:* OAuth WG ( <oauth@ietf.org>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>tony...@microsoft.com> > *Date: *Thu, 11 Aug 2011 11:15:28 -0700 > *To: *Dick Hardt < <dick.ha...@gmail.com>dick.ha...@gmail.com> > *Cc: *"OAuth WG ( <oauth@ietf.org>oauth@ietf.org)" < <oauth@ietf.org> > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Refresh Tokens > > > Many reasons, but none are explained in the specification > > *From:* Dick Hardt [ > <dick.ha...@gmail.com>mailto:dick.ha...@gmail.com<dick.ha...@gmail.com>] > > *Sent:* Thursday, August 11, 2011 10:51 AM > *To:* Anthony Nadalin > *Cc:* OAuth WG ( <oauth@ietf.org>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>OAuth@ietf.org > <https://www.ietf.org/mailman/listinfo/oauth> > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > <OAuth@ietf.org>OAuth@ietf.org > <https://www.ietf.org/mailman/listinfo/oauth> > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth