> -----Original Message----- > From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] > Sent: Thursday, June 16, 2011 1:26 AM > To: Eran Hammer-Lahav; Mike Jones; David Recordon; George Fletcher > Cc: paul Tarjan; oauth@ietf.org > Subject: AW: [OAUTH-WG] consistency of token param name in bearer > token type > > The reason why I suggested the name "bearer_token" was to achieve a > consistent naming convention across different ways to uses those tokens > (URI query, HTTP authn scheme). Now the discussion centers around > achieving a consistent naming between token acquisition and usage. I'm > basically fine with reverting to "access_token". > > Just one question: > Is the assumption of the group that bearer tokens are the only type of > tokens to be used in conjunction with URI query parameters? Otherwise, a > mechanism is needed to distinguish bearer and other tokens, e.g. another > parameter (token_type?).
YES (i.e. no more). It's bad enough we have this one. EHL > Regards, > Torsten. > > -----Ursprüngliche Nachricht----- > > Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > > Gesendet: Mittwoch, 15. Juni 2011 19:38 > > An: Mike Jones; David Recordon; George Fletcher > > Cc: paul Tarjan; oauth@ietf.org > > Betreff: Re: [OAUTH-WG] consistency of token param name in bearer > > token type > > > > 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
