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
