Subject: [OAUTH-WG] Refresh Tokens

From: Anthony Nadalin <[email-masked]>
Date: Thu, 11 Aug 2011 17:40:50 +0000

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.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 11 Aug 2011 10:50:59 -0700

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:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 11 Aug 2011 11:13:52 -0700 (PDT)

Refresh tokens have a different main goal, in my opinion.  They are useful to allow a log lived durable replacement for username/password.  This means the user's primary credential is not stored in the client.  Refresh tokens can be revoked by the user without requiring password change.  They are also always used over a secure channel, and can fetch a (sometimes much) shorter lived token used over a clear channel.  Yahoo! Messenger and others use a model like this now.  Refresh tokens can also be issued to a particular client requiring authentication, so are not useful if the client authentication credential is not also compromised.

They do have the property of anonymity as well, but that's true of both teh refresh token and access token, so it's not specific to refresh tokens.

-bill

________________________________
From: Anthony Nadalin <[email-masked]>
To: "OAuth WG ([email-masked])" <[email-masked]>
Sent: Thursday, August 11, 2011 10:40 AM
Subject: [OAUTH-WG] Refresh Tokens

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 11 Aug 2011 18:15:28 +0000

Many reasons, but none are explained in the specification

From: Dick Hardt [mailto:[email-masked]]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Refresh Tokens

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 11 Aug 2011 11:21:47 -0700 (PDT)

Does it want to be in the main definition or the security considerations section?

________________________________
From: Anthony Nadalin <[email-masked]>
To: Dick Hardt <[email-masked]>
Cc: "OAuth WG ([email-masked])" <[email-masked]>
Sent: Thursday, August 11, 2011 11:15 AM
Subject: Re: [OAUTH-WG] Refresh Tokens

 
From:Dick Hardt [mailto:[email-masked]] 
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Refresh Tokens

---

From: Justin Richer <[email-masked]>
Date: Thu, 11 Aug 2011 14:35:55 -0400

Isn't this what section 1.5 is already there for? 

   Refresh tokens are credentials used to obtain access tokens.  Refresh
   tokens are issued to the client by the authorization server and are
   used to obtain a new access token when the current access token
   becomes invalid or expires, or to obtain additional access tokens
   with identical or narrower scope (access tokens may have a shorter
   lifetime and fewer permissions than authorized by the resource
   owner).  Issuing a refresh token is optional and is included when
   issuing an access token.

   A refresh token is a string representing the authorization granted to
   the client by the resource owner.  The string is usually opaque to
   the client.  The token denotes an identifier used to retrieve the
   authorization information.  Unlike access tokens, refresh tokens are
   intended for use only with authorization servers and are never sent
   to resource servers.

What could make this text clearer? 

(Though while I'm here, I just noticed a nit: 
  "Issuing a refresh token is optional and is included when issuing an
access token." 

Could be clearer, as in something like: 

 "Issuing a refresh token is optional, but when one is issued it is
included along with an access token.")

 -- Justin

On Thu, 2011-08-11 at 14:21 -0400, William J. Mills wrote:
> ______________________________________________________________________
> 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. 
>  
>  
>  
> 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.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 11 Aug 2011 12:35:07 -0700

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 <[email-masked]<mailto:[email-masked]>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Refresh Tokens

From: Dick Hardt [mailto:[email-masked]]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Refresh Tokens

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 11 Aug 2011 19:41:28 +0000

Anonymity was certainly part of the design for WRAP

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Refresh Tokens

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 11 Aug 2011 19:58:39 +0000

Section 1.5 does not explain why refresh tokens are there. If implementers don't understand why we did something then how are they supposed to get the implementation right?

EHL

---

From: Dick Hardt <[email-masked]>
Date: Thu, 11 Aug 2011 13:25:20 -0700

If it was, no one told me.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Aug 2011 14:27:19 -0600

Maybe the feature was added anonymously. ;-)

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 11 Aug 2011 20:30:25 +0000

Could be! But a definite from Yaron.

From: Dick Hardt [mailto:[email-masked]]
Sent: Thursday, August 11, 2011 1:25 PM
To: Anthony Nadalin
Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Refresh Tokens

From: Eran Hammer-Lahav [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

EHL

---

From: Dick Hardt <[email-masked]>
Date: Thu, 11 Aug 2011 13:44:02 -0700

Reading over your anonymous story at at the bottom, I don't see what difference a refresh token has over an access token. You could do the same thing with just an access token. Am I missing something?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 11 Aug 2011 13:46:18 -0700

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 <[email-masked]<mailto:[email-masked]>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] Refresh Tokens

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 11 Aug 2011 20:51:33 +0000

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.

Sent: Thursday, August 11, 2011 1:46 PM

EHL

EHL

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 11 Aug 2011 13:58:34 -0700 (PDT)

All I'm saying is that anonymity is not unique to refresh tokens, it's true for refresh and access tokens.

