Re: [OAUTH-WG] Refresh Tokens

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 <eran@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" <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>
> *To:* Eran Hammer-Lahav <eran@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:eran@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" < <tonynad@microsoft.com>
> 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]
> *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" < <tonynad@microsoft.com>
> 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]
> *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 < <tonynad@microsoft.com>tonynad@microsoft.com>
> *Date: *Thu, 11 Aug 2011 12:41:28 -0700
> *To: *Eran Hammer-lahav < <eran@hueniverse.com>eran@hueniverse.com>, Dick
> Hardt < <dick.hardt@gmail.com>dick.hardt@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 [ <eran@hueniverse.com>
> mailto:eran@hueniverse.com <eran@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 < <tonynad@microsoft.com>tonynad@microsoft.com>
> *Date: *Thu, 11 Aug 2011 11:15:28 -0700
> *To: *Dick Hardt < <dick.hardt@gmail.com>dick.hardt@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.hardt@gmail.com>mailto:dick.hardt@gmail.com<dick.hardt@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