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
