Subject: [OAUTH-WG] OAuth Bearer Token draft

From: Phil Hunt <[email-masked]>
Date: Fri, 25 Feb 2011 11:38:24 -0800

There was some discussion on the type for the authorization header being OAUTH / MAC / BEARER etc. Did we have a resolution?

As for section 2.2 and 2.3, should we not have a more neutral solution as well and use "authorization_token" instead of oauth_token. The idea is that the parameter corresponds to the authorization header and NOT the value of it. The value of such a parameter an be an encoded value that corresponds to the authorization header.  For example:
GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host: server.example.com
instead of 
GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: server.example.com

The concern is that if for some reason you switch to "MAC" tokens, then you have to change parameter names. Why not keep them consistent?

Apologies if this was already resolved.

Phil
[email-masked]

---

From: Brian Eaton <[email-masked]>
Date: Fri, 25 Feb 2011 11:49:05 -0800

My two cents:

We've already taken three user visible outages because the OAuth2 spec
reused the "oauth_token" parameter in a way that was not compatible
with the OAuth1 spec.

Luckily they were all caught before they caused serious damage.

Generic parameter names are not useful.  They lead to confused
developers and confused code.  If code needs to treat the values
differently, the names should be different as well.

Cheers,
Brian

On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt <[email-masked]> wrote:
> There was some discussion on the type for the authorization header being
> OAUTH / MAC / BEARER etc. Did we have a resolution?
> As for section 2.2 and 2.3, should we not have a more neutral solution as
> well and use "authorization_token" instead of oauth_token. The idea is that
> the parameter corresponds to the authorization header and NOT the value of
> it. The value of such a parameter an be an encoded value that corresponds to
> the authorization header.  For example:
> The concern is that if for some reason you switch to "MAC" tokens, then you
> have to change parameter names. Why not keep them consistent?
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 25 Feb 2011 22:24:55 +0000

Hi Phil,

Yes, per the working group vote, we decided on the name "Bearer".  This name is used in the just-published draft -03.

This draft did not change the oauth_token parameter name; as editor, I am not introducing breaking changes at this point unless directed to do so by a vote of the working group.

I agree with your consistency goal among the related specs.  One step I took in this draft towards that end in the latest draft was establishing the OAuth Errors registry and extending the scope of the OAuth Parameters registry; the goal is that inconsistencies in error and parameter names among related specs will be more likely to be identified and corrected at specification time, rather than at spec usage time.

                                                                Best wishes,
                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, February 25, 2011 11:38 AM
To: OAuth WG
Subject: [OAUTH-WG] OAuth Bearer Token draft

As for section 2.2 and 2.3, should we not have a more neutral solution as well and use "authorization_token" instead of oauth_token. The idea is that the parameter corresponds to the authorization header and NOT the value of it. The value of such a parameter an be an encoded value that corresponds to the authorization header.  For example:
GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host: server.example.com<http://server.example.com>
instead of
GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: server.example.com<http://server.example.com>

Phil
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 25 Feb 2011 14:40:47 -0800

Mike,

Thanks, I just noticed you addressed the change to "BEARER" in draft 03 (just published).

I could live with the parameter name oauth_token, provided we can sub-type (rather then be generic).  E.g.
GET /resource?oauth_token=BEARER+vF9dft4qmT

Either way,  I suspect this is a breaking change unless we specify that no prefix (i.e. as with authorization header) refers to the legacy case. Which I could also live with.

If we don't then the value of OAUTH_TOKEN (or authorization_token) becomes unclear. I think this will cause some major issues that some will consider bugs in the spec.

Phil
[email-masked]

On 2011-02-25, at 2:24 PM, Mike Jones wrote:

> Hi Phil,
>  
> Yes, per the working group vote, we decided on the name “Bearer”.  This name is used in the just-published draft -03.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Feb 2011 16:03:26 -0700

'oauth_token' is limited to bearer tokens only. It is not suitable for anything else. It is a hack and should be treated as such. The right (extensible) solution is to use the HTTP Authorization header, which comes with its own extensibility model.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, February 25, 2011 2:41 PM
To: Mike Jones
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

Mike,

Phil

Hi Phil,

                                                                Best wishes,
                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, February 25, 2011 11:38 AM
To: OAuth WG
Subject: [OAUTH-WG] OAuth Bearer Token draft

As for section 2.2 and 2.3, should we not have a more neutral solution as well and use "authorization_token" instead of oauth_token. The idea is that the parameter corresponds to the authorization header and NOT the value of it. The value of such a parameter an be an encoded value that corresponds to the authorization header.  For example:
GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host: server.example.com<http://server.example.com/>
instead of
GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: server.example.com<http://server.example.com/>

Phil

---

From: Brian Eaton <[email-masked]>
Date: Fri, 25 Feb 2011 15:25:33 -0800

On Fri, Feb 25, 2011 at 3:03 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> ‘oauth_token’ is limited to bearer tokens only. It is not suitable for
> anything else.

Except that OAuth 1.0 already went out using oauth_token for signed requests.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Feb 2011 16:46:00 -0700

2.0 does not use this parameter. Only the bearer token draft uses it. If you have an issue with that, feel free to change that parameter name for bearer token requests. The MAC draft does not support protected resources requests via the query or post parameters, only the header.

EHL

> -----Original Message-----
> From: Brian Eaton [mailto:[email-masked]]
> Sent: Friday, February 25, 2011 3:26 PM
> To: Eran Hammer-Lahav
> Cc: Phil Hunt; Mike Jones; OAuth WG
> > 'oauth_token' is limited to bearer tokens only. It is not suitable for
> > anything else.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 26 Feb 2011 13:30:57 +0100

I agree with your point of view.

Consequentely, the parameter name should be something like "bearer_token"?

regards,
Torsten.

Am 25.02.2011 20:49, schrieb Brian Eaton:
> On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt<[email-masked]>  wrote: