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:[email protected]]
> Sent: Wednesday, June 30, 2010 9:18 PM
> To: Yaron Goland; [email protected]
> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
