Subject: [OAUTH-WG] Issue: add refresh token as optional in all access token requests

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 12:12:28 -0700

Not all the flows return a refresh token for security or practicality
reasons. Adding refresh token as optional in all access token requests is
required to enable upgrading a token to a token with secret. It also can
make the spec slightly shorter by not having to repeat all the parameters.

We need to either add it to every token response or allow the client to
request a secret directly without having to refresh the token.

Proposal: Keep bearer tokens as the default first-issued credential and add
an optional refresh token everywhere.

EHL

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Apr 2010 12:22:53 -0700

+1, remember discussing this a week or so ago on the list

On Thu, Apr 15, 2010 at 12:12 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Apr 2010 12:08:00 -0400

Sure, this seems sensible, especially with the *optional* part.

On Apr 15, 2010, at 3:22 PM, David Recordon wrote:

> On Thu, Apr 15, 2010 at 12:12 PM, Eran Hammer-Lahav <[email-masked] 
> > wrote:

---

From: Mark Mcgloin <[email-masked]>
Date: Fri, 16 Apr 2010 17:24:53 +0100

+1 to this

Mark McGloin

>On 16/04/2010 17:08, Richard Barnes <[email-masked]>  wrote:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Apr 2010 10:33:09 +0200

-1 to this

If a refresh token is the only way to obtain an access token with 
corresponding secret than making refresh tokens an optional result 
parameter will not suffice.

How shall the client indicate that it requires a request token? From my 
point of view, either refresh tokens become a mandatory parameter or the 
client is given an input parameter to indicate its desire with every flow.

My suggestion is to add "secret_type" to all flows and to issue request 
tokens where they are really needed. In all flows, where user 
interaction takes place or user credentials are processed.

My impression is, the API design is slowly getting weird because we want 
to circumvent this single parameter.

regards,
Torsten.

Am 16.04.2010 18:24, schrieb Mark Mcgloin:
> +1 to this
>
> Mark McGloin
>
>    
>> On 16/04/2010 17:08, Richard Barnes<[email-masked]>   wrote:
>>      
>    
>>>> On Thu, Apr 15, 2010 at 12:12 PM, Eran Hammer-Lahav
>>>>          
> <[email-masked]
>    
>>>> wrote:
>>>>

---

From: David Recordon <[email-masked]>
Date: Sat, 17 Apr 2010 09:57:26 -0700

On Sat, Apr 17, 2010 at 1:33 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> corresponding secret than making refresh tokens an optional result parameter
> will not suffice.

I think Eran is going to change that IIRC.

> tokens where they are really needed. In all flows, where user interaction
> takes place or user credentials are processed.
>
> My impression is, the API design is slowly getting weird because we want to
> circumvent this single parameter.
>
> regards,
> Torsten.
>