Or just a bit of XML signatures and encryption. The byte bloat is astounding.
Yaron
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Tuesday, June 29, 2010 11:49 PM
> To: Yaron Goland
> Cc: Marius Scurtescu; OAuth WG (oauth@ietf.org)
> Subject: RE: [OAUTH-WG] Client credentials type
>
> that's pretty big! Can you please explain what kind of client you authenticate
> with such assertions? They must contain hundreds of attributes.
>
> regards,
> Torsten.
>
> Zitat von Yaron Goland <yar...@microsoft.com>:
>
> > We regularly deal with SAML assertions that easily go into the 100s of
> > K. This is far more than most HTTP servers will accept. So we are
> > pretty much required to use the body.
> >
> >> -----Original Message-----
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> >> Behalf Of Torsten Lodderstedt
> >> Sent: Monday, June 28, 2010 12:26 PM
> >> To: Marius Scurtescu
> >> Cc: OAuth WG (oauth@ietf.org)
> >> Subject: Re: [OAUTH-WG] Client credentials type
> >>
> >> what size do you expect? SPNEGO authentication headers can be up to
> >> 12392 bytes and this does not seem to be a problem.
> >>
> >> regards,
> >> Torsten.
> >>
> >> Am 28.06.2010 21:19, schrieb Marius Scurtescu:
> >> > Only HTTP headers may not be enough. In Yaron's proposal, the
> >> > assertion could be a SAML assertion, and these could be too large
> >> > for headers.
> >> >
> >> > I think #1 makes sense.
> >> >
> >> > Marius
> >> >
> >> >
> >> >
> >> > On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt
> >> > <tors...@lodderstedt.net> wrote:
> >> >
> >> >> I would prefer (2) since authorization headers are the natural way
> >> >> to handle authentication in HTTP. Different client credential
> >> >> mechanisms can be represented by different authentication scheme
> >> >> (even custom-defined). HTTP libraries typically have special
> >> >> support for handling such headers and it keeps the authentication
> >> >> mechanism orthogonal of the API. Moreover, authorization headers
> >> >> very well work together with status code 401 and WWW-Authenticate
> >> >> headers. Using WWW-Authenticate headers, an authz server can
> >> >> easily signal what mechanisms (multiple WWW-Authenticate headers
> >> >> are allowed in a single
> >> HTTP response) it accepts for a particular request.
> >> >>
> >> >> regards,
> >> >> Torsten.
> >> >>
> >> >> Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav:
> >> >>
> >> >> Yaron Goland offered a proposal for an additional client
> >> >> credentials mechanism based on assertion. His proposal raises the
> >> >> issue of differentiating between the different kind of credentials
> >> >> used. When it comes to access grant types, this group argued for
> >> >> being explicit and providing a parameter declaring the grant type
> >> >> being used (even though it is not technically necessary).
> >> >>
> >> >>
> >> >>
> >> >> While I don't believe a grant or credential type parameter is
> >> >> needed
> >> >> - the type can be deduced from the other parameters present - we
> >> >> now treat the same requirement with a different solution. I think
> >> >> this creates a broken environment for extensibility (which is my
> >> >> current
> >> focus).
> >> >>
> >> >>
> >> >>
> >> >> At the same time, introducing such a parameter can conflict with
> >> >> the standard HTTP authentication mechanism. For example, a request
> >> >> containing both "client_credentials_type=basic" and the HTTP
> >> >> Authorization header seems odd.
> >> >>
> >> >>
> >> >>
> >> >> There are a few ways to address this:
> >> >>
> >> >>
> >> >>
> >> >> 1. Only use a type parameter when the credentials are passed using
> >> >> parameters and not a header.
> >> >>
> >> >> 2. Only allow HTTP headers for authentication, while
> >> >> "grandfathering-in" the client_secret parameter to simplify the
> >> >> most
> >> common current practice.
> >> >>
> >> >> 3. Leave is underspecified, relying on the presence of extension
> >> >> parameters or authentication headers for other credentials types.
> >> >>
> >> >>
> >> >>
> >> >> Thoughts?
> >> >>
> >> >>
> >> >>
> >> >> EHL
> >> >>
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> >>
> >> >>
> >> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
