Re: [OAUTH-WG] consistency of token param name in bearer token type

[Eran Hammer-Lahav <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Mike Jones
> Sent: Wednesday, June 01, 2011 1:15 PM
> To: David Recordon; George Fletcher
> Cc: paul Tarjan; [e-mail]
> 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:[e-mail]]
> Sent: Wednesday, June 01, 2011 12:06 AM
> To: George Fletcher
> Cc: Mike Jones; Doug Tangren; [e-mail]; 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 <[e-mail]>
> 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
> > <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Doug Tangren
> > Sent: Wednesday, May 11, 2011 10:09 PM
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > --
> > Chief Architect                   AIM:  gffletch
> > Identity Services Engineering     Work: [e-mail]
> > AOL Inc.                          Home: [e-mail]
> > Mobile: [phone]           Blog: http://practicalid.blogspot.com
> > Office: [phone]           Twitter: http://twitter.com/gffletch
> >
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth