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.
-- Mike
-----Original Message-----
From: David Recordon [mailto:record...@gmail.com]
Sent: Wednesday, June 01, 2011 12:06 AM
To: George Fletcher
Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan
Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type
Yeah, can understand how we got here. Just found it quite confusing when
reading these two specifications together with an implementor's hat on.
On Tue, May 31, 2011 at 12:29 PM, George Fletcher <gffle...@aol.com> wrote:
> Brief pointer to the "history" of this change. This change was adopted
> in draft 4 of the bearer spec as there were concerns with the previous
> parameter name of 'oauth_token'. The suggestion was made to use
> 'bearer_token' so that it matches the scheme used in the Authorization
> header. The thinking being that reading the bearer token spec would
> seem weird if the Authorization header used one name and the GET/POST
> methods used a different name.
>
> The 'bearer_token' name got a few +1 and no dissents.
>
> Full thread starts here [1]. Mike accepting the 'bearer_token'
> recommendation is here [2].
>
> Thanks,
> George
>
> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html
>
> On 5/28/11 12:30 PM, David Recordon wrote:
>
> 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 Mon, May 23, 2011 at 11:38 AM, Mike Jones
> <michael.jo...@microsoft.com> wrote:
>
> The working group explicitly decided that a different name should be
> used, to make it clear that other token types other than bearer tokens
> could also be used with OAuth 2.
>
>
>
> -- Mike
>
>
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Doug Tangren
> Sent: Wednesday, May 11, 2011 10:09 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] consistency of token param name in bearer token
> type
>
>
>
> This may have come up before so I'm sorry if I'm repeating. Why does
> bearer token spec introduce a new name for oauth2 access tokens [1],
> "bearer_token", and before that [2], "oauth_token"?
>
>
>
> I apologize if this may sound shallow but, why introduce a new
> parameter name verses sticking with what the general oauth2 spec
> already defines, "access_token". It seems arbitrary for an auth server
> to hand a client an apple then have the client hand it off to the
> resource server and call it an orange.
>
>
>
> Was this just for the sake of differentiating the parameter name
> enough so that the bearer tokens may be used in other protocols
> without being confused with oauth2 access_tokens?
>
>
>
> [1]:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2
>
> [2]:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2
>
>
>
> -Doug Tangren
> http://lessis.me
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Chief Architect AIM: gffletch
> Identity Services Engineering Work: george.fletc...@teamaol.com
> AOL Inc. Home: gffle...@aol.com
> Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com
> Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
