What exactly? On Mar 8, 2011, at 18:25, "Brian Eaton" <bea...@google.com> wrote:
> This has been proven true in our deployment as well. > > On Tue, Mar 8, 2011 at 4:16 PM, Richer, Justin P. <jric...@mitre.org> wrote: >> I simply don't agree that there's much difference in practice for many >> people. >> >> -- justin >> ________________________________________ >> From: Eran Hammer-Lahav [e...@hueniverse.com] >> 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." <jric...@mitre.org> 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 [e...@hueniverse.com] >>> 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" >>> <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 >> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
