Seems good enough to me. +1 to removing it so that it will become fully fleshed out in a useful manner.
On Sat, Jan 15, 2011 at 11:32 AM, 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
