Explicitly saying, "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" seems to reinforce the point about this being underspecified. This would still require a second document which describes the data within the SAML assertion as well as how it maps back to a client_id.
On the process side, IIRC this was added to the spec without any consensus and over some reservations by Eran...which was a broken process to begin with and a poor decision on his part. I share Hannes' desire to move this base spec to last call. Worried that leaving this text in is going to delay that whereas moving it to a separate document published by the OAuth WG will still lead toward market adoption of a more fully specified feature. --David On Tue, Jan 25, 2011 at 3:58 PM, Anthony Nadalin <tony...@microsoft.com>wrote: > I don't understand the rationale for removing the client assertion > credentials, as client password authentication is left in. Client Password > Authentication is also underspecified as client_secret could be anything > that the authentication server seems fit (raw clear text password, hash, > digest, etc.) and no way to determine the content. client_secret is also a > very weak mechanism, since this is left in the core this leads me to believe > that there is support for having client authentication in Oauth. I don't see > how having client_assertion and client_assertion_type would be something > that is underspecified as being a mechanism in which assertions can be used > for authentication. Agree that the authentication server has to make right > and declare what is being used but that is the same for client password > authentication. The client authentication assertions are something that > Microsoft and Google find useful and plan on implementing and using as a > means for stronger authentication to the authorization server. This > extensibility belongs in the core, there is no other place to put this > functionality. I don't believe that the removal (either by editor or > direction by co-chair) is something that should have been done w/o a > consensus vote since this has been in the specification for some time > without issue and the removal comes as complete unwelcome surprise. Getting > almost total rewrites of the specification this late in the review cycle is > also very disturbing. > > > > A proposal for keeping the client authentication assertion would be to > simplify to the following; > > The client assertion credentials are used in cases where a password > (clear-text shared symmetric secret) is unsuitable or does not provide > sufficient security for client authentication. The client assertion > credentials provide an extensible mechanism to use an assertion format > supported by the authorization server for authentication of the client. > > Using assertions requires the client to obtain an assertion (such as a SAML > (Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol > for the OASIS Security Assertion Markup Language (SAML) V2.0," March > 2005.)<#12dbf9d29a2ee7cd_OASIS.saml-core-2.0-os>[OASIS.saml-core-2.0-os] > assertion) from an assertion issuer or to > self-issue an assertion. 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. > > When using a client assertion, the client includes the following > parameters: > > client_assertion_type - REQUIRED. The format of the assertion as defined > by the authorization server. The value MUST be an absolute URI. > > client_assertion - REQUIRED. The client assertion. > > For example, the client sends the following access token request using a > SAML 2.0 assertion to authenticate itself (line breaks are for display > purposes only): > > > > > > POST /token HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > > > grant_type=authorization_code&code=i1WsRn1uB1& > > client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D& > > client_assertion_type= > urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > > > > > > > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Eran Hammer-Lahav > *Sent:* Friday, January 14, 2011 10:45 PM > *To:* OAuth WG > *Subject:* [OAUTH-WG] Removal: Client Assertion Credentials > > > > 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
