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
