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
