Nope. OAuth is a secondary goal of the MAC scheme and calling it access_token there would make no sense for anything but OAuth.
EHL > -----Original Message----- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Thursday, June 16, 2011 7:01 AM > To: KIHARA, Boku > Cc: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] consistency of token param name in bearer token > type > > If we're changing the bearer token's name, are we going to change the > parameter name inside of MAC as well? At the moment, it's "id", which I've > always found an odd naming choice. > > I would argue for consistency across the three main documents. > > -- Justin > > > On Thu, 2011-06-16 at 08:40 -0400, KIHARA, Boku wrote: > > +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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
