I wanted to point out that an assertion by itself cannot authenticate the client, contrary to what the draft seems to imply.
Section 3.2 of the spec says that, when using a client assertion, the client sends two parameters: client_assertion_type and client_assertion. This does not work. A client assertion will typically bind a public key to some information about the client. Sending the assertion will not by itself authenticate the client. The client must also demonstrate that it owns the corresponding private key. To look at it from a different angle, section 3.2 also says: > The assertion format, the process by which the assertion is > obtained, and the method of validating the assertion are > defined by the assertion issuer and the authorization > server, and are beyond the scope of this specification. This misses an essential element of an assertion, what the SAML spec calls "subject confirmation" (section 2.4.1.1). Subject confirmation is not a private matter between the assertion and the authorization server, it must also involve the client, and hence it must be an integral part of the protocol. Another thing that's wrong is that the client assertion is obtained too late in the protocol flow. An assertion can provide information that the server can use to identify the client application to the user as it authenticates the user and asks for permission to grant the client application's request. But that has already been done by the time the server obtains the assertion. On the other hand I like assertions because they could help identify unregistered applications, which is what I'm trying to achieve with my PKAuth protocol. So I'm thinking about adding them to PKAuth. That should be easy, because in PKAuth the client authenticates itself by presenting its TLS certificate and demonstrating knowledge of the corresponding private key in a TLS handshake. An assertion can then simply bind additional information to the certificate, and "subject confirmation" is already taken care of. Francisco --- On Sun, 1/16/11, David Recordon <[email protected]> wrote: From: David Recordon <[email protected]> Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials To: "Eran Hammer-Lahav" <[email protected]> Cc: "OAuth WG" <[email protected]> Date: Sunday, January 16, 2011, 8:36 PM 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 <[email protected]> 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:[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]> 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 -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
