This is more about pragmatism than proper standards process. A large number of providers today use client password credentials. This is the common practice in almost every non-enterprise use case (which was the original driver behind OAuth and is still the lion share of the work and deployment). Since this is such an important use case (based on 3 years of actual deployment), it should be specified in the protocol. This gives a simple and immediate solution to most providers.
However, client password credentials are clearly limited in their security attributes. It would not be wise to mandate supporting them as they are simply too weak for some cases. In addition, some use cases do not require any client authentication. The entire client authentication part of the protocol is very much deployment specific at this point in our experience. So the compromise I have been promoting is to only define the most common *practice* of sending client credentials using parameters (which is industry-wide and the most well-established among OAuth adopters). Everything else can and should be defined elsewhere. This tactic allows for longer debate and deployment experience to provide well-thought and well-specified alternative means for client authentication. Note that HTTP Basic authentication was not completely removed, but was simply demoted from normative language to an example of how client password credentials MAY be sent instead of the query parameters. It is a compromise I believe allows deployment of Basic auth today without creating any burden when unwanted. So I'm going for a modified (a). EHL > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] > Sent: Thursday, February 03, 2011 7:41 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org > Subject: Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication > for Client Credentials' > > On 2/3/2011 5:00 PM, Eran Hammer-Lahav wrote: > > Yes. I think automatic registration and other mechanisms for discovery and > obtaining credentials are going to be extremely useful. We're just not there > yet. > > This issue does not only need to be related to automatic registration. > > With respect to standardizing certain functionality you can decide that > > a) a certain feature (call it an interface) is out-of-scope (it may be > standardized later) > > You describe them as out-of-scope. Done. > > b) you want to describe it at a level that ensures interoperability. > > Since OAuth is more a framework than just a single protocol (or a small > number of protocol extensions) you do not need to even envision > standardization of every part of it. > > When you go for (b) then you better pick one way to offer a certain feature > unless there is a very good reason to have more than one. Such reason may > exist in case of cryptographic algorithms (which may get broken over time), > etc. > > So, do I get the impression that you are essentially saying that > - you would rather go for (a) and postpone the standardization of the entire > client authentication, > - you want to go for (b) but you do not want to have something in the base > specification, or > - you would go for (b) but you just want to restrict the options down to a > smaller set? > > Ciao > Hannes > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
