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: [email protected] [mailto:[email protected]] 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
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