________________________________
From: Anthony Nadalin <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>; Dick Hardt <[email-masked]>
Cc: "OAuth WG ([email-masked])" <[email-masked]>
Sent: Thursday, August 11, 2011 12:41 PM
Subject: Re: [OAUTH-WG] Refresh Tokens

 
From:Eran Hammer-Lahav [mailto:[email-masked]] 

EHL

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 11 Aug 2011 14:00:49 -0700 (PDT)

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.

Sent: Thursday, August 11, 2011 1:51 PM

 

EHL
 
To: Eran Hammer-lahav <[email-masked]>, Dick Hardt <[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 11 Aug 2011 15:02:36 -0700

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" <[email-masked]<mailto:[email-masked]>> wrote:

EHL

From: Anthony Nadalin <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, Dick Hardt <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] Refresh Tokens

From: Eran Hammer-Lahav [<mailto:[email-masked]>mailto:[email-masked]]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Refresh Tokens

EHL

From: Anthony Nadalin <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Refresh Tokens

From: Dick Hardt [<mailto:[email-masked]>mailto:[email-masked]]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Refresh Tokens

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
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 11 Aug 2011 22:07:03 +0000

I’m raising the issue on the current text, I already provided text if the original append.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Refresh Tokens

EHL

EHL

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 11 Aug 2011 15:38:31 -0700

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" <[email-masked]<mailto:[email-masked]>> wrote:

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Refresh Tokens

EHL

On Aug 11, 2011, at 17:44, "Anthony Nadalin" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> 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.

EHL

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 11 Aug 2011 22:45:41 +0000

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:[email-masked]]
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Refresh Tokens

EHL

EHL

EHL

EHL

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 11 Aug 2011 16:26:20 -0700 (PDT)

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 <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: "OAuth WG ([email-masked])" <[email-masked]>
Sent: Thursday, August 11, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Refresh Tokens

 

EHL

On Aug 11, 2011, at 18:18, "Anthony Nadalin" <[email-masked]> wrote:
I’m raising the issue on the current text, I already provided text if the original append.  
>On Aug 11, 2011, at 17:44, "Anthony Nadalin" <[email-masked]> wrote:

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 11 Aug 2011 16:27:11 -0700

Your original post does not explain how anonymity is achieved or what it actually means.

Not wearing my editor heat I'm strongly opposed to this entire concept.

EHL

On Aug 11, 2011, at 18:49, "Anthony Nadalin" <[email-masked]<mailto:[email-masked]>> wrote:

EHL

On Aug 11, 2011, at 18:18, "Anthony Nadalin" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
I’m raising the issue on the current text, I already provided text if the original append.

