Re: [OAUTH-WG] Client credentials type

[Yaron Goland <[e-mail]>]

Oh and don't forget fun things like including the full cert chain which after encoding also bloats to amazing heights.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Yaron Goland
> Sent: Wednesday, June 30, 2010 5:39 PM
> To: Torsten Lodderstedt
> Cc: OAuth WG ([e-mail])
> Subject: Re: [OAUTH-WG] Client credentials type
> 
> Or just a bit of XML signatures and encryption. The byte bloat is astounding.
> 
> 		Yaron
> 
> > -----Original Message-----
> > From: Torsten Lodderstedt [mailto:[e-mail]]
> > Sent: Tuesday, June 29, 2010 11:49 PM
> > To: Yaron Goland
> > Cc: Marius Scurtescu; OAuth WG ([e-mail])
> > 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 <[e-mail]>:
> >
> > > 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: [e-mail] [mailto:[e-mail]] On
> > >> Behalf Of Torsten Lodderstedt
> > >> Sent: Monday, June 28, 2010 12:26 PM
> > >> To: Marius Scurtescu
> > >> Cc: OAuth WG ([e-mail])
> > >> 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
> > >> > <[e-mail]>  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
> > >> >> [e-mail]
> > >> >> https://www.ietf.org/mailman/listinfo/oauth
> > >> >>
> > >> >>
> > >> >> _______________________________________________
> > >> >> OAuth mailing list
> > >> >> [e-mail]
> > >> >> https://www.ietf.org/mailman/listinfo/oauth
> > >> >>
> > >> >>
> > >> >>
> > >>
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> > >
> >
> >
> >
> >
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth