Scope was discussed in detail, including use cases and implementation experience and the current language was (painfully) negotiated to reach a balance between flexibility and library interoperability. Client password authentication is well understood, is the primary way API calls are authenticated on the web today (API key and secret), it is how OAuth 1.0 defined client authentication, and enjoys numerous examples throughout the specification for each authorization grant type. Got other examples?
Adding the proposed text in is not an option given the objections raised. This process argument is moot because whether we put it back in or not before we reach consensus on the language, it will take the same amount of time to do just that – reach consensus. Drafting another spec will give us the time to properly discuss it and reach a useful, fully specified document with examples and other details that otherwise will delay this document. We followed this exact process for the SAML assertions specification. In addition, everything in the spec right now is specified in enough detail to write the security consideration section. I have no clue how anyone can describe the security characteristics of this proposed text given that it has absolutely no details helpful to evaluate its security properties. This makes your opening paragraph in the proposed text someone of a tongue in cheek. “When passwords are not enough, use this strong and completely undefined method”. We will only make progress on this if you stop trying to use process arguments (since as David pointed out, this was put into the spec in violation of our process and I apologize for that), and start working towards a language the WG can agree on. EHL From: Anthony Nadalin [mailto:tony...@microsoft.com] Sent: Tuesday, January 25, 2011 5:32 PM To: David Recordon; hannes.tschofe...@gmx.net; Eran Hammer-Lahav Cc: OAuth WG; Blaine Cook Subject: RE: [OAUTH-WG] Removal: Client Assertion Credentials Based on your logic then Scope, Client Password Authentication, etc, should be removed. Not sure how leaving the proposed text in would delay things From: David Recordon [mailto:record...@gmail.com] Sent: Tuesday, January 25, 2011 5:11 PM To: Anthony Nadalin; hannes.tschofe...@gmx.net; Eran Hammer-Lahav Cc: OAuth WG; Blaine Cook Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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<mailto: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.) [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<http://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> [mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
