This section makes sense as it does setup for the identification and authentication of the client, so I do believe that it makes sense in the document. Thomas undertook the task to revive the Client Credentials section from previous draft that will include normative text, which when asked the room showed interest, I believe he indicated 3 weeks to do this.
I assume you are objecting to not using just HTTP authentication? There are scenarios where we need SAML and other technology so only allowing HTTP authentication is too restrictive and to allow the profiling for interoperability of these technologies we need an extension point here. From: [email protected] [mailto:[email protected]] On Behalf Of Eran Hammer-Lahav Sent: Friday, April 01, 2011 2:14 AM To: OAuth WG Subject: [OAUTH-WG] Reques to drop section 3 There was (still is) a long heated debate at the WG meeting today about client authentication and the dropped client assertion credentials section. I want to repeat my past view (and this time post it as an open issue), that this entire section makes no sense in this document. OAuth should not be defining hackish HTTP authentication schemes, especially ones not using the RFC2617 framework. Someone can easily register the client_password parameter as an extension (it's a nasty hack but I won't stand in its way), as well as any other poorly design client authentication scheme using form-encoded parameters to authentication an HTTP request... So - I want to see section 3 turned into a brief discussion about client authentication which gives HTTP Basic auth as an example and nothing else. Client authentication is already 95% out of scope. EHL
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
