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
