Re: [OAUTH-WG] Removal: Client Assertion Credentials

[Phil Hunt <[e-mail]>]

Tony,

I'm not totally understanding what the issue is as far as impact on code. My understanding was that the removal simply took it out of the standard but is still covered by "other authentication mechanism".  Thus no impact on code -- you can still use (as we will) the client_assertion form parameter. That said, I very much agree with your concerns.

It may be worthwhile for us to work on a profile that lays out the specifics of using client_assertion or client_token in a separate specification. Just as there will be multiple access token formats, I expect to see multiple client authentication methods.  Maybe client auth methods should also be defined in a registry? Though, I don't see this as necessarily an OAuth specific issue. There's a much broader requirement for defining client auth beyond Basic, Digest, Mutual SSL, etc for non-browser clients. 

As for value with OAuth, I think OAuth describe an important "pattern" and won't have much general impact on inter-operability as a standard. Thus doesn't undervalue the standard that much as it lays a foundation for other components. The key working inter-op components will likely have be defined in subsequent related specs such as suggested above.

What is not clear to me yet is what should the discovery and registration components for OAuth be? How much should be defined in deployment documentation? Deployment documentation is problematic for development tools. For example, building a .Net or Java platform is much different than a one time developer who just wants to access a single google, facebook, etc service.  In contrast, .Net/Java tools can't help much since they can't inspect the service. 

I agree, too much emphasis is on deployment docs for use of OAuth.

Phil
[e-mail]




On 2011-01-28, at 11:55 AM, Anthony Nadalin wrote:

> I said its “becoming” useless as more and more stuff is being removed.
>  
> Maybe you did not understand or I did not tell you everything you needed to know, we have endpoints that expect assertions along with the grant_type of authorization_code and we also have endpoints that expect the grant_type of URI (or the assertion, which could be whatever the authorization server decides), these are 2 different endpoints with 2 different functions. The change that was made to remove the notion of client assertion credentials only left us with the extension so we can live with the changes to the extension (it is a code change for us) but not removal of client assertion credentials we can’t live with as we are using the notion of client credentials. I’m not sure that putting this in the bearer token specification would work.
>  
>  
> From: Eran Hammer-Lahav [mailto:[e-mail]] 
> Sent: Wednesday, January 26, 2011 2:51 PM
> To: Anthony Nadalin
> Cc: OAuth WG
> Subject: RE: Removal: Client Assertion Credentials
>  
> Can you explain how having to define *two* extension parameters makes the specification useless? The bearer token specification is going to define its corresponding WWW-Authenticate header, to match its already defined Authorization header. The scheme name is just style and branding and have absolutely no technical impact. I am honestly confused by your comments, as I was in the past when you declared the entire protocol useless because of my objections to an under-defined scope parameter.
>  
> Can you point me where in WRAP are the client assertion credentials defined? I can only find the assertion profile which is comparable to the extension grant type with the SAML assertion extension (where the assertion parameter is defined and registered). The concept of the client assertion used for client authentication (separate from the authorization grant) is new and was added based on a proposal from Yaron in -11 on December 1st, 2010.
>  
> As for your additional details below (thanks!), it seems like you are not using the client assertion credentials at all but using a simple extension grant with an assertion, exactly like the SAML extension grant specification, only you are not limited to SAML 2.0. Is that correct? If this is correct, then the only issue here is our decision (which was made without any comment from you or those now raising issues about this) to move the ‘assertion’ parameter and rename the grant type from assertion to extension (which has no implementation impact). All we did is relocate the assertion parameter because it doesn’t always apply to extension grants.
>  
> Is this just a confusion about what was being removed and where it went?
>  
> EHL
>  
>  
> From: Anthony Nadalin [mailto:[e-mail]] 
> Sent: Wednesday, January 26, 2011 1:52 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: RE: Removal: Client Assertion Credentials
>  
> Maybe this was the plan all along but specification is becoming useless for our scenarios and will require that we have to go well beyond the core specification to make things work, the client assertion credentials being a prime example. The client assertion credentials has been around for a while as it was a requirement for WRAP, then dropped when the various specs got merged to form OAUTH 2.0 and then came back into the OAUTH 2.0 and then has gone through various changes since version 6 for the worse. There has been much discussion in July/August over this and new text was proposed, but that seems to not be fully accepted, but I think that follows the path when you want to remove something.
>  
> Our usage will be via bearer token assertions only (at this time)
> The grant_type would be the URI of the assertion type being used
> The authorization endpoint can use what it wants to bind the assertion to the client_id, much like it has to today for the password authentication, as we have scenarios were client_id have multiple passwords
> We use guidance from security consideration section of the assertion type being used along with the guidance from the bearer token specification
> If needed I can capture the assertions and requests, but not sure what the point of this is at this time since this is not required for the password credentials
>  
> Sure we can add the client authentication assertion to the bearer token specification but I don’t think that is the proper place to do thus but since it’s gone from the core we will have to do just that. The same seems to happen with the HTTP Authentication Scheme as it seems to be repeated in follow-on companion specifications. While oauth-v2 is not an authentication protocol there is a requirement for authentication to address security concerns. There is clear separation between authentication and authorization; we are not suggesting that authentication is appropriate facility to negotiate authorization. I think that it makes sense to include a scheme in the core and have the particular follow-on companion specifications (the various token specifications) state/define the parameters and if they don’t like the default scheme let them define a new scheme but this puts a stake in the ground for an HTTP Authentication Scheme.
>  
>  
> From: Eran Hammer-Lahav [mailto:[e-mail]] 
> Sent: Tuesday, January 25, 2011 5:38 PM
> To: Anthony Nadalin
> Cc: OAuth WG
> Subject: RE: Removal: Client Assertion Credentials
>  
> Can you share with the list how you plan to use this client assertion authentication scheme?
> Which of the authorization grant types you will use it with?
> Will you use it with the authorization endpoint, and if so, how will you bind the assertion to the client_id?
> Can you provide full examples of assertions and HTTP requests?
>  
> It would be helpful to see how far apart the proposed text below is from an actual implementation making use of it. I except to see these answers in any quality document defining a new client authentication scheme (which is true for the client password authentication throughout the document).
>  
> EHL
>  
>  
> From: Anthony Nadalin [mailto:[e-mail]] 
> Sent: Tuesday, January 25, 2011 3:58 PM
> To: Eran Hammer-Lahav; OAuth WG; [e-mail]; Blaine Cook
> Subject: RE: Removal: Client Assertion Credentials
>  
> 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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth