I don't think this is a case of providing alternative methods. It is just a case of allowing ANY method that the Authentication server deems sufficient. Kerberos, SAML, SSO token, basic auth, mutual SSL, etc.
Thus you don't need to put specific authentication methods in the spec other than to simply REQUIRE that the client be authenticated -- either inbound with the POST as you suggest or OOB during a previous exchange. It may be a good idea to define one mandatory to implement methodology, but to define more than one suggests limiting authentication approaches to specific methods. I don't think this is the intent here. Phil [email protected] On 2011-01-20, at 2:28 PM, Marius Scurtescu wrote: > On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt <[email protected]> wrote: >> The client does need to know how to authenticate. But given that it already >> has to know a lot about the service, you would think acceptable >> authentication types are well known to the client. > > Yes, true. > > >> What is the problem with the client authenticating like any normal web >> service client? (IE outside of oauth) >> >> Why involve oauth in any authentication for User or client? > > What is a normal web service client? Since the client has to POST a > bunch of parameters as form encoded, it is simpler to also send > authentication parameters there. Providing alternate methods of > authentication is just asking for trouble. Of course, the spec could > require that authentication is only sent through some other method, > but I think it is way too late for such a change. > > > Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
