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

["Manger, James H" <[e-mail]>]

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