Re: [OAUTH-WG] Proposal for text for section 2

[Yaron Goland <[e-mail]>]

James, in theory I agree with you that we should use the authorization header. Unfortunately the reality of how implementations work prevent that as a viable option. So for corporate scenarios where we need SAML we will have to put the parameters into the request body. I do not see a viable way to standardize that outside the context of a particular protocol since it requires using the request body which is owned by each protocol. So we will have to extend OAuth directly to support this usage. It is of course the working group's choice if they want to include the mechanism directly in the OAuth spec or as an extension. 

As for the distinction between client assertion/client assertion type and assertion/assertion type it is identical to the difference between client id/client secret and username/password.

	Thanks,

		Yaron

> -----Original Message-----
> From: Manger, James H [mailto:[e-mail]]
> Sent: Wednesday, June 30, 2010 9:18 PM
> To: Yaron Goland; [e-mail]
> Subject: RE: Proposal for text for section 2
> 
> Yaron,
> 
> > how can you ding client assertions credentials for doing exactly what client
> basic credentials do?
> 
> I don't like client basic credentials in request bodies either. We should ditch
> that as well. I am sure I have dinged it in the past. It offers too little benefit
> for the cost of confusing APIs (& code) by mixing the content and
> authentication. And you lose a well-established discovery method: a
> response with WWW-Authenticate: BASIC ....
> 
> At least with basic credentials they can fit in a URI. Consequently, they don't
> prevent GET, HEAD, or DELETE requests, or even non-form PUT and POST
> requests in an API. Plus the Authorization header equivalent approach
> always works as well.
> [You can almost consider an "endpoint with client_id and client_secret" as a
> single base URI for the API -- and almost pretend that it doesn't compromise
> the HTTP model.]
> 
> 
> > How about we edit the client assertion proposal to include the ability to put
> assertions both in the HTTP authorization header as well as in the body? Then
> the assertion proposal will be 100% equivalent to the existing basic
> credentials proposal.
> 
> It is hardly 100% equivalent when the header option will fail in some cases
> (large assertions), and the other option fails for GETs, HEADs, DELETEs, and
> non-form requests.
> 
> 
> I would like OAuth2 to say: "The token API will often require client auth; a
> service MAY support any auth mechanisms; BASIC is a recommended
> mechanism; BASIC MUST be supported if the service issues shared secrets to
> clients".
> Using a client assertion would fit right in if it could be defined as a standalone
> HTTP auth mechanism (even with a option to use form params for POSTs of
> forms). This would be best as its own standalone spec.
> 
> If such a spec gets support (despite sometimes failing for non-POST or non-
> form requests), we are done. If such a spec isn't supported it suggests we
> should define a specific API that accepts client assertions, instead of an
> "orthogonal" auth mechanism (still best in its own spec).
> 
> 
> P.S. When are client_assertion/client_assertion_type used, as opposed to
> assertion/assertion_type? It is not clear to me from the existing and
> proposed spec text. I don't think the OAuth2 spec has enough context for
> the assertion parts. It would be better outside the OAuth2 spec, where more
> details could be provided about how it hooks up with the rest of a claims-
> based system.
> 
> --
> James Manger