Very strongly agree, repeat my suggestion to name the parameter "oauth2_token".
-- Justin On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: > 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
