For what it's worth, I (Facebook) would not require my clients to specify a type. It's fine to discuss it in the docs and examples, but if a client passed in a request without a type, I would probably try to infer the grant type from the request rather than throwing an error.
Besides the purity of the spec, would anyone object to a server that tried to play nice by its clients? On Jun 28, 2010, at 6:42 PM, Eran Hammer-Lahav wrote: I don’t care about the name (type vs method). Are there any objection to defining a parameter for the client authentication method? Any views about using this parameter with an HTTP authorization header? EHL From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Monday, June 28, 2010 12:25 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re: [OAUTH-WG] Client credentials type While the AS implementor can infer the request by the parameters, I prefer the programmer explicitly state what she is doing. Thinking of it as a method parameter rather than a type parameter makes more sense to me. Similiarly, HTTP has GET, POST, PUT etc. even though you could differentiate between them by looking at what was passed or not passed. -- Dick On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrote: Yaron Goland offered a proposal for an additional client credentials mechanism based on assertion. His proposal raises the issue of differentiating between the different kind of credentials used. When it comes to access grant types, this group argued for being explicit and providing a parameter declaring the grant type being used (even though it is not technically necessary). While I don’t believe a grant or credential type parameter is needed – the type can be deduced from the other parameters present – we now treat the same requirement with a different solution. I think this creates a broken environment for extensibility (which is my current focus). At the same time, introducing such a parameter can conflict with the standard HTTP authentication mechanism. For example, a request containing both “client_credentials_type=basic” and the HTTP Authorization header seems odd. There are a few ways to address this: 1. Only use a type parameter when the credentials are passed using parameters and not a header. 2. Only allow HTTP headers for authentication, while “grandfathering-in” the client_secret parameter to simplify the most common current practice. 3. Leave is underspecified, relying on the presence of extension parameters or authentication headers for other credentials types. Thoughts? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
