Sorry, typo ... see clarification below. Phil [email protected]
On 2011-01-20, at 2:50 PM, Phil Hunt wrote: > 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 handled OOB (SSL mutual, SSO token etc). > > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
