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
