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
