What if strong authentication of client (between client and AM) happened OOB? Instead of passing a client_assertion, why not pass a client_token? In a sense we would be repeating the pattern for users and applying it to clients. A client use its own client_token to obtain access tokens.
I can see this approach having an advantage when a client is a web service supporting multiple end-users. It could re-use its own authentication tokens many times and wouldn't have to incur an expensive strong-authentication every time it handles an OAuth token request. The only concern I see with this, is whether a bearer token would work. You'd want to strongly bind the client with the token. IMHO Phil phil.h...@oracle.com On 2011-01-17, at 12:06 AM, Eran Hammer-Lahav wrote: > One more reason to remove the half-baked text from the spec and reintroduce > it with a full specification elsewhere. > > EHL > > From: Francisco Corella [mailto:fcore...@pomcor.com] > Sent: Sunday, January 16, 2011 11:31 PM > To: Eran Hammer-Lahav; David Recordon > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials > > 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 <record...@gmail.com> wrote: > > From: David Recordon <record...@gmail.com> > Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials > To: "Eran Hammer-Lahav" <e...@hueniverse.com> > Cc: "OAuth WG" <oauth@ietf.org> > 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 <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 > > > > -----Inline Attachment Follows----- > > _______________________________________________ > 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
