I agree with your point of view.
Consequentely, the parameter name should be something like "bearer_token"?
regards,
Torsten.
Am 25.02.2011 20:49, schrieb Brian Eaton:
My two cents:
We've already taken three user visible outages because the OAuth2 spec
reused the "oauth_token" parameter in a way that was not compatible
with the OAuth1 spec.
Luckily they were all caught before they caused serious damage.
Generic parameter names are not useful. They lead to confused
developers and confused code. If code needs to treat the values
differently, the names should be different as well.
Cheers,
Brian
On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt<phil.h...@oracle.com> wrote:
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
instead of
GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: 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
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
