James, how can you ding client assertions credentials for doing exactly what
client basic credentials do?
The current spec defines that client basic credentials can go into the request
body and defines this behavior in section 2. I just patterned the client
assertion credentials text word for word from the existing basic credentials
text.
That having been said I wonder if there isn't a simple compromise here. 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.
After all, if we do have an assertion that is small enough to fit in the header
I'd rather see it there than in the body. I personally only want the body as an
emergency escape hatch. I'm certainly no fan of shoving this kind of stuff in
the request body.
What do you think?
Yaron
> -----Original Message-----
> From: Manger, James H [mailto:james.h.man...@team.telstra.com]
> Sent: Tuesday, June 29, 2010 7:30 PM
> To: Yaron Goland; oauth@ietf.org
> Subject: RE: Proposal for text for section 2
>
> 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
