What Mike said. Definitely keep section 3 and I would really like to see the client assertion section restored. Glad to hear there is some progress on that front.
Marius On Fri, Apr 1, 2011 at 6:19 AM, Mike Jones <[email protected]> wrote: > Also -1 on dropping section 3. Rather, we need to restore the client > assertion credentials to 3, per the outcome of the discussion at today's > working group meeting. I'm glad that we're headed in that direction. > > -- Mike > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Richer, Justin P. > Sent: Friday, April 01, 2011 5:19 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Reques to drop section 3 > > -1 once again > > I want to keep the client password mechanism in core as it reflects the way > that most (nearly all in my personal experience) client implementations pass > their auth parameters today. I do think that the assertion credentials could > live fine in a simple extension, though, with the same arguments as the > assertion grant type. > > -- Justin > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Eran > Hammer-Lahav [[email protected]] > Sent: Friday, April 01, 2011 5: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 > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
