This has been proven true in our deployment as well.
On Tue, Mar 8, 2011 at 4:16 PM, Richer, Justin P. <[email protected]> wrote: > I simply don't agree that there's much difference in practice for many people. > > -- justin > ________________________________________ > From: Eran Hammer-Lahav [[email protected]] > Sent: Tuesday, March 08, 2011 7:08 PM > To: Richer, Justin P.; William J. Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > No. > > There is a huge difference between adding parameters to protected > resources and defining parameter for OAuth specific endpoints (which may > create conflicts with existing frameworks). > > One is an invasion of the provider's namespace where OAuth has no business > messing around. The other is a potential deployment issue. > > EHL > > > On 3/8/11 3:48 PM, "Richer, Justin P." <[email protected]> wrote: > >>Except that we're also infringing on service provider namespaces for our >>other endpoints as well. Not every service provider can or will create a >>pristine endpoint for tokens or authorizations, but this working group >>has had no problems putting all kinds of parameters into that space. >>Unless we want to say that we can't use query or form parameters in >>specifications ever again, this argument doesn't really hold up. >> >> -- Justin >>________________________________________ >>From: Eran Hammer-Lahav [[email protected]] >>Sent: Tuesday, March 08, 2011 1:02 PM >>To: William J. Mills; Richer, Justin P. >>Cc: OAuth WG >>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" >><[email protected]<mailto:[email protected]>> >>Reply-To: "William J. Mills" >><[email protected]<mailto:[email protected]>> >>Date: Tue, 8 Mar 2011 10:11:46 -0700 >>To: Justin Richer <[email protected]<mailto:[email protected]>> >>Cc: OAuth WG <[email protected]<mailto:[email protected]>> >>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 <[email protected]<mailto:[email protected]>> >>To: William J. Mills <[email protected]<mailto:[email protected]>> >>Cc: Brian Eaton <[email protected]<mailto:[email protected]>>; OAuth WG >><[email protected]<mailto:[email protected]>> >>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 <[email protected]<mailto:[email protected]>> >>> To: Brian Eaton <[email protected]<mailto:[email protected]>> >>> Cc: OAuth WG <[email protected]<mailto:[email protected]>> >>> 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 >>><[email protected]<mailto:[email protected]>> >>> 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 >>> > > [email protected]<mailto:[email protected]> >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > OAuth mailing list >>> > > [email protected]<mailto:[email protected]> >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > > >>> > > >>> > _______________________________________________ >>> > OAuth mailing list >>> > [email protected]<mailto:[email protected]> >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected]<mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >> >> >> >> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
