+1 to access_token.
2011/6/16 Eran Hammer-Lahav <e...@hueniverse.com>: > It should be pretty easy :-) > > Anyone objects to changing the parameter name from 'bearer_token' to > 'access_token'? Let Mike know by 6/20 or he will make the change. > > EHL > > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Mike Jones >> Sent: Wednesday, June 01, 2011 1:15 PM >> To: David Recordon; George Fletcher >> Cc: paul Tarjan; oauth@ietf.org >> Subject: Re: [OAUTH-WG] consistency of token param name in bearer token >> type >> >> 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 > _______________________________________________ > 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
