Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header

Eran Hammer-Lahav <eran@hueniverse.com> Thu, 15 July 2010 13:25 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 F33763A6A44 for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 06:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level:
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, 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 C6FSgbDiKcA0 for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 06:25:50 -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 921103A6A21 for <oauth@ietf.org>; Thu, 15 Jul 2010 06:25:50 -0700 (PDT)
Received: (qmail 8137 invoked from network); 15 Jul 2010 13:26:00 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jul 2010 13:25:59 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 15 Jul 2010 06:25:59 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>, Brian Eaton <beaton@google.com>
Date: Thu, 15 Jul 2010 06:25:57 -0700
Thread-Topic: [OAUTH-WG] OAuth vs OAuth2 in Authorization header
Thread-Index: AcskHqx2cjOATDosRQaiLmQjDRJ6BgAApWLF
Message-ID: <C8645A75.372D5%eran@hueniverse.com>
In-Reply-To: <F747E8F8-D022-46F7-BBCE-4219BF3B27B0@hueniverse.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C8645A75372D5eranhueniversecom_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header
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: Thu, 15 Jul 2010 13:25:57 -0000

To elaborate a bit:

Since there is no discovery in 1.0, the only place this can create a conflict is on the server side, when servers support both new and old schemes, and need to tell which version the client is using. This is the same issue as using the 'oauth_token' parameter in the query or body. Since there is no discovery, no 2.0 client is going to try and talk to a 1.0 server because that would be a like trying to speak SMTP to an XMPP port. On the server side, adding support for 2.0 already requires code changes.

If this proves to be an actual issue with a deployed system, I don't care about using a different name but:

- 'OAuth2' is "ugly as sin", and puts us on the broken path to produce an 'OAuth3', etc.
- We need to have more discussions about using different schemes with different token properties (i.e. Bearer, Signed, etc.). Some here want to break this into highly specialized schemes, while others want to use 2, and some a single scheme for everything (similar to 1.0). Using multiple headers doesn't break much on the 'Authorization' side because the server can easily handle it. But on the 'WWW-Authenticate' side it means having to define multiple schemes with their own discovery parameters, their own extensions, etc. This will turn into an complex and messy framework with too many confusing headers, etc.

So bikeshedding aside, we need to reach consensus on how to architect the headers first, then we can find a name or names that don't annoy people like 'Token', 'OAuth', or 'OAuth2'.

EHL


On 7/15/10 6:07 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

I would like people to raise their hand and explain how this will break actual 1.0 deployments.

EHL



On Jul 15, 2010, at 1:38, Brian Eaton <beaton@google.com> wrote:

> Draft 10 switched from "Token" scheme in the authorization header to
> "OAuth".  I'd rather we didn't reuse OAuth.  'OAuth2' would be great.
> "Token" is ugly as sin, but is better than "OAuth".
>
> Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30
>
> The problem with reusing "OAuth" is that there are existing
> implementations in the wild that have special behavior implemented for
> OAuth authorization headers.  Since OAuth2 headers don't have the same
> semantics, we're going to break those implementations.  We shouldn't
> reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate",
> "NTLM", "Digest", or "Basic.
>
> Cheers,
> Brian
> _______________________________________________
> 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