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
