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.) [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
