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]> 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] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
