It just needs to be defined properly. I was speaking only to the requirement. Not whether what is spec'd now is good or not.
I will blog more on this shortly. Cheers, Phil Sent from my phone. On 2011-01-15, at 11:32, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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:phil.h...@oracle.com] > 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 <e...@hueniverse.com> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
