If there was an actual reason to think more of these will be needed. The only attractive feature of bearer tokens are their simplicity. There can be nothing simpler. And as such, sending them over in a query parameter has obvious benefits inline with this simplicity (with the well-known security issues that must be taken into consideration).
The reasons for supporting query GET parameters and body POST parameters are ease of use and client limitations in accessing the authorization header. The second is pretty much a non-issue at this point (it was 3 years ago when 1.0 was released). Every other token type is going to be more complex and will require more parameters than just the token. In such an environment, a single parameter name will not be helpful. Using a parameter prefix might be, but it just gets ugly (oauth_bearer_token, oauth_something_signature, etc.). My point is that instead of building yet another extension point, we should come up with a reasonable solution for bearer tokens and simply state that we do not expect any other token type to use this method. That all other token types should use an HTTP header, or a special multi-part body. 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 11:46:06 -0700 To: Eran Hammer-lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>>, 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 Then a single extra reservation is preferable to N, yes? From: Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> To: William J. Mills <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>>; Justin Richer <jric...@mitre.org<mailto:jric...@mitre.org>> Cc: OAuth WG <oauth@ietf.org<mailto:oauth@ietf.org>> Sent: Tuesday, March 8, 2011 10:02 AM Subject: Re: [OAUTH-WG] OAuth Bearer Token draft 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