From: Eran Hammer-Lahav [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Refresh Tokens

EHL

EHL

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 11 Aug 2011 16:28:53 -0700

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" <[email-masked]<mailto:[email-masked]>> wrote:

To: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>

EHL

EHL

EHL

EHL

---

From: David Recordon <[email-masked]>
Date: Thu, 11 Aug 2011 17:15:54 -0700

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 <[email-masked]> 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" <[email-masked]> 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.
>
>
> Disagree, this was our rational and this is one way it’s used today with our
> scenarios. This needs to be assigned an issue.
>
> 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
>
> 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.
>
> 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
> 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.
>
> 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
>
> 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
>
> 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.
>
>
>
> 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.

---

From: Aiden Bell <[email-masked]>
Date: Fri, 12 Aug 2011 01:18:00 +0100

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 <[email-masked]> wrote:

> ------------------------------
> *From:* Anthony Nadalin <[email-masked]>
> *To:* Eran Hammer-Lahav <[email-masked]>
> *Cc:* "OAuth WG ([email-masked])" <[email-masked]>
> *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:[email-masked]]
> *Sent:* Thursday, August 11, 2011 3:39 PM
> *To:* Anthony Nadalin
> *Cc:* Dick Hardt; OAuth WG ([email-masked])
> *Subject:* Re: [OAUTH-WG] Refresh Tokens
>
> On Aug 11, 2011, at 18:18, "Anthony Nadalin" < <[email-masked]>
> [email-masked]> wrote:
>
>  *From:* Eran Hammer-Lahav [mailto:[email-masked]]
> *Sent:* Thursday, August 11, 2011 3:03 PM
> *To:* Anthony Nadalin
> *Cc:* Dick Hardt; OAuth WG ( <[email-masked]>[email-masked])
> *Subject:* Re: [OAUTH-WG] Refresh Tokens
>
>  2. The current text provides all the information needed to imement. No
> one raised an implementation issue on the current text.
>
>  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" < <[email-masked]>
> [email-masked]> 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:[email-masked]]
> *Sent:* Thursday, August 11, 2011 1:46 PM
> *To:* Anthony Nadalin; Dick Hardt
> *Cc:* OAuth WG ( <[email-masked]>[email-masked])
> *Subject:* Re: [OAUTH-WG] Refresh Tokens
>
>  *From: *Anthony Nadalin < <[email-masked]>[email-masked]>
> *Date: *Thu, 11 Aug 2011 12:41:28 -0700
> *To: *Eran Hammer-lahav < <[email-masked]>[email-masked]>, Dick
> Hardt < <[email-masked]>[email-masked]>
> *Cc: *"OAuth WG ( <[email-masked]>[email-masked])" < <[email-masked]>
> [email-masked]>
> *Subject: *RE: [OAUTH-WG] Refresh Tokens
>
>
>  *From:* Eran Hammer-Lahav [ <[email-masked]>
> mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, August 11, 2011 12:35 PM
> *To:* Anthony Nadalin; Dick Hardt
> *Cc:* OAuth WG ( <[email-masked]>[email-masked])
> *Subject:* Re: [OAUTH-WG] Refresh Tokens
>
>  *From: *Anthony Nadalin < <[email-masked]>[email-masked]>
> *Date: *Thu, 11 Aug 2011 11:15:28 -0700
> *To: *Dick Hardt < <[email-masked]>[email-masked]>
> *Cc: *"OAuth WG ( <[email-masked]>[email-masked])" < <[email-masked]>
> [email-masked]>
> *Subject: *Re: [OAUTH-WG] Refresh Tokens
>
>
>  *From:* Dick Hardt [ <[email-masked]>mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Thursday, August 11, 2011 10:51 AM
> *To:* Anthony Nadalin
> *Cc:* OAuth WG ( <[email-masked]>[email-masked])
> *Subject:* Re: [OAUTH-WG] 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
>  <[email-masked]>[email-masked]
>  <https://www.ietf.org/mailman/listinfo/oauth>
> <[email-masked]>[email-masked]
> <https://www.ietf.org/mailman/listinfo/oauth>

-- 
------------------------------------------------------------------
Never send sensitive or private information via email unless it is
encrypted. http://www.gnupg.org

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Aug 2011 21:00:54 -0400

This seems to need a chair to step in.  Tony is taking a strong stand
and maintaining it:

> included so developers understand why the refresh tokens are there.

So far, though it's been only half a day, I've seen several posts
disagreeing with Tony, and none supporting any change to the text for
this.  We're close to ending WGLC, so please post here if you agree
with Tony's suggested change.  Otherwise, it looks like consensus is
against.

Barry, as chair

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 12 Aug 2011 17:10:49 +0200

OAuth allows a client to access user resources without revealing the 
resource owner's identity to the client. Isn't this anonymity? I 
consider this an important property of the protocol.

regards,
Torsten.

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 12 Aug 2011 09:00:17 -0700

Many APIs in practice have a method such as "/me" or "/profile" for
applications to retrieve the profile information of the resource owner given
their access token. IMO this is a completely appropriate use of OAuth, even
though the resource owner is no longer anonymous in this case. I agree that
it's implementation specific.

My understanding was that OAuth is designed to give limited, revokable,
and/or temporary access to a third party without revealing the resource
owner's credentials. This has nothing to do with anonymity.

Also this is not unique to refresh tokens, the same applies to access
tokens.

Aaron Parecki

On Fri, Aug 12, 2011 at 8:10 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> resource owner's identity to the client. Isn't this anonymity? I consider
> this an important property of the protocol.
>
> regards,
> Torsten.
>
>
>
>> ______________________________**_________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>
>
> ______________________________**_________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Aiden Bell <[email-masked]>
Date: Fri, 12 Aug 2011 17:05:41 +0100

In some sense, but it is an indirect consequence of the fact the protocol is
for granting access
without requiring the revealing of user credentials, which in most (but not
all) cases means
hiding the user's identity on the system.

In many cases however, their identity is simply translated/embodied by into
tokens exchanged and
the service using OAuth will expose identity.

Therefore an implicit property is the negotiation of access to resources
without revealing a
user's identity ... but identity goes well beyond login credentials in most
useful systems.
Even then, you can use OAuth with login credentials (in native apps etc)
(4.3) to authenticate.

Because "identity" and "anonymity" may possibly be implemented using OAuth
doesn't mean
that it is an explicit design feature in OAuth itself.

I think it is very dangerous to go down this route, as bringing explicit
anonymity into the mix
will confuse the purpose and scope of OAuth, when anonymity is a restriction
on some system
using OAuth.

I don't see OAuth as being anymore a system with anonymity properties than
say, my web browser.
Depends on how you use it; entirely.

Aiden Bell

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 12 Aug 2011 14:00:50 -0400

Precisely!  In fact the anonymity of this sort can be achieved even 
without a refresh token: as long as the end user is not required to 
authenticate to the client.

But for all I remember, we have never had a SINGLE USE CASE (sorry to 
transition to my pet peeve) that required anonymity.  The original and 
overarching OAuth requirement has been not to reveal user credentials; 
the refresh tokens were required in order to make end-user's life 
easier. In short, I do not recall anonimity being the end.

I have no doubt that Tony has a new important use case, and I think we 
should document it, derive requirements from it, and pursue this in the 
next OAuth release.

Igor