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:james.h.man...@team.telstra.com] 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 ... _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
