Re: [OAUTH-WG] Client credentials type

[Torsten Lodderstedt <[e-mail]>]

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
>
>