I agree with Justin.
________________________________
From: "Richer, Justin P." <jric...@mitre.org>
To: Eran Hammer-Lahav <e...@hueniverse.com>; OAuth WG <oauth@ietf.org>
Sent: Friday, April 1, 2011 5:18 AM
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: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav [e...@hueniverse.com]
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
