I hope this will be the last time we define a query parameter for delivering what should be sent via a request header field. Infringing on a service's namespace is always a bad idea, no matter what prefix we put next to it.
EHL From: "William J. Mills" <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>> Reply-To: "William J. Mills" <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>> Date: Tue, 8 Mar 2011 10:11:46 -0700 To: Justin Richer <jric...@mitre.org<mailto:jric...@mitre.org>> Cc: OAuth WG <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft So is a different namespace for each new mechanism right, or should a parameter be added to parallel the authorization scheme name? Seems like it would be clean to define oauth_scheme and use the same value as defined for the auth scheme name. ________________________________ From: Justin Richer <jric...@mitre.org<mailto:jric...@mitre.org>> To: William J. Mills <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>> Cc: Brian Eaton <bea...@google.com<mailto:bea...@google.com>>; OAuth WG <oauth@ietf.org<mailto: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<mailto:jric...@mitre.org>> > To: Brian Eaton <bea...@google.com<mailto:bea...@google.com>> > Cc: OAuth WG <oauth@ietf.org<mailto: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<mailto: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<mailto:phil.h...@oracle.com> > > > > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org<mailto:OAuth@ietf.org> > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org<mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
