There is an explanation (I'm not defending it, just explaining). In the flow endpoint I chose 'access_token' over token because of the refresh token. It seems better to talk about two different kinds of tokens than to have one generic 'token' and one with special meaning 'refresh_token'.
The protected resource endpoint is the only place I agree requires a prefix because it always intrudes on another namespace or platform and the likelihood of a conflict is high. I used 'oauth_token' instead of 'oauth_access_token' for brevity thinking that it should be trivial to figure out what to put there (the only other option is a refresh token which isn't likely to be confused here). The header uses 'token' because it is a generic authentication scheme which doesn't mandate you use the OAuth flows to get a token. This is the only place I feel strongly about not changing it. Feel free to propose new names. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Luke Shepard > Sent: Tuesday, April 20, 2010 12:46 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Consistency in access token parameter > > There are potentially three names for access tokens in this spec: > > - token > - access_token > - oauth_token > > You hit the /oauth/access_token endpoint, and get back access_token=blah. > Then you take that string and pass it to the protected resource as > oauth_token=blah. > > Developers that have prototyped things over here have found this to be > confusing. It's simpler to just take the same named param everywhere. > > I vote that one of two things happen: > > 1/ Return oauth_token from the access token endpoint. > 2/ Accept access_token on the protected resource endpoint. > 3/ Return "token" (and still "refresh_token") from the access_token > endpoint, and accept "token" on the protected resource. > > I know there will be infinite debate about the right way to do this, but just > wanted some thoughts for now. I will probably choose #2 as that seems most > explicit, even though it's a few more characters. > > _______________________________________________ > 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
