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

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

Yaron,

[Sorry I didn't see your response before sending my previous reply]

> SAML assertions routinely run into the 10s and even 100s of K.
> This exceeds the practical limit that most HTTP servers and proxies
> put on the size of the HTTP request headers they are willing to accept.
> So we cannot rely on the HTTP authorization header
> as a means of transporting SAML assertions.
> We are thus, as a practical matter, forced into using the request body.

So SAML assertions are impractical for authenticating/authorizing requests to a general HTTP API. Three options are:
1) Swap the assertion for session credentials that work with the API; or
2) Redefine the API to include the client assertion, which constrains the API to only use POSTs of form-encoded requests; or
3) Shrink the assertions (eg with compression or an artefact-binding) so it fits the HTTP model.

The API in question here is the OAuth2 "token endpoint" API [section 4 of draft-ietf-oauth-v2-09].
You want to take option 2 -- which sort of makes sense in this case since this API is already about swapping credentials.

This feels like a good candidate for a separate spec: "An HTTP API for obtaining an OAuth2 token with an assertion".

The proposal might jar a little less if it was part of the API definition [section 4]. It is certainly not "completely orthogonal to anything in section 4" since it adds constraints (POST and form-encoding) and applies only to the specific section 4 API and no others.

--
James Manger



From: Manger, James H [mailto:[e-mail]] 
Sent: Monday, June 28, 2010 9:38 PM

..."Assertion Client Credentials" is too much of a hack. It only works for POSTs, and only when the body is form-encoded.

It could not be used, for instance, to delete a token with an HTTP DELETE request...


From: [e-mail] [mailto:[e-mail]] On Behalf Of Yaron Goland
Sent: Tuesday, 29 June 2010 7:56 AM

The following is proposed language for a new section, 2.2, in the spec. This is part of the spec that deals with client authentication. This proposal is completely orthogonal to anything in section 4 such as grant types...

2.2 Assertion Client Credentials
...