Subject: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials'

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 03 Feb 2011 10:16:26 +0200

Hi all,

Eran suggested to remove the HTTP Basic Authentication functionality 
from the specification in his mail from last month:
http://www.ietf.org/mail-archive/web/oauth/current/msg05028.html

Essentially, there are two ways to accomplish the same functionality, 
namely (1) Request parameters and (2) HTTP Basic authentication.

Eran's initial discussion trigger very quickly evolved a discussion 
about the removal of 'credential body parameters':
http://www.ietf.org/mail-archive/web/oauth/current/msg05035.html
This was, however, not supported by Justin, Eran, and Marius.

The main question for me is: "What is mandatory to implement?"

Regarding this question I went through the discussions on the mailing 
list and I got the following impression:
"+" means in favor of removing HTTP Basic Authentication and
"-" means against it.
"~" indicates that the person is OK with removing it under certain 
conditions.

+Eran
+Justin
~Tony (OK with having it optional but does not want to remove it from 
draft-ietf-oauth-v2)
~Igor (OK with having it optional but does not want to remove it from 
draft-ietf-oauth-v2)
+Marius

Please correct me if I have forgotten someone.

My reading of the feedback from the response on the list is that we have 
a decision to make HTTP Basic authentication optional to implement (and 
therefore the request parameters mandatory to implement).

A secondary question is: "Should the **optional** HTTP Basic 
Authentication functionality be included in the draft-ietf-oauth-v2 
specification?"

Here are my two questions:

1) Do you insist on having the HTTP Basic authentication documented in 
draft-ietf-oauth-v2?

PLEASE NOTE: Having functionality in a separate document does not mean 
that it will take longer to complete nor that it is less important. It 
is purely a document management question!

2) If your answer to question (1) is "NO" then:
    Would you be willing to co-author a document on this functionality?

Since the response so far does not give me a rough consensus I would 
like to get your feedback.

Deadline for response: Feb, 10th 2011

Ciao
Hannes

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 01:39:48 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Thursday, February 03, 2011 12:16 AM
> To: [email-masked]
> Subject: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for
> Client Credentials'
> 
> Hi all,
> 

Nothing. The authorization server can support whatever client authentication methods it deems appropriate. *IF* client password credentials are supported, then the spec offers one way to provide them using parameters.  The reason why this is not that important is that there is no real interop as it currently stands because the process of obtaining these client credentials is out of scope.

EHL
 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 3 Feb 2011 15:02:44 +0200

> Nothing. The authorization server can support whatever client 
> authentication methods it deems appropriate. *IF* client 
> password credentials are supported, then the spec offers one 
> way to provide them using parameters.  The reason why this is 
> not that important is that there is no real interop as it 
> currently stands because the process of obtaining these 
> client credentials is out of scope.

In order to deploy Oauth one has to consider a number of components.
Today, many of them require proprietary mechanisms and steps executed
out-of-band. 

My hope, however, is that we (as part of this standardization work)
improve interoperability and thereby reduce the number of proprietary
components. 

This topic seems to be one where standardization could indeed be
helpful. 

Wouldn't you agree? 

Ciao
Hannes

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 08:00:22 -0700

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.

EHL

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> Sent: Thursday, February 03, 2011 5:03 AM
> To: Eran Hammer-Lahav; Hannes Tschofenig; [email-masked]
> Subject: RE: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication
> for Client Credentials'
> 
> > authentication methods it deems appropriate. *IF* client password
> > credentials are supported, then the spec offers one way to provide
> > them using parameters.  The reason why this is not that important is
> > that there is no real interop as it currently stands because the
> > process of obtaining these client credentials is out of scope.
> 
> My hope, however, is that we (as part of this standardization work) improve
> interoperability and thereby reduce the number of proprietary components.
> 
> This topic seems to be one where standardization could indeed be helpful.
> 
> Wouldn't you agree?
> 
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 03 Feb 2011 17:40:37 +0200

> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 09:48:36 -0700

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

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, February 03, 2011 7:41 AM
> To: Eran Hammer-Lahav
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Subject: Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication
> for Client Credentials'
> 
> > 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.
> 
> a) a certain feature (call it an interface) is out-of-scope (it may be
> standardized later)
> 
> 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.
> 
> - 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
>