Re: [OAUTH-WG] consistency of token param name in bearer token type

[Bill <[e-mail]>]

On 15/06/11 02:30, David Recordon wrote:
> Bearer token doesn't exist within the core spec around getting an
> access token. The term that is used is "access token".

Right, I get that Bearer is defined in another draft document (which the 
core spec references and probably should not btw, that's confusing as well)

 >> "access_token":"vF9dft4qmT",
 >> "token_type":"Bearer"

I was referring to bearer token wrt token_type. The above is how I 
understand one will be supplied.

Bill

>
>
> On Tue, Jun 14, 2011 at 8:12 AM, Bill<[e-mail]>  wrote:
>> On 10/06/11 17:45, David Recordon wrote:
>>>
>>> I think it's vital to have the GET and POST parameters make sense to
>>> every developer. I worry less about the authorization header since a
>>> developer implementing it will honestly be a stronger engineer.
>>
>> I agree with David regardless of engineering strength, this is going to be
>> confusing to developers. Also tho', devs are exposed to the access token
>> response, not just the GET/POST bits. So ideally syntax would line up with
>> how the token is obtained
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-5.1 and not just
>> across requests using the token.
>>
>> A possible clarifying change is to use something like "bearer_token" end to
>> end.
>>
>> [[[
>> {
>>        "access_token":"vF9dft4qmT",
>>        "token_type":"bearer_token", /* ? */
>> ...
>> }
>>
>>
>> GET /resource HTTP/1.1
>> Host: server.example.com
>> Authorization: bearer_token vF9dft4qmT
>>
>>
>> GET /resource?bearer_token=vF9dft4qmT&...
>> Host: server.example.com
>>
>>
>> POST /resource
>> Host: server.example.com
>> Content-Type: application/x-www-form-urlencoded
>>
>> &bearer_token=vF9dft4qmT&...
>>
>>
>> HTTP/1.1 401 Unauthorized
>> WWW-Authenticate: bearer_token realm="example"
>> ]]]
>>
>>
>> Bill
>>
>>
>>> Here's what I said earlier in the thread about my motivation:
>>>>
>>>> Did a full read through of draft 16 and the bear token spec with Paul
>>>> yesterday afternoon in order to do a manual diff from draft 10. The
>>>> point Doug raised was actually confusing. Throughout the core spec
>>>> it's referred to as access_token but then becomes bearer_token upon
>>>> use.
>>>>
>>>> Just thinking through this from a developer documentation perspective,
>>>> it's going to become confusing. Developer documentation focuses on
>>>> getting an access token and then using that access token to interact
>>>> with an API. Thus the code you're writing as a client developer will
>>>> use variables, cache keys, and database columns named `access_token`.
>>>> But then when you're going to use it, you'll need to put this access
>>>> token into a field named bearer_token.
>>>>
>>>> Feels quite a bit simpler to just name it access_token. Realize the
>>>> core spec never did this since we didn't want to trample on protected
>>>> resources which might already have a different type of access_token
>>>> parameter. oauth_token was a good compromise since developers would
>>>> already know that they were using OAuth and thus a new term wasn't
>>>> being introduced. That's no longer true with bearer_token since 99% of
>>>> developers will have never heard of a bearer token.
>>>>
>>>> Googling for "bearer token" turns up Eran's blog post titled "OAuth
>>>> Bearer Tokens are a Terrible Idea" and there isn't a single result on
>>>> the first page which explains what they are. Binging for "bearer
>>>> token" is equally scary.
>>>
>>> --David
>>>
>>>
>>> On Fri, Jun 10, 2011 at 9:34 AM, John Kemp<[e-mail]>    wrote:
>>>>
>>>> George,
>>>>
>>>> On Jun 10, 2011, at 4:11 PM, George Fletcher wrote:
>>>>
>>>>> I definitely don't want to change the Authorization header naming
>>>>> scheme. I believe it should stay 'Bearer' because that's what the token is.
>>>>> We could make it...
>>>>>
>>>>> Authorization: Bearer access_token=vF9dft4qmT
>>>>>
>>>>> If that helps with consistency.
>>>>
>>>> Well, it might seem more consistent, but I'm not sure it's worthwhile to
>>>> make the change just for that reason.
>>>>
>>>> Is it possible that the Bearer HTTP mechanism would ever take multiple
>>>> parameters? In which case, having the ability to name the parameters of the
>>>> Bearer mechanism might become more interesting.
>>>>
>>>> - John
>>>>
>>>>> I don't think we should be associating the term 'access_token' with the
>>>>> bearer security mechanism.
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>> On 6/10/11 8:35 AM, John Kemp wrote:
>>>>>>
>>>>>> What does this mean for the HTTP Authorization header naming scheme for
>>>>>> bearer tokens?
>>>>>>
>>>>>> As I understand this decision, we are discussing whether to standardize
>>>>>> on the name "access_token" when a bearer token is sent as either a URL query
>>>>>> parameter, or in a form POSTed body?
>>>>>>
>>>>>> Currently the HTTP Authorization header looks like this (from
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05
>>>>>> ):
>>>>>>
>>>>>> GET /resource HTTP/1.1
>>>>>> Host: server.example.com
>>>>>> Authorization: Bearer vF9dft4qmT
>>>>>>
>>>>>> Is the proposal then that we have:
>>>>>>
>>>>>> 1. GET /resource?access_token=vF9dft4qmT
>>>>>> 2. POST /resource
>>>>>>
>>>>>> access_token=vF9dft4qmT&...
>>>>>>
>>>>>> 3.
>>>>>>
>>>>>> GET /resource HTTP/1.1
>>>>>> Host: server.example.com
>>>>>> Authorization: access_token vF9dft4qmT
>>>>>>
>>>>>> Can someone actually give the details of the proposal, or
>>>>>> agree/disagree with the examples above?
>>>>>>
>>>>>> - John
>>>>>>
>>>>>> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote:
>>>>>>
>>>>>>
>>>>>>> Yes, that's fine with me.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> George
>>>>>>>
>>>>>>> On 6/10/11 4:20 AM, David Recordon wrote:
>>>>>>>
>>>>>>>> George, Doug and Eran are you alright with the Bearer token spec
>>>>>>>> using
>>>>>>>> the parameter name "access_token" as well?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu
>>>>>>>>
>>>>>>>> <[e-mail]>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike
>>>>>>>>> Jones<[e-mail]>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If you can drive a consensus decision for the name "access_token",
>>>>>>>>>> I'd be glad to change the name in the spec.  I agree that the current names
>>>>>>>>>> are confusing for developers.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> At Google we are getting the same feedback, that it is confusing for
>>>>>>>>> developers. It would definitely help if we could change the name to
>>>>>>>>> "access_token".
>>>>>>>>>
>>>>>>>>> Marius
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>>
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>