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

Justin Richer <jricher@mitre.org> Thu, 15 July 2010 19:15 UTC

Return-Path: <jricher@mitre.org>
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 4B4C93A6B38 for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 12:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.489
X-Spam-Level:
X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 d34BS2eABOui for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 12:15:08 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 81BAA3A69CE for <oauth@ietf.org>; Thu, 15 Jul 2010 12:15:06 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FJFFmo000594 for <oauth@ietf.org>; Thu, 15 Jul 2010 15:15:16 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o6FJFF2f000585; Thu, 15 Jul 2010 15:15:15 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Thu, 15 Jul 2010 15:15:15 -0400
From: Justin Richer <jricher@mitre.org>
To: Luke Shepard <lshepard@facebook.com>
In-Reply-To: <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com>
References: <AANLkTim6az--AdwmEoew2pz3kEjhc_GyEaiyo_0UhSRr@mail.gmail.com> <1279205969.18579.55.camel@localhost.localdomain> <AANLkTildz62l2Me26Dlrv5nNmp8Z3P8JD1K-ChcWc5IO@mail.gmail.com> <AANLkTill8k-fUFt-IZLWdZinScj4fSBoI4rAiAf1PrYR@mail.gmail.com> <1279216291.18579.61.camel@localhost.localdomain> <74AEEFD7-04B3-4B28-970E-0DB554728BED@facebook.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 15 Jul 2010 15:15:15 -0400
Message-ID: <1279221315.11628.17.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" <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 19:15:15 -0000

> > It was discussed before, but I don't remember there being any consensus
> > in the group. What are the practical reasons for not using "oauth2"
> > namespacing in the one place we still use namespacing? Most of what I've
> > heard seems to sound like "I don't like it to have a 2 on it". 
> 
> I don't like it to have a 2 in it.

OK, I would. :)

> > I don't want to have to set up the OAuth 2 system to have to catch
> > failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad
> > OAuth 1 call should be distinguishable from the start. Also, what about
> > when we finally get a signed-request going? I would assume that that's
> > going to add back in things like oauth_signature, oauth_nonce, and the
> > other parameters whose absence you should filter on. 
> 
> The latest signature discussions have all focused on a single, self-contained, signed parameter that includes both data and signature. I think it's unlikely that we will introduce the plethora of parameters that we had in OAuth 1.0.

Yeah, I'd noticed that; but those all stemmed around cryptographic
verification of the token itself, and not the request that contained the
token. There seems to be a lot of interest in coming up with a way for
the AS to sign the token so that the PR can verify its authenticity, but
what about the original use case of the PR being able to verify the
authenticity of the call?

 -- Justin


> > On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote:
> >> I thought this topic had been beaten to death before. An OAuth 1.0
> >> protected resource request includes a variety of oauth_ parameters
> >> whereas OAuth 2.0 just has oauth_token.
> >> 
> >> 
> >> --David
> >> 
> >> 
> >> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <beaton@google.com>
> >> wrote:
> >>        On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer
> >>        <jricher@mitre.org> wrote:
> >>> +1 on OAuth2 header, and I also want to see oauth2_token in
> >>        URI and form
> >>> parameter methods.
> >> 
> >> 
> >>        Good point about the query parameter names needing to be
> >>        unambiguous.
> >> 
> >>        _______________________________________________
> >>        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
>