Oh and don't forget fun things like including the full cert chain which after encoding also bloats to amazing heights.
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Yaron Goland > Sent: Wednesday, June 30, 2010 5:39 PM > To: Torsten Lodderstedt > Cc: OAuth WG ([email protected]) > 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:[email protected]] > > Sent: Tuesday, June 29, 2010 11:49 PM > > To: Yaron Goland > > Cc: Marius Scurtescu; OAuth WG ([email protected]) > > 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 <[email protected]>: > > > > > 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: [email protected] [mailto:[email protected]] On > > >> Behalf Of Torsten Lodderstedt > > >> Sent: Monday, June 28, 2010 12:26 PM > > >> To: Marius Scurtescu > > >> Cc: OAuth WG ([email protected]) > > >> 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 > > >> > <[email protected]> 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 > > >> >> [email protected] > > >> >> https://www.ietf.org/mailman/listinfo/oauth > > >> >> > > >> >> > > >> >> _______________________________________________ > > >> >> OAuth mailing list > > >> >> [email protected] > > >> >> https://www.ietf.org/mailman/listinfo/oauth > > >> >> > > >> >> > > >> >> > > >> > > >> _______________________________________________ > > >> OAuth mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
