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

Naitik Shah <n@daaku.org> Thu, 15 July 2010 21:34 UTC

Return-Path: <naitiks@gmail.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 C0F003A6840 for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 14:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 IjxSdvGEEfc7 for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 14:34:16 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 5806C3A6A6B for <oauth@ietf.org>; Thu, 15 Jul 2010 14:34:16 -0700 (PDT)
Received: by gxk1 with SMTP id 1so657046gxk.31 for <oauth@ietf.org>; Thu, 15 Jul 2010 14:34:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=3UW7h5sXrWGhlJ0qJLyeOCKZUW5Dejo3/fPiVbR26Fw=; b=to/Z7vebnQx8lnZuhTsf3w74g+6W1+GApZ+sNNd8HHXEoY4i/Ut+1l5rD8V+ZlcbBv R17n64fKyaw8hLYsDJBSWE6Tt7zg9UYT6yy7t+yrn0Qa0z5rTWRIXH0D+7EL7F59JiIx zUn9Tg65s5aT1lsEnBwwf0x22ciX/JSHM8Ttg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=fWSywKmDZa21IRt2q0yja/3WCUMGZAms+Ydr+JAphKbOCZz584gecxbD+YIHZEGzTx 4n2yq5RXNQWsOj/cvEIEXnqtuTB1z1XJVjyBUoZpuCX+dNbHXFVUzzAOCj3luskBTziD avfTKrgEo3hY68MliJYL/tLEQbGGGVKhVVJhg=
Received: by 10.150.69.32 with SMTP id r32mr612573yba.107.1279229664333; Thu, 15 Jul 2010 14:34:24 -0700 (PDT)
MIME-Version: 1.0
Sender: naitiks@gmail.com
Received: by 10.231.159.193 with HTTP; Thu, 15 Jul 2010 14:34:04 -0700 (PDT)
In-Reply-To: <1279216291.18579.61.camel@localhost.localdomain>
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>
From: Naitik Shah <n@daaku.org>
Date: Thu, 15 Jul 2010 14:34:04 -0700
X-Google-Sender-Auth: 9tvAFnHp8pvYEZGsxt-zcpvav50
Message-ID: <AANLkTikJymidRFzQf17Ssm-CCX7RLZ8Gu0_SZl_ocWdi@mail.gmail.com>
To: Justin Richer <jricher@mitre.org>
Content-Type: multipart/alternative; boundary="000e0cd598ccba9041048b73dd64"
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 21:34:17 -0000

I though we'd come to a decision on the versioning too :) IMHO, it's better
to push this burden of versioning into the token itself if necessary. I
think it's better from a developers perspective to pass an oauth_token,
because it's cleaner. Most deployments will already have versioned tokens to
enable upgrading these for internal changes, so why can't the OAuth version
be contained in there too? Given the option to simplify the implementation
for a API provider (Big Company, or someone who has to know how OAuth works)
vs API consumer (Developer, or someone who usually just wants some data), I
hope everyone agrees our focus should be the Developer.

While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so don't
have the same backward compatibility issues, we've already changed our
tokens and introduced new ones a couple of times and this had no impact on
the parameter name being used.


-Naitik

On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer <jricher@mitre.org> wrote:

> 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 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.
>
>  -- 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
>