[OAUTH-WG] Client credentials type

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 28 June 2010 17:39 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855DF3A691A for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 10:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Level:
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_40=-0.185, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG6ybrGYOUhw for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 10:39:37 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7F16528C106 for <oauth@ietf.org>; Mon, 28 Jun 2010 10:39:34 -0700 (PDT)
Received: (qmail 10192 invoked from network); 28 Jun 2010 17:39:35 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jun 2010 17:39:35 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 28 Jun 2010 10:39:33 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Date: Mon, 28 Jun 2010 10:39:34 -0700
Thread-Topic: Client credentials type
Thread-Index: AcsW5Zz/FVZYBlj1T06cHdkG6yGF6w==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9DP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Client credentials type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jun 2010 17:39:45 -0000

Yaron Goland offered a proposal for an additional client credentials mechanism based on assertion. His proposal raises the issue of differentiating between the different kind of credentials used. When it comes to access grant types, this group argued for being explicit and providing a parameter declaring the grant type being used (even though it is not technically necessary).

While I don't believe a grant or credential type parameter is needed - the type can be deduced from the other parameters present - we now treat the same requirement with a different solution. I think this creates a broken environment for extensibility (which is my current focus).

At the same time, introducing such a parameter can conflict with the standard HTTP authentication mechanism. For example, a request containing both "client_credentials_type=basic" and the HTTP Authorization header seems odd.

There are a few ways to address this:

1. Only use a type parameter when the credentials are passed using parameters and not a header.
2. Only allow HTTP headers for authentication, while "grandfathering-in" the client_secret parameter to simplify the most common current practice.
3. Leave is underspecified, relying on the presence of extension parameters or authentication headers for other credentials types.

Thoughts?

EHL