While the AS implementor can infer the request by the parameters, I prefer the programmer explicitly state what she is doing. Thinking of it as a method parameter rather than a type parameter makes more sense to me. Similiarly, HTTP has GET, POST, PUT etc. even though you could differentiate between them by looking at what was passed or not passed.
-- Dick On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrote: > 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
