You still need to define it. The two parameters don’t accomplish anything since you can’t use them without a more detailed specification, in which case, what is the value of this? Where is the interoperability gain?
This is clearly not a feature that is likely to be implemented in any general purpose library, unlike the ‘scope’ parameter which is under-defined but still useful for library support. Including it in the specification is confusing (the unanimous feedback I received so far), without any benefit. The specification provides a clear extension mechanism for new parameters. Why is that not enough? EHL From: Phillip Hunt [mailto:[email protected]] Sent: Saturday, January 15, 2011 12:52 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials A strong client credential is needed in many cases. I had assumed client assertion would fulfill this need. Phil Sent from my phone. On 2011-01-14, at 22:45, Eran Hammer-Lahav <[email protected]<mailto:[email protected]>> wrote: I would like to suggest we drop the client assertion credentials (-11 section 3.2) from the specification, and if needed, publish it as a separate specification for the following reasons: 1. The mechanism is under specified, especially in its handling of the client_id identifier (when used to obtain end-user authorization). It does not contain any implementation details to accomplish any level of interoperability or functionality. This is in contrast to the assertion grant type which has matured over a year into a fully thought-out extension mechanism, as well as a separate SAML assertion specification with active deployment (the two, together with running code, show clear consensus). 2. The section is a confused mix of security considerations sprinkled with normative language. Instead, it should be replaced with guidelines for extending the set of supported client credentials, but without defining a new registry. It is clearly an area of little deployment experience for OAuth, and that includes using HTTP Basic authentication for client authentication (more on that to come). 3. The section has received a little support and a little objection. Those who still want to advocate for it need to show not only consensus for keeping it, but also active community support for deploying it. Deployment, of course, will also require showing progress on public specifications profiling the mechanism into a useful interoperable feature. Comments? Counter-arguments? EHL _______________________________________________ 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
