I think it's vital to have the GET and POST parameters make sense to every developer. I worry less about the authorization header since a developer implementing it will honestly be a stronger engineer.
Here's what I said earlier in the thread about my motivation: > 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 Fri, Jun 10, 2011 at 9:34 AM, John Kemp <j...@jkemp.net> wrote: > George, > > On Jun 10, 2011, at 4:11 PM, George Fletcher wrote: > >> I definitely don't want to change the Authorization header naming scheme. I >> believe it should stay 'Bearer' because that's what the token is. We could >> make it... >> >> Authorization: Bearer access_token=vF9dft4qmT >> >> If that helps with consistency. > > Well, it might seem more consistent, but I'm not sure it's worthwhile to make > the change just for that reason. > > Is it possible that the Bearer HTTP mechanism would ever take multiple > parameters? In which case, having the ability to name the parameters of the > Bearer mechanism might become more interesting. > > - John > >> I don't think we should be associating the term 'access_token' with the >> bearer security mechanism. >> >> Thanks, >> George >> >> On 6/10/11 8:35 AM, John Kemp wrote: >>> What does this mean for the HTTP Authorization header naming scheme for >>> bearer tokens? >>> >>> As I understand this decision, we are discussing whether to standardize on >>> the name "access_token" when a bearer token is sent as either a URL query >>> parameter, or in a form POSTed body? >>> >>> Currently the HTTP Authorization header looks like this (from >>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-05 >>> ): >>> >>> GET /resource HTTP/1.1 >>> Host: server.example.com >>> Authorization: Bearer vF9dft4qmT >>> >>> Is the proposal then that we have: >>> >>> 1. GET /resource?access_token=vF9dft4qmT >>> 2. POST /resource >>> >>> access_token=vF9dft4qmT&... >>> >>> 3. >>> >>> GET /resource HTTP/1.1 >>> Host: server.example.com >>> Authorization: access_token vF9dft4qmT >>> >>> Can someone actually give the details of the proposal, or agree/disagree >>> with the examples above? >>> >>> - John >>> >>> On Jun 10, 2011, at 2:58 PM, George Fletcher wrote: >>> >>> >>>> Yes, that's fine with me. >>>> >>>> Thanks, >>>> George >>>> >>>> On 6/10/11 4:20 AM, David Recordon wrote: >>>> >>>>> George, Doug and Eran are you alright with the Bearer token spec using >>>>> the parameter name "access_token" as well? >>>>> >>>>> >>>>> On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu >>>>> >>>>> <mscurte...@google.com> >>>>> >>>>> wrote: >>>>> >>>>> >>>>>> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones <michael.jo...@microsoft.com> >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> 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. >>>>>>> >>>>>>> >>>>>> At Google we are getting the same feedback, that it is confusing for >>>>>> developers. It would definitely help if we could change the name to >>>>>> "access_token". >>>>>> >>>>>> Marius >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> 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
