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