'oauth_token' is limited to bearer tokens only. It is not suitable for anything else. It is a hack and should be treated as such. The right (extensible) solution is to use the HTTP Authorization header, which comes with its own extensibility model.
EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Friday, February 25, 2011 2:41 PM To: Mike Jones Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft Mike, Thanks, I just noticed you addressed the change to "BEARER" in draft 03 (just published). I could live with the parameter name oauth_token, provided we can sub-type (rather then be generic). E.g. GET /resource?oauth_token=BEARER+vF9dft4qmT Either way, I suspect this is a breaking change unless we specify that no prefix (i.e. as with authorization header) refers to the legacy case. Which I could also live with. If we don't then the value of OAUTH_TOKEN (or authorization_token) becomes unclear. I think this will cause some major issues that some will consider bugs in the spec. Phil phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2011-02-25, at 2:24 PM, Mike Jones wrote: Hi Phil, Yes, per the working group vote, we decided on the name "Bearer". This name is used in the just-published draft -03. This draft did not change the oauth_token parameter name; as editor, I am not introducing breaking changes at this point unless directed to do so by a vote of the working group. I agree with your consistency goal among the related specs. One step I took in this draft towards that end in the latest draft was establishing the OAuth Errors registry and extending the scope of the OAuth Parameters registry; the goal is that inconsistencies in error and parameter names among related specs will be more likely to be identified and corrected at specification time, rather than at spec usage time. Best wishes, -- Mike From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Friday, February 25, 2011 11:38 AM To: OAuth WG Subject: [OAUTH-WG] OAuth Bearer Token draft There was some discussion on the type for the authorization header being OAUTH / MAC / BEARER etc. Did we have a resolution? As for section 2.2 and 2.3, should we not have a more neutral solution as well and use "authorization_token" instead of oauth_token. The idea is that the parameter corresponds to the authorization header and NOT the value of it. The value of such a parameter an be an encoded value that corresponds to the authorization header. For example: GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host: server.example.com<http://server.example.com/> instead of GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: server.example.com<http://server.example.com/> The concern is that if for some reason you switch to "MAC" tokens, then you have to change parameter names. Why not keep them consistent? Apologies if this was already resolved. Phil phil.h...@oracle.com<mailto:phil.h...@oracle.com>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
