The biggest problem that I can see are the examples and terminology in the core doc, which tries very hard to not look like it is binding to any particular use-a-token spec or token format. That plus the history that George pointed out below (which I still very strongly believe that 'oauth_token' should not be used as that's been claimed by OAuth1) got us here today.
One of the downsides to splitting this into three specs is that we need to be more consistent across them. -- Justin On Wed, 2011-06-01 at 03:06 -0400, David Recordon wrote: > 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
