Your approach fits with the "be generous in what you accept" ethos.
On 2010-06-28, at 8:02 PM, Luke Shepard wrote: > 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) >> 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 >> https://www.ietf.org/mailman/listinfo/oauth >> >> <ATT00001..txt> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
