That's because I'm focused on my use case, which is using the Authorization header. In query args/form parameters we definitely need better differentiation.
________________________________ From: Justin Richer <jric...@mitre.org> To: William J. Mills <wmi...@yahoo-inc.com> Cc: Brian Eaton <bea...@google.com>; OAuth WG <oauth@ietf.org> Sent: Tuesday, March 8, 2011 8:41 AM Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I don't understand this comment. If you're using query/form parameters, there are no schemes involved in the process. -- Justin On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: > A major difference is now there is a scheme name that is > differentiating. You no longer have to parse the entire variable set > to figure out what is going on. Now the scheme name determines > things. Now that we have schemes I don't see re-using parameter names > as a problem. > > > > > ______________________________________________________________________ > From: Justin Richer <jric...@mitre.org> > To: Brian Eaton <bea...@google.com> > Cc: OAuth WG <oauth@ietf.org> > Sent: Tuesday, March 8, 2011 7:11 AM > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > 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 > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
