+1 I think basic auth for client credentials belongs to an extension, that simplifies the core spec. Is there a good reason to keep an optional feature in core?
Marius On Tue, Jan 18, 2011 at 3:21 PM, Igor Faynberg <igor.faynb...@alcatel-lucent.com> wrote: > +1 > > Igor > > Anthony Nadalin wrote: >> >> If it is left as optional (not removed) then I'm OK to go with >> parameter-based approach as default >> >> -----Original Message----- >> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Tuesday, >> January 18, 2011 9:50 AM >> To: Anthony Nadalin; Richer, Justin P.; OAuth WG >> Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >> Credentials >> >> So does requiring the parameter-based approach which has identical >> security properties. We need to require at least one, and we already know >> some will not deploy Basic. >> >> EHL >> >> >>> >>> -----Original Message----- >>> From: Anthony Nadalin [mailto:tony...@microsoft.com] >>> Sent: Tuesday, January 18, 2011 9:28 AM >>> To: Richer, Justin P.; Eran Hammer-Lahav; OAuth WG >>> Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >>> Credentials >>> >>> Concern here is that HTTP Basic Auth provides a straightforward interop >>> profile for the web server profile >>> >>> -----Original Message----- >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >>> Richer, Justin P. >>> Sent: Monday, January 17, 2011 7:43 AM >>> To: Eran Hammer-Lahav; OAuth WG >>> Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >>> Credentials >>> >>> +1 to making BASIC optional. I don't think we were going to be >>> +supporting it >>> in general, either. >>> >>> -- Justin >>> ________________________________________ >>> From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran >>> Hammer-Lahav [e...@hueniverse.com] >>> Sent: Saturday, January 15, 2011 1:53 AM >>> To: OAuth WG >>> Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >>> Credentials >>> >>> OAuth 2.0 provides two methods for client authentication using password >>> credentials: request parameters and HTTP Basic authentication. I suggest >>> we drop the requirement to support HTTP Basic authentication, and only >>> mention it as an example for alternative methods. My reasons are: >>> >>> >>> 1. A few providers have expressed concerns over the need to support >>> Basic authentication, and some explicitly said they will not support it. >>> Parameter-based authentication, OTOH, is widely deployed in 2.0. >>> >>> 2. Due to the way OAuth is being implemented at the HTTP >>> authentication >>> layer (even if it is wrong), can conflict within the framework as both a >>> consumer and provider of authentication components. >>> >>> 3. The mapping between username and client_id, while not >>> complicated, >>> is still a big awkward, and can be confusing when combined with the >>> username and password grant type. On the other hand, the use of client_id in >>> the end-user authorization endpoint lends itself nicely to the use of the >>> same parameter elsewhere. >>> >>> 4. Some existing authentication frameworks will have an issue >>> handling >>> the mix of Basic authentication and parameters authentication due to how >>> each is deployed. In cases where a front gate handles Basic, it will be hard >>> to let requests through for parameter processing. >>> >>> Comments? Counter-arguments? >>> >>> 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 >> > > _______________________________________________ > 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
