From fcorella@pomcor.com Tue Mar 1 09:56:35 2011 Return-Path: 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 A3A863A6A35 for ; Tue, 1 Mar 2011 09:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, 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 l9KpnZIZZU5d for ; Tue, 1 Mar 2011 09:56:32 -0800 (PST) Received: from nm30-vm0.bullet.mail.ac4.yahoo.com (nm30-vm0.bullet.mail.ac4.yahoo.com [98.139.52.250]) by core3.amsl.com (Postfix) with SMTP id D551E3A6A1A for ; Tue, 1 Mar 2011 09:56:31 -0800 (PST) Received: from [98.139.52.190] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 01 Mar 2011 17:57:32 -0000 Received: from [98.139.52.133] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 01 Mar 2011 17:57:32 -0000 Received: from [127.0.0.1] by omp1016.mail.ac4.yahoo.com with NNFMP; 01 Mar 2011 17:57:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 428013.27324.bm@omp1016.mail.ac4.yahoo.com Received: (qmail 56303 invoked by uid 60001); 1 Mar 2011 17:57:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299002252; bh=WeD7UqwPYKeLVfpBTqcs0hywpvvIkv1+hYpewM8iwAI=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JgCIGgX2+caPrWq7LgqUmNyoGCxmaY1fwfk/kggWkeWv/mLByElNbGaZpgPKTJCQoocsARyMJYabOq2Qs40hfwJsdv/NkZ21Z8sMrK1w5ROcAi+Id3GMi9jEB0JruqszNoriBAmLmGK6KdgpnyGFiUvv8fu4dnIsHkM9JPhx7xY= Message-ID: <315279.56286.qm@web55803.mail.re3.yahoo.com> X-YMail-OSG: U_jPtRsVM1kLI_nHwV8n6YdK6i_Znn.eXOBEOo28TYgtvmL y7OfB70Wj2soAjXzT6AM3ZkG2neyRAAJi3OyOLOWdOpQ_n0Q9e9aSW8W96ye QygD_WWBJJh0514VlfcoivdVyGKNnOcyuS_MRazBjiQbsdITknyZ31yvvyy1 dALAql9QiFBmIVpsiSOOZdpAYI5th36nHbKzAf9ZIhBzgK3UOM1VmJz_qAe. 3e_FEWyvEn_eAXs16rZVLMFSJJu5qS3xkupE06IDGAyjpayH1OVval5wS_nz ABNZ5sU2lF0lEhHugVt.cjHmvPw.BNPuMHDkH08qt.ifDYdcT7LAbNbDTCod jDQ-- Received: from [67.91.91.101] by web55803.mail.re3.yahoo.com via HTTP; Tue, 01 Mar 2011 09:57:31 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Tue, 1 Mar 2011 09:57:31 -0800 (PST) From: Francisco Corella To: OAuth Mailing List , James HManger In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127F4DAE9D@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1561885316-1299002251=:56286" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 17:56:35 -0000 --0-1561885316-1299002251=:56286 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi James, It would help if you would spell out an attack flow, step by step, and poin= t out the practical consequences of the attack. Thanks, Francisco --- On Tue, 3/1/11, Manger, James H wrote= : From: Manger, James H Subject: RE: [OAUTH-WG] Indicating origin of OAuth credentials to combat lo= gin CSRF To: "fcorella@pomcor.com" , "OAuth Mailing List" Cc: "Karen P. Lewison" Date: Tuesday, March 1, 2011, 6:59 AM =0A=0A =0A =0A=0A=0A=0A=0A> The attack is only possible if there are multip= le independent authorization servers that don't trust each other. =0A =C2= =A0 =0AAnd there are. Facebook, Twitter, Photos-are-us, Xyz=E2=80=A6 can op= erate authorization servers; they are all independent; and don=E2=80=99t pa= rticularly trust each other. The attack doesn=E2=80=99t require a single re= source server to trust all these independent=0A authorization servers. =0A = =C2=A0 =0A> By far the most widespread deployment of OAuth is for social lo= gin, as in "log in with Facebook".=C2=A0 In that case the authorization ser= ver is a Facebook endpoint, the resource servers are Facebook endpoints, an= d the attack is not possible =0A =C2=A0 =0A =C2=A0 =0AYou are probably righ= t that this attack is not possible against a client app offering a =E2=80= =9Clogin with facebook=E2=80=9D button. Such a client is hardwired to work = with a single service =E2=80=93 which is one (very limiting) way to avoid t= hese attacks. =0A =C2=A0 =0AA client accepting login from any social networ= k (even ones the client hasn=E2=80=99t heard of) could be susceptible this = attack. The =E2=80=9Cother=E2=80=9D social network returns a token that it = actually got from Facebook and gets the client app to use it at=0A Facebook= . =0A =C2=A0 =0A =C2=A0 =0A-- =0AJames Manger =0A =C2=A0 =0A =C2=A0 =0A=0AF= rom: Francisco Corella [mailto:fcorella@pomcor.com]=0A =0ASent: Tuesday, 1 March 2011 4:17 PM =0ATo: OAuth Mailing List; Manger, James H =0ACc: Karen P. Lewison =0ASubject: RE: [OAUTH-WG] Indicating origin of OAuth credentials to combat= login CSRF =0A=0A =C2=A0 =0A=0A=0A=0A=0AHi James, =0A =0AI think I got it now.=C2=A0 Thanks for explaining it so patiently. =0A =0AThe attack is only possible if there are multiple independent authorizat= ion servers that don't trust each other.=C2=A0 But the OAuth specification = talks about multiple resource servers but only one authorization server.=C2= =A0 I think there is an implicit assumption that=0A the multiple resource s= ervers will only accept tokens from the one authorization server.=C2=A0 By = far the most widespread deployment of OAuth is for social login, as in "log= in with Facebook".=C2=A0 In that case the authorization server is a Facebo= ok endpoint, the resource=0A servers are Facebook endpoints, and the attack= is not possible. =0A =0AFrancisco =0A =0A--- On Tue, 3/1/11, Manger, James H wr= ote: =0A =0A =0A =0AFrom: Manger, James H =0ASubject: RE: [OAUTH-WG] Indicating origin of OAuth credentials to combat= login CSRF =0ATo: "fcorella@pomcor.com" , "OAuth Mailing List" =0ACc: "Karen P. Lewison" =0ADate: Tuesday, March 1, 2011, 12:43 AM =0A=0A=0AFrancisco, =0A=C2=A0 =0A= >> A client that follows HTTP redirects (or Link: header or any =0A>> other variety of hypertext) might get directed to an 2nd =0A>> service while still using the token from the 1st service. =0A =0A> But why would a legitimate authorization server redirect the =0A> client to an attacker's server? =0A=C2=A0 =0AIt can happen the other w= ay around. The 1st service acts maliciously, forwarding a token that was ac= tually obtained from the 2nd service. The client then uses=0A that token to= make requests to the 2nd service =E2=80=93 because it thinks it is part of= the 1st service. =0A=C2=A0 =0AThe core issue is that a client gets a opaqu= e token from one service and will use it to access other resources. The tok= en is opaque to the client: =0A1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The c= lient cannot check that the token was originally issued by this service (as= opposed to this service forwarding a token from elsewhere); =0A2.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 The client cannot check that the token was mean= t for itself (as opposed to being forwarded from another client); =0A3.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The client isn=E2=80=99t told by the toke= n issuer where it should & shouldn=E2=80=99t be used (ie the boundary of th= e services); =0A4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The client isn=E2=80= =99t told by a resource server which sources of tokens are legitimate. =0A= =C2=A0 =0AOne way to avoid some of these issues is to hardwire clients to a= specific service =E2=80=93 which is very limiting. =0AAnother way is to ha= ve a standard token format =E2=80=93 which is limiting, and a big burden on= clients. =0AA better way is to accept points 1 & 2; address 3 by listing r= esource sites in token responses; and address 4 obliquely by listing the au= thorization server in the =E2=80=9COrigin=E2=80=9D HTTP request=0A header. = Then it doesn=E2=80=99t matter if a client unwittingly connects with an att= acker=E2=80=99s service (just as it shouldn=E2=80=99t matter to a legitimat= e web site if their web browser clients unwittingly visit malicious or comp= romised web sites). =0A=C2=A0 =0A-- =0AJames Manger =0A=0A=0A=0A=0A=0A=0A = =C2=A0 =0A=0A =0A --0-1561885316-1299002251=:56286 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi James,

It would help if you would s= pell out an attack flow, step by step, and point out the practical conseque= nces of the attack.

Thanks,

Francisco

--- On Tue, 3= /1/11, Manger, James H <James.H.Manger@team.telstra.com> w= rote:

From: Manger, James H <James.H.Man= ger@team.telstra.com>
Subject: RE: [OAUTH-WG] Indicating origin of OA= uth credentials to combat login CSRF
To: "fcorella@pomcor.com" <fcore= lla@pomcor.com>, "OAuth Mailing List" <oauth@ietf.org>
Cc: "Kar= en P. Lewison" <kplewison@pomcor.com>
Date: Tuesday, March 1, 2011= , 6:59 AM

=0A=0A =0A =0A=0A<= div class=3D"yiv936749894WordSection1">=0A

> The attack is only possible if there are multiple independent author= ization servers that don't trust each other.

=0A

 

=0A

And there are= . Facebook, Twitter, Photos-are-us, Xyz=E2=80=A6 can operate authorization = servers; they are all independent; and don=E2=80=99t particularly trust eac= h other. The attack doesn=E2=80=99t require a single resource server to tru= st all these independent=0A authorization servers.

=0A

 

=0A

> By= far the most widespread deployment of OAuth is for social login, as in "lo= g in with Facebook".  In that case the authorization server is a Faceb= ook endpoint, the resource servers are Facebook endpoints, and the attack i= s not possible

=0A

 

=0A

 

=0A

You are probably right that this attack is not possible against a cl= ient app offering a =E2=80=9Clogin with facebook=E2=80=9D button. Such a cl= ient is hardwired to work with a single service =E2=80=93 which is one (ver= y limiting) way to avoid these attacks.

=0A

 

=0A

A client accepting= login from any social network (even ones the client hasn=E2=80=99t heard o= f) could be susceptible this attack. The =E2=80=9Cother=E2=80=9D social net= work returns a token that it actually got from Facebook and gets the client= app to use it at=0A Facebook.

=0A

&= nbsp;

=0A

 

=0A

--

=0A

James Manger

=0A

 

=0A

 

=0A
=0A

From: Francisco Corella [mailto:fco= rella@pomcor.com]=0A
=0ASent: Tuesday, 1 March 2011 4:17 PM
= =0ATo: OAuth Mailing List; Manger, James H
=0ACc: Karen P.= Lewison
=0ASubject: RE: [OAUTH-WG] Indicating origin of OAuth cr= edentials to combat login CSRF

=0A
=0A

 

=0A=0A=0A=0A=0A=0A=0A
=0A

Hi= James,
=0A
=0AI think I got it now.  Thanks for explaining it s= o patiently.
=0A
=0AThe attack is only possible if there are multiple= independent authorization servers that don't trust each other.  But t= he OAuth specification talks about multiple resource servers but only one a= uthorization server.  I think there is an implicit assumption that=0A = the multiple resource servers will only accept tokens from the one authoriz= ation server.  By far the most widespread deployment of OAuth is for s= ocial login, as in "log in with Facebook".  In that case the authoriza= tion server is a Facebook endpoint, the resource=0A servers are Facebook en= dpoints, and the attack is not possible.
=0A
=0AFrancisco
=0A
= =0A--- On Tue, 3/1/11, Manger, James H <James.H.Manger@team.telstr= a.com> wrote:
=0A
=0A

=0A


=0AFrom: Manger, James H <James= .H.Manger@team.telstra.com>
=0ASubject: RE: [OAUTH-WG] Indicating ori= gin of OAuth credentials to combat login CSRF
=0ATo: "fcorella@pomcor.co= m" <fcorella@pomcor.com>, "OAuth Mailing List" <oauth@ietf.org>=
=0ACc: "Karen P. Lewison" <kplewison@pomcor.com>
=0ADate: Tues= day, March 1, 2011, 12:43 AM

=0A
=0A
=0A

Francisco,

=0A

 

=0A

>> A client that follows HTTP redirects (or Link: head= er or any
=0A>> other variety of hypertext) might get directed to = an 2nd
=0A>> service while still using the token from the 1st serv= ice.
=0A
=0A> But why would a legitimate authorization server redi= rect the
=0A> client to an attacker's server?

=0A

It can happen the other way around= . The 1st service acts maliciously, forwarding a token that was = actually obtained from the 2nd service. The client then uses=0A = that token to make requests to the 2nd service =E2=80=93 because= it thinks it is part of the 1st service.

=0A

 

=0A

The core issue is that a c= lient gets a opaque token from one service and will use it to access other = resources. The token is opaque to the client:

=0A

1.       The client cannot check th= at the token was originally issued by this service (as opposed to this serv= ice forwarding a token from elsewhere);

=0A

2.       The client cannot check that the= token was meant for itself (as opposed to being forwarded from another cli= ent);

=0A

3.    &n= bsp;  The client isn=E2=80=99t told by the token issuer where it shoul= d & shouldn=E2=80=99t be used (ie the boundary of the services);=

=0A

4.       The= client isn=E2=80=99t told by a resource server which sources of tokens are= legitimate.

=0A

 

=0A

One way to avoid some of these issues is to hardwire clients to = a specific service =E2=80=93 which is very limiting.

=0A

Another way is to have a standard token format =E2=80=93 which is= limiting, and a big burden on clients.

=0A

A b= etter way is to accept points 1 & 2; address 3 by listing resource site= s in token responses; and address 4 obliquely by listing the authorization = server in the =E2=80=9COrigin=E2=80=9D HTTP request=0A header. Then it does= n=E2=80=99t matter if a client unwittingly connects with an attacker=E2=80= =99s service (just as it shouldn=E2=80=99t matter to a legitimate web site = if their web browser clients unwittingly visit malicious or compromised web= sites).

=0A

 

=0A

--

=0A

James Manger

=0A
= =0A
=0A
=0A

 

=0A
=0A = =0A
--0-1561885316-1299002251=:56286-- From torsten@lodderstedt.net Tue Mar 1 12:01:14 2011 Return-Path: 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 5383C3A6A2D; Tue, 1 Mar 2011 12:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 OTUKeMKa2M8j; Tue, 1 Mar 2011 12:01:13 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by core3.amsl.com (Postfix) with ESMTP id 989D03A6AA9; Tue, 1 Mar 2011 12:01:12 -0800 (PST) Received: from [79.253.34.196] (helo=[192.168.71.49]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PuVlt-00059l-Iz; Tue, 01 Mar 2011 21:02:13 +0100 Message-ID: <4D6D50C5.4040703@lodderstedt.net> Date: Tue, 01 Mar 2011 21:02:13 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marius Scurtescu References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3EE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A91D3F9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D68F471.3090204@lodderstedt.net> <4D6C0289.3030300@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Draft -12 feedback deadline X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 20:01:14 -0000 Am 28.02.2011 23:58, schrieb Marius Scurtescu: > On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg > wrote: >> +1 >> >> Igor >> >> Torsten Lodderstedt wrote: >>> ... >>> >>> I'm in favour to add the refresh token parameter to the implicit grant >>> flow as it would make it more useable for native apps. > I think it is much safer to go with refresh tokens only sent > indirectly through an authorization code swap. > why is it _much_ safer? The only threat elimimated by this approach is a token leak via browser cache. On the other hand, the authorization code flow has to be protected from session fixation and guessing attacks, threats which are not applicable to the implicit grant flow. It seams to be acceptable to issue access tokens with the implicit grant but not refresh tokens. Why? Because we assume access tokens have a much sorter lifetime than refresh tokens? This is not specified by the draft! So anyone could issue access tokens with infinite lifetime via the implicit grant and claim full OAuth 2.0 compliance. > Implicit grant with refresh token also has no client secret swap and > makes things worse by passing the refresh token through the browser. What do you think is the value of having a client secret for a native app? As pointed out in my previous posting, refresh tokens can be invalidated during every refresh request. So the impact can be reduced to that of an access token leak (which seams to be acceptable). regards, Torsten. > Marius From phil.hunt@oracle.com Tue Mar 1 12:33:25 2011 Return-Path: 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 CDBE03A6AA8 for ; Tue, 1 Mar 2011 12:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fgo1Nac8zMeU for ; Tue, 1 Mar 2011 12:33:25 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 571F93A69F9 for ; Tue, 1 Mar 2011 12:33:08 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p21KYABg019665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Mar 2011 20:34:12 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p21KYAuH031850 for ; Tue, 1 Mar 2011 20:34:10 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 1048801751299011641; Tue, 01 Mar 2011 12:34:01 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Mar 2011 12:34:00 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary=Apple-Mail-17-729375642 Date: Tue, 1 Mar 2011 12:33:59 -0800 References: <20110301202907.67B403A6A8C@core3.amsl.com> To: OAuth WG Message-Id: <98237282-4E57-4CD7-AAA1-24373943CDE2@oracle.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4D6D5842.0144,ss=1,fgs=0 Subject: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-chain-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 20:33:25 -0000 --Apple-Mail-17-729375642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii After talking to some folks about OAuth protected services being able to = connect to other REST based OAuth protected services, it occurred to me = that some form of "chaining" is required to support scenarios that are = essentially message buses. The document specifies a new grant type = which enables an OAuth client that has an oauth_token from its client, = to request a new access token for another oauth protected server (which = may or may not be in another OAuth "domain"). Your feedback and contributions greatly appreciated. Phil phil.hunt@oracle.com Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 1, 2011 12:29:07 PM PST > To: phil.hunt@yahoo.com > Subject: New Version Notification for draft-hunt-oauth-chain-00=20 >=20 >=20 > A new version of I-D, draft-hunt-oauth-chain-00.txt has been = successfully submitted by Phil Hunt and posted to the IETF repository. >=20 > Filename: draft-hunt-oauth-chain > Revision: 00 > Title: Chain Grant Type for OAuth2 > Creation_date: 2011-03-01 > WG ID: Independent Submission > Number_of_pages: 10 >=20 > Abstract: > This specification defines a method by which an OAuth protected > service, can use a received oauth token from its client, to in turn, > act as a client and access another OAuth protected service in a > 'chained' profile. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --Apple-Mail-17-729375642 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Your feedback and contributions = greatly appreciated.


Begin forwarded message:

From: IETF I-D Submission = Tool <idsubmission@ietf.org>
Date: March 1, 2011 12:29:07 PM PST
To: phil.hunt@yahoo.com
Subject: New Version = Notification for draft-hunt-oauth-chain-00 =


A new version of I-D, = draft-hunt-oauth-chain-00.txt has been successfully submitted by Phil = Hunt and posted to the IETF repository.

Filename: = draft-hunt-oauth-chain
Revision: 00
Title: Chain = Grant Type for OAuth2
Creation_date: 2011-03-01
WG ID: = Independent Submission
Number_of_pages: 10

Abstract:
This = specification defines a method by which an OAuth protected
service, = can use a received oauth token from its client, to in turn,
act as a = client and access another OAuth protected service in a
'chained' = profile.



The IETF = Secretariat.



= --Apple-Mail-17-729375642-- From phil.hunt@oracle.com Tue Mar 1 16:23:49 2011 Return-Path: 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 A57D63A6A21 for ; Tue, 1 Mar 2011 16:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 q54dEccA+SIC for ; Tue, 1 Mar 2011 16:23:48 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 569273A6C10 for ; Tue, 1 Mar 2011 16:23:13 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p220OFoB017059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Mar 2011 00:24:17 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2209xtE011287 for ; Wed, 2 Mar 2011 00:24:15 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 1099530181299025447; Tue, 01 Mar 2011 16:24:07 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Mar 2011 16:24:06 -0800 From: Phil Hunt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-25-743181563 Date: Tue, 1 Mar 2011 16:24:04 -0800 In-Reply-To: <98237282-4E57-4CD7-AAA1-24373943CDE2@oracle.com> To: OAuth WG References: <20110301202907.67B403A6A8C@core3.amsl.com> <98237282-4E57-4CD7-AAA1-24373943CDE2@oracle.com> Message-Id: <4FE8C786-00C9-478C-8210-B030A559264C@oracle.com> X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4D6D8E2F.0194,ss=1,fgs=0 Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-hunt-oauth-chain-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:23:49 -0000 --Apple-Mail-25-743181563 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For those interested in the chain grant proposal, I have posted more = details on my blog:=20 = http://independentidentity.blogspot.com/2011/03/oauth-new-chain-grant-type= .html Phil phil.hunt@oracle.com On 2011-03-01, at 12:33 PM, Phil Hunt wrote: > After talking to some folks about OAuth protected services being able = to connect to other REST based OAuth protected services, it occurred to = me that some form of "chaining" is required to support scenarios that = are essentially message buses. The document specifies a new grant type = which enables an OAuth client that has an oauth_token from its client, = to request a new access token for another oauth protected server (which = may or may not be in another OAuth "domain"). >=20 > Your feedback and contributions greatly appreciated. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: IETF I-D Submission Tool >> Date: March 1, 2011 12:29:07 PM PST >> To: phil.hunt@yahoo.com >> Subject: New Version Notification for draft-hunt-oauth-chain-00=20 >>=20 >>=20 >> A new version of I-D, draft-hunt-oauth-chain-00.txt has been = successfully submitted by Phil Hunt and posted to the IETF repository. >>=20 >> Filename: draft-hunt-oauth-chain >> Revision: 00 >> Title: Chain Grant Type for OAuth2 >> Creation_date: 2011-03-01 >> WG ID: Independent Submission >> Number_of_pages: 10 >>=20 >> Abstract: >> This specification defines a method by which an OAuth protected >> service, can use a received oauth token from its client, to in turn, >> act as a client and access another OAuth protected service in a >> 'chained' profile. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-25-743181563 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii For = those interested in the chain grant proposal, I have posted more details = on my blog: 
  http://independentidentity.blogspot.com/2011/03/oauth-new-c= hain-grant-type.html


On 2011-03-01, at 12:33 PM, Phil Hunt wrote:

After talking to some = folks about OAuth protected services being able to connect to other REST = based OAuth protected services, it occurred to me that some form of = "chaining" is required to support scenarios that are essentially message = buses.  The document specifies a new grant type which enables an = OAuth client that has an oauth_token from its client, to request a new = access token for another oauth protected server (which may or may not be = in another OAuth "domain").

Your feedback and = contributions greatly appreciated.


Begin forwarded message:

From: IETF I-D Submission = Tool <idsubmission@ietf.org>
Date: March 1, 2011 12:29:07 PM PST
To: phil.hunt@yahoo.com
Subject: New Version = Notification for draft-hunt-oauth-chain-00 =


A new version of I-D, = draft-hunt-oauth-chain-00.txt has been successfully submitted by Phil = Hunt and posted to the IETF repository.

Filename: = draft-hunt-oauth-chain
Revision: 00
Title: Chain = Grant Type for OAuth2
Creation_date: 2011-03-01
WG ID: = Independent Submission
Number_of_pages: 10

Abstract:
This = specification defines a method by which an OAuth protected
service, = can use a received oauth token from its client, to in turn,
act as a = client and access another OAuth protected service in a
'chained' = profile.



The IETF = Secretariat.



_______________= ________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= = --Apple-Mail-25-743181563-- From hannes.tschofenig@gmx.net Tue Mar 1 23:31:08 2011 Return-Path: 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 BCF3A3A6A49 for ; Tue, 1 Mar 2011 23:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3UmZu+1yPOZG for ; Tue, 1 Mar 2011 23:31:07 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id C9F443A6934 for ; Tue, 1 Mar 2011 23:31:06 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2011 07:32:10 -0000 Received: from unknown (EHLO [10.255.138.199]) [192.100.123.77] by mail.gmx.net (mp049) with SMTP; 02 Mar 2011 08:32:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19kFdxAITBkiTZZmUvshcIG3YcHU0DAA7gbng9yb3 BOcO5SzSWqLw6I From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 09:32:05 +0200 Message-Id: To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 07:31:08 -0000 This is a Last Call for comments on=20 http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt Please have your comments in no later than March 16. Do remember to send a note in if you have read the document and have no=20= other comments other than "its ready to go" - we need those as much as = we need "I found a problem". Thanks! Hannes & Blaine From hannes.tschofenig@gmx.net Wed Mar 2 00:30:33 2011 Return-Path: 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 7B3CB3A6A08 for ; Wed, 2 Mar 2011 00:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 pWorpS2PgUMI for ; Wed, 2 Mar 2011 00:30:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 3A5623A6A32 for ; Wed, 2 Mar 2011 00:30:31 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2011 08:31:35 -0000 Received: from unknown (EHLO [10.255.138.199]) [192.100.123.77] by mail.gmx.net (mp055) with SMTP; 02 Mar 2011 09:31:35 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19hmPUpshRh4NSiQcW6oD0w9bKkUAR1jRZ4QIC5DJ kwk73uPk4grij3 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 10:31:33 +0200 Message-Id: <3EC990E1-78A4-4568-A2AA-1AE368862689@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 08:30:33 -0000 This is a Last Call for comments on=20 http://www.ietf.org/id/draft-ietf-oauth-v2-bearer-03.txt Please have your comments in no later than March 25 (extended deadline = because of the ongoing OAuth base specification WGLC). Do remember to send a note in if you have read the document and have no=20= other comments other than "its ready to go" - we need those as much as = we need "I found a problem". Thanks! Hannes & Blaine From bcampbell@pingidentity.com Wed Mar 2 06:04:41 2011 Return-Path: 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 7D6A03A67E3 for ; Wed, 2 Mar 2011 06:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 X0mjb9Q7AwFI for ; Wed, 2 Mar 2011 06:04:40 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by core3.amsl.com (Postfix) with ESMTP id 3FAB13A67B7 for ; Wed, 2 Mar 2011 06:04:39 -0800 (PST) Received: from source ([209.85.161.51]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTW5OuJByMlgctMsqONENjqHiMLXGhGQF@postini.com; Wed, 02 Mar 2011 06:05:46 PST Received: by fxm11 with SMTP id 11so1604fxm.24 for ; Wed, 02 Mar 2011 06:05:43 -0800 (PST) Received: by 10.223.74.73 with SMTP id t9mr104410faj.16.1299074743257; Wed, 02 Mar 2011 06:05:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.113.83 with HTTP; Wed, 2 Mar 2011 06:05:12 -0800 (PST) From: Brian Campbell Date: Wed, 2 Mar 2011 07:05:12 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 14:04:41 -0000 I propose that the "or native applications" text be dropped from the first paragraph in section 4.2 Implicit Grant [1]. There is clearly some disagreement about what is most appropriate for mobile/native applications and many, including myself, don't feel that the implicit grant works well to support them (due to the lack of a refresh token and need to repeat the authorization steps). I understand that the text in section 4 is non-normative, however, I feel that the mention of native apps in 4.2 biases thinking in a particular way (it's already led to one lengthy internal discussion that I'd rather not have again and again). I believe it'd be more appropriate for the draft to remain silent on how native apps should acquire tokens and leave it up to implementations/deployments to decide (or an extension draft as Marius has proposed). The "or native applications" text in is also somewhat inconsistent with the text in the following sentence that talks about the authentication of the client being based on the user-agent's same-origin policy. Removing those three words is a small change but one that I feel would be beneficial on a number of fronts. Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav wrote: > Feel free to propose alternative preamble for the implicit and authorization code sections, describing the characteristics of what they are good for. It should fit in a single paragraph. Such a proposal would fit right in with last call feedback to -13. > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Wednesday, February 16, 2011 1:39 PM >> To: Eran Hammer-Lahav >> Cc: Brian Campbell; OAuth WG >> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >> >> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >> wrote: >> > The reason why we don't return a refresh token in the implicit grant is >> exactly because there is no client authentication... >> >> Not sure that's the main reason. AFAIK it is because the response is sent >> through the user-agent and it could leak. >> >> >> > These are all well-balanced flows with specific security properties. If you >> need something else, even if it is just a tweak, it must be considered a >> different flow. That doesn't mean you need to register a new grant type, just >> that you are dealing with different implementation details unique to your >> server. >> >> The Authorization Code flow, with no client secret, is perfectly fine for Native >> Apps IMO. >> >> Marius > From ietf@adambarth.com Fri Feb 25 23:09:22 2011 Return-Path: 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 694F53A691B; Fri, 25 Feb 2011 23:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 6JxNyhCSLUAO; Fri, 25 Feb 2011 23:09:16 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AABEB3A68A0; Fri, 25 Feb 2011 23:09:16 -0800 (PST) Received: by iwl42 with SMTP id 42so1902795iwl.31 for ; Fri, 25 Feb 2011 23:10:11 -0800 (PST) Received: by 10.231.161.15 with SMTP id p15mr3530063ibx.104.1298704210675; Fri, 25 Feb 2011 23:10:10 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id 8sm1627920iba.22.2011.02.25.23.10.09 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 23:10:09 -0800 (PST) Received: by iwl42 with SMTP id 42so1902774iwl.31 for ; Fri, 25 Feb 2011 23:10:09 -0800 (PST) Received: by 10.231.160.80 with SMTP id m16mr3552715ibx.106.1298704209087; Fri, 25 Feb 2011 23:10:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.40.7 with HTTP; Fri, 25 Feb 2011 23:09:39 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1127DCD2142@WSMSG3153V.srv.dir.telstra.com> From: Adam Barth Date: Fri, 25 Feb 2011 23:09:39 -0800 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 02 Mar 2011 08:01:36 -0800 Cc: "websec@ietf.org" , OAuth Mailing List Subject: Re: [OAUTH-WG] [websec] Indicating origin of OAuth credentials to combat login CSRF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 07:09:23 -0000 On Thu, Feb 24, 2011 at 4:08 PM, Manger, James H wrote: > Q. Should an OAuth client app list the authorization server in the Origin > header of requests to resource servers? They are allowed to, but are not required to, by the Origin header specification. Whether they should or not is a question for the OAuth working group to decide. Adam > In OAuth (delegation) flows a server dynamically issues credentials (such= as > a bearer token) to a client app to use in subsequent HTTP requests to oth= er > servers. To combat login cross-site request forgery (CSRF) attacks [1] > (where an attacker=92s server issues the attacker=92s credentials to a cl= ient > app to use on behalf of a victim at a legitimate server) the client app > needs to indicate where the credentials came from. The Origin header [2] > looks like the right place to indicate this. > > > > [For the OAuth list: The Origin HTTP request header =93indicates the orig= in(s) > that caused the user agent to issue the request=94 > [http://tools.ietf.org/html/draft-ietf-websec-origin-00#section-6.2].] > > > > [For the WebSec list: An OAuth credential from an authorization server is= a > bit like a cookie, but not restricted to the same origin.] > > > > > > Example: > > > > =A0 Client to (malicious) authorization server: -> > > =A0 =A0=A0POST /token HTTP/1.1 > > =A0 =A0=A0Host: login.example.com > > =A0 =A0=A0=85 > > =A0 <- > > =A0 =A0=A0HTTP/1.1 200 OK > > =A0 =A0=A0=85 > > =A0 =A0=A0{ "access_token": "SlAV32hkKG", =85} > > > > =A0 Client to resource server: -> > > =A0 =A0=A0POST /uploadData HTTP/1.1 > > =A0 =A0=A0Host: api.exampledata.com > > =A0 =A0=A0Authorization: BEARER SlAV32hkKG > > =A0 =A0=A0Origin: https://login.example.com > > =A0=A0=A0 =85 > > > > > > There can be other servers that contribute to a client app making a reque= st. > For instance, one server can redirect to another. A Origin request header > can list multiple origins. The server will not be able to distinguish whi= ch > origin issued OAuth credentials from which issued a redirect etc. That mi= ght > not matter if a server has to trust all the values listed in the Origin > header. > > Q. Is it the group=92s expectation that servers checking the Origin heade= r > will require all the listed origins to be trusted? > > > > [1] Robust Defenses for Cross Site Request Forgery, > http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf > > [2] The Web Origin Concept, > http://tools.ietf.org/html/draft-ietf-websec-origin > > [3] Principles of the Same Origin Policy, > http://tools.ietf.org/html/draft-abarth-principles-of-origin > > > > -- > > James Manger > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > From eran@hueniverse.com Wed Mar 2 08:32:50 2011 Return-Path: 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 B371B3A6831 for ; Wed, 2 Mar 2011 08:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] 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 56D2x9M7FDHL for ; Wed, 2 Mar 2011 08:32:49 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3D04E3A682C for ; Wed, 2 Mar 2011 08:32:49 -0800 (PST) Received: (qmail 15806 invoked from network); 2 Mar 2011 16:33:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Mar 2011 16:33:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Mar 2011 09:33:47 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , OAuth WG Date: Wed, 2 Mar 2011 09:33:40 -0700 Thread-Topic: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt Thread-Index: AcvYtETztIMdYVRmR0yEWy35xSKtpQAPcMHA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3D88@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3EC990E1-78A4-4568-A2AA-1AE368862689@gmx.net> In-Reply-To: <3EC990E1-78A4-4568-A2AA-1AE368862689@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:32:50 -0000 Last call comments on draft-ietf-oauth-v2-bearer-03: Section 2.1: - ABNF includes '1#auth-param', but no prose is provided about how new para= meters may be defined. There is no reason for this scheme to be extensible,= given its designed simplicity and limitations. If more attributes are need= ed in the future, a new scheme must be defined. - RWS should be replaces with SP since the header has no other attributes (= and should not have any). This will make parsing easier by mandating a sing= le space (unless HTTPbis has other guidelines). Section 2.4: - Realm is a required attribute per RFC 2617. While discussions about this = are on-going in HTTPbis (open issue), this document must comply with the cu= rrent standard. If the WG feels strongly about it, it should engage the HTT= Pbis working group and provide feedback. - ABNF includes '( token "=3D" ( token / quoted-string ) )', but no prose i= s provided about how new parameters may be defined. Retained this extensibi= lity point must be justified with actual use cases. Section 2.4.1: - Why are the HTTP error code suggested and not required? Section 4.1.1: - There is no 'Additional Resource Request Parameters' in the template - re= move. - Missing 'Additional Token Endpoint Response Parameters: None'. Section 4.2: - The entire registry is ridiculous. Protected resource endpoints are compl= etely within the authority of the resource provider. The fact that this doc= ument defines the 'oauth_token' parameter which infringes on the provider's= namespace is bad enough. To suggest that this document has any authority o= ver other parameters defined and used by the resource server is overreachin= g. No single use cases has been suggested for this registry in over three y= ears of OAuth work. Section 4.2.2.2: - There is no 'error' parameter for resource responses. It is not defined a= nywhere in this specification or elsewhere. There is an 'error' attribute d= efined for the WWW-Authenticate header, but so is 'error_description' and '= error_uri'. How exactly is this parameter added to the resource response i= f not in the header? If it is in the header, there is no such location in t= he registry (nor is header extensibility discussed see 2.4). Section 4.3: - This registry is unnecessary and adds no value here (namespace collision = is unlikely in general, and unlikely to cause problems). No use cases where= suggested to justify it, and no additional error codes were proposed in ov= er a year of discussions. Error codes were intentionally left non-extensibl= e to increase interoperability. If addition color is needed for existing er= ror codes, additional response parameters may be registered. Otherwise, if = new error codes are needed, a new RFC must be published updating draft-ietf= -oauth-v2. - The only way to define such a registry is to bring it up as a comment for= draft-ietf-oauth-v2. Otherwise, it is limited to the Bearer token header o= nly (and since this document is not extensible, not needed even here). This document is not ready for publication. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Wednesday, March 02, 2011 12:32 AM > To: OAuth WG > Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt >=20 > This is a Last Call for comments on >=20 > http://www.ietf.org/id/draft-ietf-oauth-v2-bearer-03.txt >=20 > Please have your comments in no later than March 25 (extended deadline > because of the ongoing OAuth base specification WGLC). >=20 > Do remember to send a note in if you have read the document and have no > other comments other than "its ready to go" - we need those as much as we > need "I found a problem". >=20 > Thanks! > Hannes & Blaine > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From craig.heath@wacapps.net Wed Mar 2 10:03:12 2011 Return-Path: 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 437D83A683E for ; Wed, 2 Mar 2011 10:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 fBiFUl0jKcpj for ; Wed, 2 Mar 2011 10:03:11 -0800 (PST) Received: from out02.themessagecenter.com (out02.themessagecenter.com [208.113.96.229]) by core3.amsl.com (Postfix) with ESMTP id 69C403A683A for ; Wed, 2 Mar 2011 10:03:11 -0800 (PST) Received: from [192.168.66.109] by out02.themessagecenter.com with ESMTP (Tumbleweed Email Firewall SMTP Relay); Wed, 02 Mar 2011 09:52:25 -0800 X-Server-Uuid: 385D78BC-A8BE-4780-80CD-A503E34C32DD Received: from EX-CH-002-SFO.shared.themessagecenter.com (192.168.66.93) by EX-CH-004-SFO.shared.themessagecenter.com (192.168.66.111) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Mar 2011 10:04:07 -0800 Received: from ex-be-016-sfo.shared.themessagecenter.com ( [192.168.66.102]) by EX-CH-002-SFO.shared.themessagecenter.com ( [64.151.95.180]) with mapi; Wed, 2 Mar 2011 10:04:07 -0800 From: "Craig Heath" To: "oauth@ietf.org" Date: Wed, 2 Mar 2011 10:05:15 -0800 Thread-Topic: RFC5849 - Purpose of Temporary Credentials Shared Secret? Thread-Index: AcvZAYG4U5dLvKGJQXyOocum691xEQ== Message-ID: <4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63@EX-BE-016-SFO.shared.themessagecenter.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61705C533PS15352902-01-01 Content-Type: multipart/alternative; boundary=_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63EXBE016SFOsha_ Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secret? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:48:35 -0000 --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63EXBE016SFOsha_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello! Can some kind soul help me understand the purpose of the shared sec= ret part of the Temporary Credentials in RFC5849? - The client authenticates using the Cient Credentials, and gets the Tempor= ary Credentials. - The Resource Owner gives their authorization. - The Temporary Credentials are then used in the Token Credentials Request. The part that's puzzling me is the RFC says the client authenticates using = *both* the Client Credentials and the Token Credentials in the Token Creden= tials Request. I could understand one or the other, but why both? (and inc= identally, how can it provide both?) Clearly the Token Credentials identif= ier is needed, as it is part of the Token Credentials Request; it's only th= e shared secret I'm wondering about (the "oauth_token_secret" part of the r= eponse to the Temporary Credentials Request). My best guess so far is that it is intended to allow for the case when the = Client Credentials are not secret, but in that case why use the Client Cred= entials at all in the Token Credential Request? Thanks for any light shed on this! - Craig Heath. --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63EXBE016SFOsha_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hello!  Can= some kind soul help me understand the purpose of the shared secret part of= the Temporary Credentials in RFC5849?

<= o:p> 

- The client authenticates using t= he Cient Credentials, and gets the Temporary Credentials.

- The Resource Owner gives their authorization.

- The Temporary Credentials are then used in the = Token Credentials Request.

 

The part that's puzzling me is the RFC says th= e client authenticates using *both* the Client Credentials and the Token Cr= edentials in the Token Credentials Request.  I could understand one or= the other, but why both? (and incidentally, how can it provide both?) = ; Clearly the Token Credentials identifier is needed, as it is part of the = Token Credentials Request; it's only the shared secret I'm wondering about = (the "oauth_token_secret" part of the reponse to the Temporary Cr= edentials Request).

 

My best guess so far is that it is intended to allow = for the case when the Client Credentials are not secret, but in that case w= hy use the Client Credentials at all in the Token Credential Request?<= /o:p>

 

Tha= nks for any light shed on this!

&n= bsp;

- Craig Heath.

= --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63EXBE016SFOsha_-- From craig.heath@wacapps.net Wed Mar 2 11:51:26 2011 Return-Path: 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 327CF3A6889 for ; Wed, 2 Mar 2011 11:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.140, 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 mdY09LYpZZGD for ; Wed, 2 Mar 2011 11:51:23 -0800 (PST) Received: from out02.themessagecenter.com (out02.themessagecenter.com [208.113.96.229]) by core3.amsl.com (Postfix) with ESMTP id CC83F3A687E for ; Wed, 2 Mar 2011 11:51:23 -0800 (PST) Received: from [192.168.66.92] by out02.themessagecenter.com with ESMTP (Tumbleweed Email Firewall SMTP Relay); Wed, 02 Mar 2011 11:40:37 -0800 X-Server-Uuid: 385D78BC-A8BE-4780-80CD-A503E34C32DD Received: from EX-CH-002-SFO.shared.themessagecenter.com (192.168.66.89) by EX-CH-001-SFO.shared.themessagecenter.com (192.168.66.88) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Mar 2011 11:52:18 -0800 Received: from ex-be-016-sfo.shared.themessagecenter.com ( [192.168.66.102]) by EX-CH-002-SFO.shared.themessagecenter.com ( [64.151.95.180]) with mapi; Wed, 2 Mar 2011 11:52:18 -0800 From: "Craig Heath" To: "Craig Heath" , "oauth@ietf.org" Date: Wed, 2 Mar 2011 11:53:27 -0800 Thread-Topic: RFC5849 - Purpose of Temporary Credentials Shared Secret? Thread-Index: AcvZAYG4U5dLvKGJQXyOocum691xEQAEbxrA Message-ID: <4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C95@EX-BE-016-SFO.shared.themessagecenter.com> References: <4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63@EX-BE-016-SFO.shared.themessagecenter.com> In-Reply-To: <4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63@EX-BE-016-SFO.shared.themessagecenter.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 617042BF3PS15398640-01-01 Content-Type: multipart/alternative; boundary=_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C95EXBE016SFOsha_ Subject: Re: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secret? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:51:26 -0000 --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C95EXBE016SFOsha_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Oops, just noticed a typo in my previous message, I meant: " The part that's puzzling me is the RFC says the client authenticates usin= g *both* the Client Credentials and the _Temporary_ Credentials in the Toke= n Credentials Request. I could understand one or the other, but why both? = (and incidentally, how can it provide both?) Clearly the _Temporary_ Crede= ntials identifier is needed, as it is part of the Token Credentials Request= ; it's only the shared secret I'm wondering about (the "oauth_token_secret"= part of the reponse to the Temporary Credentials Request)." Sorry! - Craig. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= raig Heath Sent: 02 March 2011 18:05 To: oauth@ietf.org Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secre= t? Hello! Can some kind soul help me understand the purpose of the shared sec= ret part of the Temporary Credentials in RFC5849? - The client authenticates using the Cient Credentials, and gets the Tempor= ary Credentials. - The Resource Owner gives their authorization. - The Temporary Credentials are then used in the Token Credentials Request. The part that's puzzling me is the RFC says the client authenticates using = *both* the Client Credentials and the Token Credentials in the Token Creden= tials Request. I could understand one or the other, but why both? (and inc= identally, how can it provide both?) Clearly the Token Credentials identif= ier is needed, as it is part of the Token Credentials Request; it's only th= e shared secret I'm wondering about (the "oauth_token_secret" part of the r= eponse to the Temporary Credentials Request). My best guess so far is that it is intended to allow for the case when the = Client Credentials are not secret, but in that case why use the Client Cred= entials at all in the Token Credential Request? Thanks for any light shed on this! - Craig Heath. --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C95EXBE016SFOsha_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Oops, just noticed a typo in my previous message, I meant:

=  

&= quot; The part that's puzzling me is the RFC says the client authenticates = using *both* the Client Credentials and the _Temporary_ Credentials in the = Token Credentials Request.  I could understand one or the other, but w= hy both? (and incidentally, how can it provide both?)  Clearly the _Te= mporary_ Credentials identifier is needed, as it is part of the Token Crede= ntials Request; it's only the shared secret I'm wondering about (the "= oauth_token_secret" part of the reponse to the Temporary Credentials R= equest)."

 

Sorry!

 

- Craig.

=  

From: oauth-bounces@ietf.org [mailto:oaut= h-bounces@ietf.org] On Behalf Of Craig Heath
Sent: 02 March 2011 18:05To: oauth@ietf.org
Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary = Credentials Shared Secret?

 

Hello!  Can some kind soul help me underst= and the purpose of the shared secret part of the Temporary Credentials in R= FC5849?

 

- The client authenticates using the Cient Credentials, and gets t= he Temporary Credentials.

- The Resource Owner gives their authorization.=

- The T= emporary Credentials are then used in the Token Credentials Request.

&nbs= p;

The p= art that's puzzling me is the RFC says the client authenticates using *both= * the Client Credentials and the Token Credentials in the Token Credentials= Request.  I could understand one or the other, but why both? (and inc= identally, how can it provide both?)  Clearly the Token Credentials id= entifier is needed, as it is part of the Token Credentials Request; it's on= ly the shared secret I'm wondering about (the "oauth_token_secret"= ; part of the reponse to the Temporary Credentials Request).

 =

My best guess= so far is that it is intended to allow for the case when the Client Creden= tials are not secret, but in that case why use the Client Credentials at al= l in the Token Credential Request?

 

Thanks for any light shed on this!

&= nbsp;

- = Craig Heath.

= --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C95EXBE016SFOsha_-- From eran@hueniverse.com Wed Mar 2 12:26:26 2011 Return-Path: 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 CDED33A6823 for ; Wed, 2 Mar 2011 12:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.051, 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 vqFLD61OMa-C for ; Wed, 2 Mar 2011 12:26:24 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5124E3A6816 for ; Wed, 2 Mar 2011 12:26:21 -0800 (PST) Received: (qmail 23195 invoked from network); 2 Mar 2011 20:27:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Mar 2011 20:27:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Mar 2011 13:27:04 -0700 From: Eran Hammer-Lahav To: Craig Heath , "oauth@ietf.org" Date: Wed, 2 Mar 2011 13:26:57 -0700 Thread-Topic: RFC5849 - Purpose of Temporary Credentials Shared Secret? Thread-Index: AcvZAYG4U5dLvKGJQXyOocum691xEQAFn/sw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3E9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63@EX-BE-016-SFO.shared.themessagecenter.com> In-Reply-To: <4EDB411A4D566C45BE3AB6E0152BFAF92761AC1C63@EX-BE-016-SFO.shared.themessagecenter.com> 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_90C41DD21FB7C64BB94121FBBC2E7234464F0C3E9DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secret? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:26:26 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3E9DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Because it uses the same method of making authenticated requests as everyth= ing else. It's just a result of pushing everything through a single functio= n. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= raig Heath Sent: Wednesday, March 02, 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secre= t? Hello! Can some kind soul help me understand the purpose of the shared sec= ret part of the Temporary Credentials in RFC5849? - The client authenticates using the Cient Credentials, and gets the Tempor= ary Credentials. - The Resource Owner gives their authorization. - The Temporary Credentials are then used in the Token Credentials Request. The part that's puzzling me is the RFC says the client authenticates using = *both* the Client Credentials and the Token Credentials in the Token Creden= tials Request. I could understand one or the other, but why both? (and inc= identally, how can it provide both?) Clearly the Token Credentials identif= ier is needed, as it is part of the Token Credentials Request; it's only th= e shared secret I'm wondering about (the "oauth_token_secret" part of the r= eponse to the Temporary Credentials Request). My best guess so far is that it is intended to allow for the case when the = Client Credentials are not secret, but in that case why use the Client Cred= entials at all in the Token Credential Request? Thanks for any light shed on this! - Craig Heath. --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3E9DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Because it uses the same method of making authenticated reque= sts as everything else. It’s just a result of pushing everything thro= ugh a single function.

 

EHL

 

<= p class=3DMsoNormal>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.o= rg] On Behalf Of Craig Heath
Sent: Wednesday, March 02, 20= 11 10:05 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] RFC5= 849 - Purpose of Temporary Credentials Shared Secret?

=

 

= Hello!  Can some kind soul help me understand the p= urpose of the shared secret part of the Temporary Credentials in RFC5849?

 

- The client authentic= ates using the Cient Credentials, and gets the Temporary Credentials.<= /o:p>

- The Resource Owne= r gives their authorization.

- The Temporary Credentials are then used in the Token Crede= ntials Request.

 

The p= art that's puzzling me is the RFC says the client authenticates using *both= * the Client Credentials and the Token Credentials in the Token Credentials= Request.  I could understand one or the other, but why both? (and inc= identally, how can it provide both?)  Clearly the Token Credentials id= entifier is needed, as it is part of the Token Credentials Request; it's on= ly the shared secret I'm wondering about (the "oauth_token_secret"= ; part of the reponse to the Temporary Credentials Request).

 

=

My best guess so far is that it is = intended to allow for the case when the Client Credentials are not secret, = but in that case why use the Client Credentials at all in the Token Credent= ial Request?

<= o:p> 

Thanks f= or any light shed on this!

 

- Craig Heath.

= --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3E9DP3PW5EX1MB01E_-- From craig.heath@wacapps.net Wed Mar 2 12:56:19 2011 Return-Path: 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 CD72C3A686E for ; Wed, 2 Mar 2011 12:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, 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 74Y2pHFDm2SZ for ; Wed, 2 Mar 2011 12:56:18 -0800 (PST) Received: from out02.themessagecenter.com (out02.themessagecenter.com [208.113.96.229]) by core3.amsl.com (Postfix) with ESMTP id A41C33A6874 for ; Wed, 2 Mar 2011 12:56:18 -0800 (PST) Received: from [192.168.66.109] by out02.themessagecenter.com with ESMTP (Tumbleweed Email Firewall SMTP Relay); Wed, 02 Mar 2011 12:45:32 -0800 X-Server-Uuid: 385D78BC-A8BE-4780-80CD-A503E34C32DD Received: from EX-CH-002-SFO.shared.themessagecenter.com (192.168.66.93) by EX-CH-004-SFO.shared.themessagecenter.com (192.168.66.109) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Mar 2011 12:57:14 -0800 Received: from ex-be-016-sfo.shared.themessagecenter.com ( [192.168.66.102]) by EX-CH-002-SFO.shared.themessagecenter.com ( [64.151.95.180]) with mapi; Wed, 2 Mar 2011 12:57:14 -0800 From: "Craig Heath" To: "oauth@ietf.org" Date: Wed, 2 Mar 2011 12:57:13 -0800 Thread-Topic: RFC5849 - Purpose of Temporary Credentials Shared Secret? Thread-Index: AcvZAYG4U5dLvKGJQXyOocum691xEQAFn/swAAEZosY= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 617073E63PS15422066-01-01 Content-Type: multipart/alternative; boundary=_000_Ns3TvYk5gRSfHZMCnr0d_ Subject: Re: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secret? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:56:19 -0000 --_000_Ns3TvYk5gRSfHZMCnr0d_ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the quick response! Can I ask a more specific question: What's= the security purpose of the Temporary Credentials shared secret? If an im= plementation were to, say, always use an empty string, would it make any di= fference to the security of the protocol? - Craig. -----Original Message----- From: Eran Hammer-Lahav Sent: 02-03-2011, 8:27 pm To: Craig Heath; oauth@ietf.org Subject: RE: RFC5849 - Purpose of Temporary Credentials Shared Secret? Because it uses the same method of making authenticated requests as everyth= ing else. It=92s just a result of pushing everything through a single funct= ion. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= raig Heath Sent: Wednesday, March 02, 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secre= t? Hello! Can some kind soul help me understand the purpose of the shared sec= ret part of the Temporary Credentials in RFC5849? - The client authenticates using the Cient Credentials, and gets the Tempor= ary Credentials. - The Resource Owner gives their authorization. - The Temporary Credentials are then used in the Token Credentials Request. The part that's puzzling me is the RFC says the client authenticates using = *both* the Client Credentials and the Token Credentials in the Token Creden= tials Request. I could understand one or the other, but why both? (and inc= identally, how can it provide both?) Clearly the Token Credentials identif= ier is needed, as it is part of the Token Credentials Request; it's only th= e shared secret I'm wondering about (the "oauth_token_secret" part of the r= eponse to the Temporary Credentials Request). My best guess so far is that it is intended to allow for the case when the = Client Credentials are not secret, but in that case why use the Client Cred= entials at all in the Token Credential Request? Thanks for any light shed on this! - Craig Heath. --_000_Ns3TvYk5gRSfHZMCnr0d_ Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 
Thanks for the quick response!  Can I ask a more specific quest=
ion:  What's the security purpose of the Temporary Credentials shared secre=
t?  If an implementation were to, say, always use an empty string, would it=
 make any difference to the security of the protocol?

- Craig.
-----Original Message-----
From: Eran Hammer-Lahav
Sent:  02-03-2011, 8:27  pm
To: Craig Heath; oauth@ietf.org
Subject: RE: RFC5849 - Purpose of Temporary Credentials Shared Secret?

Because it uses the sa= me method of making authenticated requests as everything else. It=92s just = a result of pushing everything through a single function.=

 

EHL<= /p>

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Craig Heath
Sent: Wednesday, March 02, 2011 10:05 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Share= d Secret?

 

Hello!  Can some kind soul= help me understand the purpose of the shared secret part of the Temporary = Credentials in RFC5849?

 

- The client authenticates usin= g the Cient Credentials, and gets the Temporary Credentials.

- The Resource Owner gives thei= r authorization.

- The Temporary Credentials are= then used in the Token Credentials Request.

 

The part that's puzzling me is = the RFC says the client authenticates using *both* the Client Credentials a= nd the Token Credentials in the Token Credentials Request.  I could un= derstand one or the other, but why both? (and incidentally, how can it provide both?)  Clearly the Token Crede= ntials identifier is needed, as it is part of the Token Credentials Request= ; it's only the shared secret I'm wondering about (the "oauth_token_se= cret" part of the reponse to the Temporary Credentials Request).

 

My best guess so far is that it= is intended to allow for the case when the Client Credentials are not secr= et, but in that case why use the Client Credentials at all in the Token Cre= dential Request?

 

Thanks for any light shed on th= is!

 

- Craig Heath.

--_000_Ns3TvYk5gRSfHZMCnr0d_-- From huilan.lu@alcatel-lucent.com Wed Mar 2 15:22:17 2011 Return-Path: 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 E3ADD3A68B7 for ; Wed, 2 Mar 2011 15:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 8U6AfLxSYUjb for ; Wed, 2 Mar 2011 15:22:15 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E1A0D3A687D for ; Wed, 2 Mar 2011 15:22:14 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p22NNGOJ019124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 17:23:16 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p22NNFak019296 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Mar 2011 17:23:15 -0600 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 2 Mar 2011 17:23:15 -0600 From: "Lu, Hui-Lan (Huilan)" To: "'Torsten Lodderstedt'" , Eric Date: Wed, 2 Mar 2011 17:23:14 -0600 Thread-Topic: [OAUTH-WG] validate authorization code in draft 12 Thread-Index: AcvHCXuSlyw/KjdaSx2Gy4J3t7p6ggSHjW/w Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058DBA1DCB@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4D39442B.2090408@cs.stanford.edu> <4D505C6F.7090209@lodderstedt.net> In-Reply-To: <4D505C6F.7090209@lodderstedt.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_0E96A74B7DFCF844A9BE2A0BBE2C425F058DBA1DCBUSNAVSXCHMBSB_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] validate authorization code in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:22:18 -0000 --_000_0E96A74B7DFCF844A9BE2A0BBE2C425F058DBA1DCBUSNAVSXCHMBSB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Tosten. A healthy client is not expected to issue an access to= ken request unconditionally when receiving an authorization code at its red= irect_uri. The client should do so only if it is in the right state with a = correlatable authorization request pending. Best regards, Huilan LU CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er person, use it for any purpose, or store or copy the information in any = medium. Copyright in this e-mail and any attachments belongs to Alcatel-Luc= ent and/or its affiliated entities. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= orsten Lodderstedt Sent: Monday, February 07, 2011 3:56 PM To: Eric Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] validate authorization code in draft 12 Hi Eric, I'm trying to understand the attack you described. I would expect any clien= t to mark its web sessions if it triggers an authorization process. If so, = the attacker would need to forge a valid client session in the right state = (authz process in progress) in order to place a sucessful attack. For a typ= ical web application this would require the attacker to login to this app a= nd kick off the authorization process. This requires more than one addition= al http call. What do you think? regards, Torsten. Am 21.01.2011 09:30, schrieb Eric: Eran, and others, A few of us had some discussions on the authorization code flow, as depicte= d in Fig. 3 of the current (12th) draft. We think that it is probably worth= while to suggest in the specification that an OAuth implementation SHOULD p= rovide a way for the client to validate the authorization code before sendi= ng it to the Authorization Server (AS). From what we have heard, this has = been done in some of the current OAuth deployments. There are other people = who do not think this is such a big security risk, although so far no one h= as objected that there is some risk here. The issue is that according to the current draft, someone who owns a botnet= can locate the redirect URIs of clients that listen on HTTP, and access th= em with random authorization codes, and cause HTTPS connections to be made = on the Authorization Server (AS). There are a few things that the attacker = can achieve with this OAuth flow that he cannot easily achieve otherwise : 1. Cost magnification: the attacker incurs the cost of an HTTP connection a= nd causes an HTTPS connection to be made on the AS; and he can co-ordinate = the timing of such HTTPS connections across multiple clients relatively eas= ily, if these clients blindly connect to the AS without first validating th= e authorization codes received. Although the attacker could achieve something similar, say by including an = iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web= users to visit that page, timing attacks using such a scheme is (say for = the purpose of DDoS) more difficult . 2. Connection laundering: if the AS realizes it is flooded by HTTPS connect= ions with illegitimate codes, it collects no useful information about the a= ttacker, since the clients act as relays. 3. CSRF defense/the 'state' parameter don't completely address this problem= . With such a defense, the attacker might need to incur an additional HTTP = request to obtain a valid CSRF code/ state parameter. This does cut down th= e effectiveness of the attack by a factor of 2, which is good. However, if = the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to= be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.htm= l), the attacker still achieves a cost magnification. Our proposal is that the OAuth specification suggests that an OAuth impleme= ntation SHOULD provide a way for the client to validate the authorization c= ode before sending it to the Authorization Server (AS). The specifics of h= ow to validate the authorization code may not need to be part of the core s= pecification. We sketch a design below for consideration for future impleme= ntation. It might be reasonable to assume that OAuth implementations provid= e some API for the client to call to validate and send the authorization co= de to the AS. There are two possible schemes for implementation: a) if the = client and the AS already share a symmetric secret, an HMAC key can be crea= ted from the shared secret, and the authorization code will be HMAC'ed and = standard techniques can be employed in the client-side API implementation t= o detect replay and forgery attempts on the code; b) an alternative is for = the AS to sign the code using the private key from its SSL certificate, and= for the client API to validate the signature using the public key. On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav wrote: Draft -12 is finally out. This is almost a complete rewrite of the entire document, with the primary = goal of moving it back to a similar structure used in -05. I have been thin= king about this for a few months and finally came up with a structure that = combines the two approaches. The draft includes some major cleanups, significantly simpler language, red= uces repeated prose, and tried to keep prose to the introduction and normat= ive language in the rest of the specification. I took out sections that bro= ke the flow, and did my best to give this a linear narrative that is easy t= o follow. The draft includes the following normative changes: o Clarified 'token_type' as case insensitive. o Authorization endpoint requires TLS when an access token is issued. o Removed client assertion credentials, mandatory HTTP Basic authenticat= ion support for client credentials, WWW-Authenticate header, and the OAuth2= authentication scheme. o Changed implicit grant (aka user-agent flow) error response from query= to fragment. o Removed the 'redirect_uri_mismatch' error code since in such a case, t= he authorization server must not send the error back to the client. o Defined access token type registry. I would like to spend the coming week receiving and applying feedback befor= e requesting a WGLC for everything but the security considerations section = (missing) 2/1. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Thursday, January 20, 2011 4:45 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Open Authentication Protocol Working Gro= up > of the IETF. > > > Title : The OAuth 2.0 Authorization Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-12.txt > Pages : 46 > Date : 2011-01-20 > > This specification describes the OAuth 2.0 authorization protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. _______________________________________________ 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 --_000_0E96A74B7DFCF844A9BE2A0BBE2C425F058DBA1DCBUSNAVSXCHMBSB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Tosten. A healthy=20 client is not expected to issue an access token request unconditionally=20 when receiving an authorization code at its redirect_uri. The=20 client should do so only if it is in the right state with a=20 correlatable authorization request pending. =   
 
Best regards,

Huilan LU


CONFIDENTIALI= TY=20 NOTICE: This e-mail and any files attached may contain confidential and=20 proprietary information of Alcatel-Lucent and/or its affiliated entities. A= ccess=20 by the intended recipient only is authorized. Any liability arising from an= y=20 party acting, or refraining from acting, on any information contained in th= is=20 e-mail is hereby excluded. If you are not the intended recipient, please no= tify=20 the sender immediately, destroy the original transmission and its attachmen= ts=20 and do not disclose the contents to any other person, use it for any purpos= e, or=20 store or copy the information in any medium. Copyright in this e-mail and a= ny=20 attachments belongs to Alcatel-Lucent and/or its affiliated=20 entities.
 

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten=20 Lodderstedt
Sent: Monday, February 07, 2011 3:56 PM
To:=20 Eric
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] valid= ate=20 authorization code in draft 12

Hi Eric,

I'm trying to understand the attack you descri= bed.=20 I would expect any client to mark its web sessions if it triggers an=20 authorization process. If so, the attacker would need to forge a valid cl= ient=20 session in the right state (authz process in progress) in order to place = a=20 sucessful attack. For a typical web application this would require the=20 attacker to login to this app and kick off the authorization process. Thi= s=20 requires more than one additional http call.

What do you=20 think?

regards,
Torsten.

Am 21.01.2011 09:30, schrieb E= ric:=20
Era= n, and=20 others,

A few of us had some discussions on the authorization co= de=20 flow, as depicted in Fig. 3 of the current (12th) draft. We think that = it is=20 probably worthwhile to suggest in the specification that an OAuth=20 implementation SHOULD provide a way for the client to validate the=20 authorization code before sending it to the  Authorization Server = (AS).=20 From what we have heard, this has been done in some of the current OAut= h=20 deployments. There are other people who do not think this is such a big= =20 security risk, although so far no one has objected that there is some r= isk=20 here.

The issue is that according to the current draft, someone = who=20 owns a botnet can locate the redirect URIs of clients that listen on HT= TP,=20 and access them with random authorization codes, and cause HTTPS connec= tions=20 to be made on the Authorization Server (AS). There are a few things tha= t the=20 attacker can achieve with this OAuth flow that he cannot easily achieve= =20 otherwise :

1. Cost magnification: the attacker incurs the cost= of=20 an HTTP connection and causes an HTTPS connection to be made on the AS;= and=20 he can co-ordinate the timing of such HTTPS connections across multiple= =20 clients relatively easily, if these clients blindly connect to the AS=20 without first validating the authorization codes received.

Altho= ugh=20 the attacker could achieve something similar, say by including an ifram= e=20 pointing to the HTTPS URL of the AS in an HTTP web page and lure web&nb= sp;=20 users to visit that page, timing attacks using such a scheme is (say fo= r the=20 purpose of DDoS) more difficult .

2. Connection laundering: if t= he AS=20 realizes it is flooded by HTTPS connections with illegitimate codes, it= =20 collects no useful information about the attacker, since the clients ac= t as=20 relays. 

3. CSRF defense/the 'state' parameter don't compl= etely=20 address this problem. With such a defense, the attacker might need to i= ncur=20 an additional HTTP request to obtain a valid CSRF code/ state parameter= .=20 This does cut down the effectiveness of the attack by a factor of 2, wh= ich=20 is good. However, if the HTTPS/HTTP cost ratio is higher than 2 (the co= st=20 factor is estimated to be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-l= atency.html),=20 the attacker still achieves a cost magnification.

Our proposal i= s=20 that the OAuth specification suggests that an OAuth implementation SHOU= LD=20 provide a way for the client to validate the authorization code before= =20 sending it to the  Authorization Server (AS). The specifics of how= to=20 validate the authorization code may not need to be part of the core=20 specification. We sketch a design below for consideration for future=20 implementation. It might be reasonable to assume that OAuth implementat= ions=20 provide some API for the client to call to validate and send the=20 authorization code to the AS. There are two possible schemes for=20 implementation: a) if the client and the AS already share a symmetric=20 secret, an HMAC key can be created from the shared secret, and the=20 authorization code will be HMAC'ed and standard techniques can be emplo= yed=20 in the client-side API implementation to detect replay and forgery atte= mpts=20 on the code; b) an alternative is for the AS to sign the code using the= =20 private key from its SSL certificate, and for the client API to validat= e the=20 signature using the public key.

 

On Thu, Jan 20, 2011 at 4:56 PM, Eran=20 Hammer-Lahav <eran@hueniverse.com> wrote:
Draft=20 -12 is finally out.

This is almost a complete rewrite of the e= ntire=20 document, with the primary goal of moving it back to a similar struct= ure=20 used in -05. I have been thinking about this for a few months and fin= ally=20 came up with a structure that combines the two approaches.

The= =20 draft includes some major cleanups, significantly simpler language,=20 reduces repeated prose, and tried to keep prose to the introduction a= nd=20 normative language in the rest of the specification. I took out secti= ons=20 that broke the flow, and did my best to give this a linear narrative = that=20 is easy to follow.

The draft includes the following normative= =20 changes:

  o  Clarified 'token_type' as case=20 insensitive.
  o  Authorization endpoint requires TLS wh= en an=20 access token is issued.
  o  Removed client assertion=20 credentials, mandatory HTTP Basic authentication support for client=20 credentials, WWW-Authenticate header, and the OAuth2 authentication=20 scheme.
  o  Changed implicit grant (aka user-agent flow= )=20 error response from query to fragment.
  o  Removed the= =20 'redirect_uri_mismatch' error code since in such a case, the authoriz= ation=20 server must not send the error back to the client.
  o=20  Defined access token type registry.

I would like to spen= d the=20 coming week receiving and applying feedback before requesting a WGLC = for=20 everything but the security considerations section (missing)=20 2/1.

EHL



> -----Original Message-----
>=20 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf>=20 Of Internet-Drafts@ietf.org
> Sent:=20 Thursday, January 20, 2011 4:45 PM
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-W= G] I-D=20 Action:draft-ietf-oauth-v2-12.txt
>
> A New=20 Internet-Draft is available from the on-line Internet-Drafts=20 directories.
> This draft is a work item of the Open Authentica= tion=20 Protocol Working Group
> of the IETF.
>
>
> &= nbsp;=20     Title           : The OAuth 2.= 0=20 Authorization Protocol
>       Author(s)  = =20     : E. Hammer-Lahav, et al.
>      = =20 Filename        : draft-ietf-oauth-v2-12.txt
&= gt;=20       Pages           : 46>=20       Date            := =20 2011-01-20
>
> This specification describes the OAuth 2.0= =20 authorization protocol.
>
> A URL for this Internet-Draft= =20 is:
> http://www.ietf.org/internet-drafts/dra= ft-ietf-oauth-v2-12.txt
>
>=20 Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/=
>
>=20 Below is the data which will enable a MIME compliant mail reader
&= gt;=20 implementation to automatically retrieve the ASCII version of the=20 Internet-
>=20 Draft.
__________________________________________= _____
OAuth=20 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth


_______________________________________________
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org/mailman/listinfo/oauth
--_000_0E96A74B7DFCF844A9BE2A0BBE2C425F058DBA1DCBUSNAVSXCHMBSB_-- From eran@hueniverse.com Wed Mar 2 15:25:59 2011 Return-Path: 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 7089E3A6907 for ; Wed, 2 Mar 2011 15:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ujYToZvSBuQ9 for ; Wed, 2 Mar 2011 15:25:51 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EB8E43A68B5 for ; Wed, 2 Mar 2011 15:25:50 -0800 (PST) Received: (qmail 27062 invoked from network); 2 Mar 2011 23:26:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Mar 2011 23:26:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Mar 2011 16:26:49 -0700 From: Eran Hammer-Lahav To: Craig Heath , "oauth@ietf.org" Date: Wed, 2 Mar 2011 16:26:42 -0700 Thread-Topic: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secret? Thread-Index: AcvZAYG4U5dLvKGJQXyOocum691xEQAFn/swAAEZosYABQzQ0A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3F4B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: 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_90C41DD21FB7C64BB94121FBBC2E7234464F0C3F4BP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secret? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:25:59 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3F4BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It limits the ability to exchange the token in cases where the client has n= o private secret, or if the client has multiple instances using the same cr= edentials (providing an isolation between them). You need to make your own = security analysis of the protocol and your needs. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= raig Heath Sent: Wednesday, March 02, 2011 12:57 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared S= ecret? Thanks for the quick response! Can I ask a more specific question: What's= the security purpose of the Temporary Credentials shared secret? If an im= plementation were to, say, always use an empty string, would it make any di= fference to the security of the protocol? - Craig. -----Original Message----- From: Eran Hammer-Lahav Sent: 02-03-2011, 8:27 pm To: Craig Heath; oauth@ietf.org Subject: RE: RFC5849 - Purpose of Temporary Credentials Shared Secret? Because it uses the same method of making authenticated requests as everyth= ing else. It's just a result of pushing everything through a single functio= n. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= raig Heath Sent: Wednesday, March 02, 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secre= t? Hello! Can some kind soul help me understand the purpose of the shared sec= ret part of the Temporary Credentials in RFC5849? - The client authenticates using the Cient Credentials, and gets the Tempor= ary Credentials. - The Resource Owner gives their authorization. - The Temporary Credentials are then used in the Token Credentials Request. The part that's puzzling me is the RFC says the client authenticates using = *both* the Client Credentials and the Token Credentials in the Token Creden= tials Request. I could understand one or the other, but why both? (and inc= identally, how can it provide both?) Clearly the Token Credentials identif= ier is needed, as it is part of the Token Credentials Request; it's only th= e shared secret I'm wondering about (the "oauth_token_secret" part of the r= eponse to the Temporary Credentials Request). My best guess so far is that it is intended to allow for the case when the = Client Credentials are not secret, but in that case why use the Client Cred= entials at all in the Token Credential Request? Thanks for any light shed on this! - Craig Heath. --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3F4BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It limits the ability to exchange the token in cases where th= e client has no private secret, or if the client has multiple instances usi= ng the same credentials (providing an isolation between them). You need to = make your own security analysis of the protocol and your needs.<= /span>

 

EHL

&nbs= p;

=  

From: oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Craig = Heath
Sent: Wednesday, March 02, 2011 12:57 PM
To: oaut= h@ietf.org
Subject: Re: [OAUTH-WG] RFC5849 - Purpose of Temporary= Credentials Shared Secret?

 

Thanks for the quick response!  Can I ask a more s=
pecific question:  What's the security purpose of the Temporary Creden=
tials shared secret?  If an implementation were to, say, always use an=
 empty string, would it make any difference to the security of the protocol=
?
 
- Craig.
-----Origina= l Message-----
From: Eran Hammer-Lahav
Sent:&=
nbsp; 02-03-2011, 8:27  pm
To: Craig Heath; oauth@ietf.=
org
Subject: RE: RFC5849 - Purpose of Temporary Credentials =
Shared Secret?
 
Because it uses the same method =
of making authenticated requests as everything else. It’s just a resu=
lt of pushing everything through a single function.
 
EHL<=
/p>
 
From: oauth-bounces@ietf.org=
 [mailto:oauth-bounces@ietf.org] On Behalf Of Craig Heath
Sent=
: Wednesday, March 02, 2011 10:05 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared =
Secret?
 
Hello!  Can some kind =
soul help me understand the purpose of the shared secret part of the Tempor=
ary Credentials in RFC5849?
 
- The client authenticates using the Cient Credentials, and gets t=
he Temporary Credentials.
- The Resource Owner gives their authorization.
- The Temporary Credentials a=
re then used in the Token Credentials Request.
 
The part that's puzzling me is the RFC says the c=
lient authenticates using *both* the Client Credentials and the Token Crede=
ntials in the Token Credentials Request.  I could understand one or th=
e other, but why both? (and incidentally, how can it provide both?)  C=
learly the Token Credentials identifier is needed, as it is part of the Tok=
en Credentials Request; it's only the shared secret I'm wondering about (th=
e "oauth_token_secret" part of the reponse to the Temporary Crede=
ntials Request).
 
My b=
est guess so far is that it is intended to allow for the case when the Clie=
nt Credentials are not secret, but in that case why use the Client Credenti=
als at all in the Token Credential Request?
 
Thanks for any light shed on this! 
 
=

- Craig Heath.
= --_000_90C41DD21FB7C64BB94121FBBC2E7234464F0C3F4BP3PW5EX1MB01E_-- From James.H.Manger@team.telstra.com Wed Mar 2 19:34:36 2011 Return-Path: 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 342E13A692F for ; Wed, 2 Mar 2011 19:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 HA1THrCBU3Bh for ; Wed, 2 Mar 2011 19:34:25 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id E98CA3A6938 for ; Wed, 2 Mar 2011 19:34:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,256,1296997200"; d="scan'208,217";a="28397924" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 03 Mar 2011 14:35:28 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6273"; a="20450764" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 03 Mar 2011 14:35:27 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 3 Mar 2011 14:35:27 +1100 From: "Manger, James H" To: OAuth Mailing List Date: Thu, 3 Mar 2011 14:35:25 +1100 Thread-Topic: Comments on draft-ietf-oauth-v2-bearer-03 Thread-Index: AcvZVAhzw0GRBeXeR+WutxG9byCctA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1127F5DFA5F@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1127F5DFA5FWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] Comments on draft-ietf-oauth-v2-bearer-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 03:34:36 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1127F5DFA5FWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on the bearer token spec: 1. There is a whole lot of text about OAuth2 get-a-token parts that isn't n= ecessary in the bearer token spec. A bit of context can be useful to a reader, but in this case it brings too = much of the complexity of the get-a-token flows into what should be a quite= simple spec. It is not as though it can replace reading OAuth2 core. 1a. Change the title from "The OAuth 2.0 Protocol: Bearer Tokens" to "The BEARER HTTP authentication scheme", or "Using Bearer Tokens in HTTP requests". 2. The abstract should say this is a mechanism for HTTP requests. My sugges= tion: "This specification describes how to include a bearer token conveying aut= horization information in an HTTP request. It also describes how to recogni= ze a bearer token delivered by an OAuth 2.0 delegation flow." 3. We shouldn't "treat" an access token as a bearer token. A particular tok= en either "is" a bearer token, or not (in which case "treating" it as a bea= rer token is wrong). Perhaps change: "treating an OAuth access token as a bearer token" to "when an OAuth access token is a bearer token". 4. Drop most of the "Introduction" and all of the "Overview". These are all= about OAuth2 core and aren't necessary for understanding how to use a bear= er token in an HTTP request. Here is my suggestion: "Introduction "A bearer token is the simplest mechanism for a client to convey its author= ity when sending a request to a server. A server accepting a bearer token a= ssumes the authority it represents applies to whom ever presented it. That = is, there is no additional authentication of the client. Consequently, it i= s crucial that a bearer token is never exposed to any party that might misu= se it. Using bearer tokens that only represents a limited amount of authori= ty, in a specific context, for a short amount of time can reduce the risks = of using bearer tokens. "This document specifies the "BEARER" HTTP authentication scheme for convey= ing a bearer token in an HTTP request header. It also specifies two alterna= tives for situations where it is infeasible for clients to modify HTTP head= ers: a URI query parameter; and a parameter in the body of a POST that uses= the application/x-www-form-urlencoded media type. "For example: GET /resource HTTP/1.1 Host: example.com Authorization: BEARER vF9dft4qmTG_fdf-qwAS "One possible source of dynamically issued bearer tokens is an OAuth 2.0 fl= ow for user delegation or credential exchange as specified in [OAUTH2]. Sec= tion X of this document describes how a bearer token is represented in an O= Auth 2.0 token response." 5. Section 2 "Authenticated Requests" starts with "clients make authenticat= ed token requests using...". It sounds like the client is requesting a toke= n, as opposed to using it. The term "authenticated token" confuses me a bit= . Perhaps this section could start with: "Clients make requests with a bearer token using...". Section 2.1 similarly talks about "authenticated token requests". 6. The multiple "MAY support" statements about the different methods in sec= tion 2 "Authenticated Requests" awkwardly overlap: MAY support additional m= ethods [other than Authorization header]; MAY attempt to use POST body; MAY= support these alternatives (POST body and URI query param). How about: "Sections 2.1, 2.2 and 2.3 defines how a bearer token can be carried in an = HTTP header, a POST body, and a URI respectively. A server MUST support the= HTTP header approach, MAY support the POST body approach, and MAY support = the URI approach." 7. The ABNF for the Authorization header doesn't comply with = the ABNF in draft-ietf-httpbis-p7-auth-12. HTTPbis has relaxed the ABNF fro= m its original spec in RFC2617 to accommodate schemes that use a base64 blo= b, instead of comma-separated name=3Dvalue pairs, but it doesn't allow a mi= x of both forms. Acceptably choices for this spec are (from my most preferr= ed to least): 1) use "BEARER a=3D"; 2) use "BEARER " with no = extensions possible; 3) get a change to HTTPbis. 8. The allowed characters in is crazy. Using , = but not within quotes is not a good sign?! Token issuers don't need 93 allowed chars, just allow the 66 web-safe ones = and make it simpler for everyone. 9. Don't say oauth_token SHOULD be the last parameter. This "SHOULD" has no= useful purpose for clients or servers. All it can do is: add more code to = clients to make it the last param (as opposed to treating it like any param= , perhaps held in a Map/dictionary/associative-arrray); encourage servers t= o make dangerous checks, such as looking for the last occurrence of "&oauth= _token=3D" instead of properly parsing the string. 10. Instead of concentrating on when a "WWW-Authenticate: Bearer" response = header MUST be returned, we should focus what it means when it is present i= n a response. Servers can return it when they need that meaning. This would= makes it clearer that it can be included with, say, a 200 OK response to i= ndicate that more would be available if a bearer token had been included. 11. The "WWW-Authenticate: Bearer" response header would be a good place fo= r the server to indicate whether or not it supports the URI & POST-body opt= ional methods for conveying a bearer token. Perhaps a supports=3D"body quer= y" parameter? 12. A section explaining how a client can recognizes when a OAuth 2.0 token= response contains a bearer token is needed. It would simply says that the = token_type parameter SHALL have the value "bearer" when the token is intend= ed to be used with the methods defined in this spec. 13. "Message Authentication Code (MAC)" is a better term than "keyed messag= e digest" when describing how a token can be protected. Keyed message diges= ts are only a subset of MACs, which can also be constructed from block ciph= ers for instance. 13. The threat mitigation (3.2) text about passing-by-reference is not quit= e right. Suggestion: "Alternatively, a bearer token can be a reference to authorization inform= ation, rather than encoding the information directly. Such references MUST = be infeasible for an attacker to guess, for instance by being randomly chos= en 128-bit values (22 base64url characters). Using a reference may require = an extra interaction between a server and the token issuer to resolve the r= eference to the authorization information." 14. Drop "with OAuth" from the first recommendation in 3.3. It is true for = any use of the BEARER scheme. "This is the primary security consideration when using bearer tokens with = OAuth..." 15. "Don't pass bearer tokens in page URLs" is a rather strange recommendat= ion given the spec defines a way to do just this. The recommendation goes o= n to say "pass browser tokens in message bodies", but elsewhere we recommen= d using the Authorization header in preference to the body. Plus I guess "b= rowser token" should be "bearer token". Perhaps this recommendation is not about a client making requests to a reso= urce server, but a client caching items in a user's browser for whom it is = acting. If this is the case, the advice should be moved out of this spec an= d into OAuth 2.0 core. 16. "Don't store bearer tokens in cookies" has a MUST NOT "as cookies are g= enerally sent in the clear", which seems harsh given that a server can use = HTTPS to set a cookie and include a "secure" attribute so it is only return= ed over HTTPS. How about just telling servers to do these two things? 17. "Issue short-lived bearer tokens" mentions "the User-Agent" flow, but I= think that has changed names. Perhaps rephrase it generically: "Only short= -lived bearer tokens should be issued to clients that run within a web brow= ser". -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E1127F5DFA5FWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments on the bearer token spec:

 

1. There is a whole lot of text about OAuth2 get-a-t= oken parts that isn’t necessary in the bearer token spec.<= /p>

A bit of context can be useful to a reader, but in t= his case it brings too much of the complexity of the get-a-token flows into= what should be a quite simple spec. It is not as though it can replace rea= ding OAuth2 core.

 

1a. Change the title from “The OAuth 2.0 Proto= col: Bearer Tokens” to

 “The BEARER HTTP authentication scheme&#= 8221;, or

“Using Bearer Tokens in HTTP requests”.<= o:p>

 

2. The abstract should say this is a mechanism for H= TTP requests. My suggestion:

  “This specification describes how to in= clude a bearer token conveying authorization information in an HTTP request= . It also describes how to recognize a bearer token delivered by an OAuth 2= .0 delegation flow.”

 

3. We shouldn’t “treat” an access = token as a bearer token. A particular token either “is” a beare= r token, or not (in which case “treating” it as a bearer token = is wrong). Perhaps change:

“treating an OAuth access token as a bearer to= ken” to

“when an OAuth access token is a bearer token&= #8221;.

 

4. Drop most of the “Introduction” and a= ll of the “Overview”. These are all about OAuth2 core and aren&= #8217;t necessary for understanding how to use a bearer token in an HTTP re= quest. Here is my suggestion:

“Introduction

 

“A bearer token i= s the simplest mechanism for a client to convey its authority when sending = a request to a server. A server accepting a bearer token assumes the author= ity it represents applies to whom ever presented it. That is, there is no additional authentication of the client. Conseque= ntly, it is crucial that a bearer token is never exposed to any party that = might misuse it. Using bearer tokens that only represents a limited amount = of authority, in a specific context, for a short amount of time can reduce the risks of using bearer tokens.

 

“This document sp= ecifies the “BEARER” HTTP authentication scheme for conveying a= bearer token in an HTTP request header. It also specifies two alternatives= for situations where it is infeasible for clients to modify HTTP headers: a URI query parameter; and a parameter in the body of= a POST that uses the application/x-www-form-urlencoded media type.

 

“For example:

  GET /resource HT= TP/1.1

  Host: example.co= m

  Authorization: B= EARER vF9dft4qmTG_fdf-qwAS

 

“One possible sou= rce of dynamically issued bearer tokens is an OAuth 2.0 flow for user deleg= ation or credential exchange as specified in [OAUTH2]. Section X of this do= cument describes how a bearer token is represented in an OAuth 2.0 token response.”

 

5. Section 2 “Authenticated Requests” st= arts with “clients make authenticated token requests using…R= 21;. It sounds like the client is requesting a token, as opposed to using i= t. The term “authenticated token” confuses me a bit. Perhaps th= is section could start with:

  “Clients make requests with a bear= er token using…”.

Section 2.1 similarly talks about “authenticat= ed token requests”.

 

6. The multiple “MAY support” statements= about the different methods in section 2 “Authenticated RequestsR= 21; awkwardly overlap: MAY support additional methods [other than Authoriza= tion header]; MAY attempt to use POST body; MAY support these alternatives (POST body and URI query param).

How about:

“Sections 2.1, 2.2 and 2.3 defines how a beare= r token can be carried in an HTTP header, a POST body, and a URI respective= ly. A server MUST support the HTTP header approach, MAY support the POST bo= dy approach, and MAY support the URI approach.”

 

7. The ABNF for the Authorization header <credent= ials> doesn’t comply with the ABNF in draft-ietf-httpbis-p7-auth-1= 2. HTTPbis has relaxed the ABNF from its original spec in RFC2617 to accomm= odate schemes that use a base64 blob, instead of comma-separated name=3Dvalue pairs, but it doesn’t allow a mix of= both forms. Acceptably choices for this spec are (from my most preferred t= o least): 1) use “BEARER a=3D<token>”; 2) use “BEAR= ER <token>” with no extensions possible; 3) get a change to HTT= Pbis.

 

8. The allowed characters in <access-token> is= crazy. Using <quoted-char>, but not within quotes is not a good sign= ?!

Token issuers don’t need 93 allowed chars, jus= t allow the 66 web-safe ones and make it simpler for everyone.

 

9. Don’t say oauth_token SHOULD be the last pa= rameter. This “SHOULD” has no useful purpose for clients or ser= vers. All it can do is: add more code to clients to make it the last param = (as opposed to treating it like any param, perhaps held in a Map/dictionary/associative-arrray); encourage servers to make dangero= us checks, such as looking for the last occurrence of “&oauth_tok= en=3D” instead of properly parsing the string.

 

10. Instead of concentrating on when a “WWW-Au= thenticate: Bearer” response header MUST be returned, we should focus= what it means when it is present in a response. Servers can return it when= they need that meaning. This would makes it clearer that it can be included with, say, a 200 OK response to indicate that more= would be available if a bearer token had been included.

 

11. The “WWW-Authenticate: Bearer” respo= nse header would be a good place for the server to indicate whether or not = it supports the URI & POST-body optional methods for conveying a bearer= token. Perhaps a supports=3D”body query” parameter?=

 

12. A section explaining how a client can recognizes= when a OAuth 2.0 token response contains a bearer token is needed. It woul= d simply says that the token_type parameter SHALL have the value “bea= rer” when the token is intended to be used with the methods defined in this spec.

 

13. “Message Authentication Code (MAC)” = is a better term than “keyed message digest” when describing ho= w a token can be protected. Keyed message digests are only a subset of MACs= , which can also be constructed from block ciphers for instance.=

 

13. The threat mitigation (3.2) text about passing-b= y-reference is not quite right. Suggestion:

  “Alternatively, a bearer token can be a= reference to authorization information, rather than encoding the informati= on directly. Such references MUST be infeasible for an attacker to guess, f= or instance by being randomly chosen 128-bit values (22 base64url characters). Using a reference may require an extra i= nteraction between a server and the token issuer to resolve the reference t= o the authorization information.”

 

14. Drop “with OAuth” from the first rec= ommendation in 3.3. It is true for any use of the BEARER scheme.=

 “This is the primary security considerat= ion when using bearer tokens with OAuth…”

 

15. “Don’t pass bearer tokens in page UR= Ls” is a rather strange recommendation given the spec defines a way t= o do just this. The recommendation goes on to say “pass browser token= s in message bodies”, but elsewhere we recommend using the Authorization header in preference to the body. Plus I guess “browse= r token” should be “bearer token”.

Perhaps this recommendation is not about a client ma= king requests to a resource server, but a client caching items in a user= 217;s browser for whom it is acting. If this is the case, the advice should= be moved out of this spec and into OAuth 2.0 core.

 

16. “Don’t store bearer tokens in cookie= s” has a MUST NOT “as cookies are generally sent in the clear&#= 8221;, which seems harsh given that a server can use HTTPS to set a cookie = and include a “secure” attribute so it is only returned over HT= TPS. How about just telling servers to do these two things?

 

17. “Issue short-lived bearer tokens” me= ntions “the User-Agent” flow, but I think that has changed name= s. Perhaps rephrase it generically: “Only short-lived bearer tokens s= hould be issued to clients that run within a web browser”.=

 

--

James Manger

 

--_000_255B9BB34FB7D647A506DC292726F6E1127F5DFA5FWSMSG3153Vsrv_-- From craig.heath@wacapps.net Thu Mar 3 01:04:36 2011 Return-Path: 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 4FA243A6882 for ; Thu, 3 Mar 2011 01:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 Naz9CGRTcybV for ; Thu, 3 Mar 2011 01:04:30 -0800 (PST) Received: from out02.themessagecenter.com (out02.themessagecenter.com [208.113.96.229]) by core3.amsl.com (Postfix) with ESMTP id E37573A699C for ; Thu, 3 Mar 2011 01:04:30 -0800 (PST) Received: from [192.168.66.109] by out02.themessagecenter.com with ESMTP (Tumbleweed Email Firewall SMTP Relay); Thu, 03 Mar 2011 00:53:29 -0800 X-Server-Uuid: 385D78BC-A8BE-4780-80CD-A503E34C32DD Received: from EX-CH-002-SFO.shared.themessagecenter.com (192.168.66.93) by EX-CH-004-SFO.shared.themessagecenter.com (192.168.66.110) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 3 Mar 2011 01:05:11 -0800 Received: from ex-be-016-sfo.shared.themessagecenter.com ( [192.168.66.102]) by EX-CH-002-SFO.shared.themessagecenter.com ( [64.151.95.180]) with mapi; Thu, 3 Mar 2011 01:05:11 -0800 From: "Craig Heath" To: "oauth@ietf.org" Date: Thu, 3 Mar 2011 01:06:18 -0800 Thread-Topic: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secret? Thread-Index: AcvZAYG4U5dLvKGJQXyOocum691xEQAFn/swAAEZosYABQzQ0AAUXp0A Message-ID: <4EDB411A4D566C45BE3AB6E0152BFAF92761AC1D1C@EX-BE-016-SFO.shared.themessagecenter.com> References: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3F4B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C3F4B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 617188833PS15555354-01-01 Content-Type: multipart/alternative; boundary=_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1D1CEXBE016SFOsha_ Subject: Re: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secret? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 09:04:36 -0000 --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1D1CEXBE016SFOsha_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable "... if the client has multiple instances ..." Aha, the penny drops! Thank you :-) - Craig. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: 02 March 2011 23:27 To: Craig Heath; oauth@ietf.org Subject: RE: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared S= ecret? It limits the ability to exchange the token in cases where the client has n= o private secret, or if the client has multiple instances using the same cr= edentials (providing an isolation between them). You need to make your own = security analysis of the protocol and your needs. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= raig Heath Sent: Wednesday, March 02, 2011 12:57 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared S= ecret? Thanks for the quick response! Can I ask a more specific question: What's= the security purpose of the Temporary Credentials shared secret? If an im= plementation were to, say, always use an empty string, would it make any di= fference to the security of the protocol? - Craig. -----Original Message----- From: Eran Hammer-Lahav Sent: 02-03-2011, 8:27 pm To: Craig Heath; oauth@ietf.org Subject: RE: RFC5849 - Purpose of Temporary Credentials Shared Secret? Because it uses the same method of making authenticated requests as everyth= ing else. It's just a result of pushing everything through a single functio= n. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= raig Heath Sent: Wednesday, March 02, 2011 10:05 AM To: oauth@ietf.org Subject: [OAUTH-WG] RFC5849 - Purpose of Temporary Credentials Shared Secre= t? Hello! Can some kind soul help me understand the purpose of the shared sec= ret part of the Temporary Credentials in RFC5849? - The client authenticates using the Cient Credentials, and gets the Tempor= ary Credentials. - The Resource Owner gives their authorization. - The Temporary Credentials are then used in the Token Credentials Request. The part that's puzzling me is the RFC says the client authenticates using = *both* the Client Credentials and the Token Credentials in the Token Creden= tials Request. I could understand one or the other, but why both? (and inc= identally, how can it provide both?) Clearly the Token Credentials identif= ier is needed, as it is part of the Token Credentials Request; it's only th= e shared secret I'm wondering about (the "oauth_token_secret" part of the r= eponse to the Temporary Credentials Request). My best guess so far is that it is intended to allow for the case when the = Client Credentials are not secret, but in that case why use the Client Cred= entials at all in the Token Credential Request? Thanks for any light shed on this! - Craig Heath. --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1D1CEXBE016SFOsha_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

"… if the client has multiple instances …"

=

 =

Aha, the penny drops!  Thank you :-)

 =

= - Craig.

 

From: Eran Hammer-La= hav [mailto:eran@hueniverse.com]
Sent: 02 March 2011 23:27
To: Craig Heath; oauth@ietf.org
Subject: RE: [OAUTH-WG] RFC5= 849 - Purpose of Temporary Credentials Shared Secret?

=

 

= It limits the ability to exchang= e the token in cases where the client has no private secret, or if the clie= nt has multiple instances using the same credentials (providing an isolatio= n between them). You need to make your own security analysis of the protoco= l and your needs.

 

EHL

 

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Craig Heath
Sent: Wednesday, March 02, = 2011 12:57 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG= ] RFC5849 - Purpose of Temporary Credentials Shared Secret?

 = 

Thanks for the quick response!  Can I ask a more speci=
fic question:  What's the security purpose of the Temporary Credential=
s shared secret?  If an implementation were to, say, always use an emp=
ty string, would it make any difference to the security of the protocol?
 
- Craig.<=
/o:p>
-----Original Message-----
From: Eran Hammer-Lahav
Sent:  02-03-20=
11, 8:27  pm
To: Craig Heath; oauth@ietf.o=
rg
Subject: RE: RFC5849 - Purpose of Temporary =
Credentials Shared Secret?
 

Because it uses the same method of making authenticated requests as eve= rything else. It’s just a result of pushing everything through a sing= le function.

 

EHL

 

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Craig Heath
Sent: Wednesday, March 02, 2011 10:05 AM
= To: oauth@ietf.org
Subject: [OAUTH-WG] RFC5849 - Purpose of T= emporary Credentials Shared Secret?

 

Hello!  Can some kind soul help me understand the purpose of t= he shared secret part of the Temporary Credentials in RFC5849?

 

- The clie= nt authenticates using the Cient Credentials, and gets the Temporary Creden= tials.

- The Resource Owner gives their = authorization.

- The Temporary Credentia= ls are then used in the Token Credentials Request.

 

The part that's puzz= ling me is the RFC says the client authenticates using *both* the Client Cr= edentials and the Token Credentials in the Token Credentials Request. = I could understand one or the other, but why both? (and incidentally, how = can it provide both?)  Clearly the Token Credentials identifier is nee= ded, as it is part of the Token Credentials Request; it's only the shared s= ecret I'm wondering about (the "oauth_token_secret" part of the r= eponse to the Temporary Credentials Request).

 

My best guess so far is tha= t it is intended to allow for the case when the Client Credentials are not = secret, but in that case why use the Client Credentials at all in the Token= Credential Request?

 

Thanks for any light shed on this!

 

- Craig Heath.=

= --_000_4EDB411A4D566C45BE3AB6E0152BFAF92761AC1D1CEXBE016SFOsha_-- From pflam@cs.stanford.edu Thu Mar 3 01:51:19 2011 Return-Path: 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 0DF7E3A687F for ; Thu, 3 Mar 2011 01:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.256 X-Spam-Level: X-Spam-Status: No, score=-5.256 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_42=0.6, 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 Jmjv0kjnWmJD for ; Thu, 3 Mar 2011 01:51:16 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 87AB13A6827 for ; Thu, 3 Mar 2011 01:51:16 -0800 (PST) Received: from secllab.stanford.edu ([171.64.65.88] helo=css-macbook-pro-9.local) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Pv5Cn-0002q3-6F; Thu, 03 Mar 2011 01:52:22 -0800 Message-ID: <4D6F64D0.3040608@cs.stanford.edu> Date: Thu, 03 Mar 2011 01:52:16 -0800 From: pflam@cs.stanford.edu User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0-OracleInternal Thunderbird/3.1.8 MIME-Version: 1.0 To: "Lu, Hui-Lan (Huilan)" Content-Type: multipart/alternative; boundary="------------030409060802030006010107" X-Scan-Signature: 5d4d7bb02bad719eb6b7853edc1469aa Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] validate authorization code in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 09:51:19 -0000 This is a multi-part message in MIME format. --------------030409060802030006010107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Huilan, If you are referring to the 'state' parameter (or some other way such as a session cookie that the client uses to track the state of the request), there are a few limitations: a) it is an optional feature as far as the spec is concerned, b) it is not sufficient to prevent a DDoS attack. See the discussion below regarding "3. CSRF defense/the 'state' parameter don't completely address this problem." Regards, Eric On Wed, Mar 2, 2011 at 3:23 PM, Lu, Hui-Lan (Huilan)wrote: I agree with Tosten. Ahealthy client is not expected to issue an access token request unconditionally when receiving an authorization code at its redirect_uri. The client should do so only if it is in the right state with a correlatable authorization request pending. Best regards, Huilan LU CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. ------------------------------------------------------------------------ *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org ]*On Behalf Of*Torsten Lodderstedt *Sent:*Monday, February 07, 2011 3:56 PM *To:*Eric *Cc:*oauth@ietf.org *Subject:*Re: [OAUTH-WG] validate authorization code in draft 12 Hi Eric, I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful attack. For a typical web application this would require the attacker to login to this app and kick off the authorization process. This requires more than one additional http call. What do you think? regards, Torsten. Am 21.01.2011 09:30, schrieb Eric: > Eran, and others, > > A few of us had some discussions on the authorization code > flow, as depicted in Fig. 3 of the current (12th) draft. We > think that it is probably worthwhile to suggest in the > specification that an OAuth implementation SHOULD provide a > way for the client to validate the authorization code before > sending it to the Authorization Server (AS). From what we > have heard, this has been done in some of the current OAuth > deployments. There are other people who do not think this is > such a big security risk, although so far no one has objected > that there is some risk here. > > The issue is that according to the current draft, someone > whoowns a botnet can locate the redirect URIs of clients that > listen on HTTP, and access them with random authorization > codes, and cause HTTPS connections to be made on the > Authorization Server (AS). There are a few things that the > attacker can achieve with this OAuth flow that he cannot > easily achieve otherwise : > > 1. Cost magnification: the attacker incurs the cost of an HTTP > connection and causes an HTTPS connection to be made on the > AS; and he can co-ordinate the timing of such HTTPS > connections across multiple clients relatively easily, if > these clients blindly connect to the AS without first > validating the authorization codes received. > > Although the attacker could achieve something similar, say by > including an iframe pointing to the HTTPS URL of the AS in an > HTTP web page and lure web users to visit that page, timing > attacks using such a scheme is (say for the purpose of DDoS) > more difficult . > > 2. Connection laundering: if the AS realizes it is flooded by > HTTPS connections with illegitimate codes, it collects no > useful information about the attacker, since the clients act > as relays. > > 3. CSRF defense/the 'state' parameter don't completely address > this problem. With such a defense, the attacker might need to > incur an additional HTTP request to obtain a valid CSRF code/ > state parameter. This does cut down the effectiveness of the > attack by a factor of 2, which is good. However, if the > HTTPS/HTTP cost ratio is higher than 2 (the cost factor is > estimated to be around 3.5x > athttp://www.semicomplete.com/blog/geekery/ssl-latency.html > ), > the attacker still achieves a cost magnification. > > Our proposal is that the OAuth specification suggests that an > OAuth (Authorization Server) implementation SHOULD provide a > way for the client to validate the authorization code before > sending it to the Authorization Server (AS). The specifics of > how to validate the authorization code may not need to be part > of the core specification. We sketch a design below for > consideration for future implementation. It might be > reasonable to assume that OAuth implementations provide some > API for the client to call to validate and send the > authorization code to the AS. There are two possible schemes > for implementation: a) if the client and the AS already share > a symmetric secret, an HMAC key can be created from the shared > secret, and the authorization code will be HMAC'ed and > standard techniques can be employed in the client-side API > implementation to detect replay and forgery attempts on the > code; b) an alternative is for the AS to sign the code using > the private key from its SSL certificate, and for the client > API to validate the signature using the public key. > > > > On Thu, Jan 20, 2011 at 4:56 PM, Eran > Hammer-Lahav > wrote: > > Draft -12 is finally out. > > This is almost a complete rewrite of the entire document, > with the primary goal of moving it back to a similar > structure used in -05. I have been thinking about this for > a few months and finally came up with a structure that > combines the two approaches. > > The draft includes some major cleanups, significantly > simpler language, reduces repeated prose, and tried to > keep prose to the introduction and normative language in > the rest of the specification. I took out sections that > broke the flow, and did my best to give this a linear > narrative that is easy to follow. > > The draft includes the following normative changes: > > o Clarified 'token_type' as case insensitive. > o Authorization endpoint requires TLS when an access > token is issued. > o Removed client assertion credentials, mandatory HTTP > Basic authentication support for client credentials, > WWW-Authenticate header, and the OAuth2 authentication scheme. > o Changed implicit grant (aka user-agent flow) error > response from query to fragment. > o Removed the 'redirect_uri_mismatch' error code since > in such a case, the authorization server must not send the > error back to the client. > o Defined access token type registry. > > I would like to spend the coming week receiving and > applying feedback before requesting a WGLC for everything > but the security considerations section (missing) 2/1. > > EHL > > > > > -----Original Message----- > > From:oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org > ] On Behalf > > OfInternet-Drafts@ietf.org > > Sent: Thursday, January 20, 2011 4:45 PM > > To:i-d-announce@ietf.org > > Cc:oauth@ietf.org > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the Open Authentication > Protocol Working Group > > of the IETF. > > > > > > Title : The OAuth 2.0 Authorization Protocol > > Author(s) : E. Hammer-Lahav, et al. > > Filename : draft-ietf-oauth-v2-12.txt > > Pages : 46 > > Date : 2011-01-20 > > > > This specification describes the OAuth 2.0 authorization > protocol. > > > > A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > > > > Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > > > Below is the data which will enable a MIME compliant mail > reader > > implementation to automatically retrieve the ASCII > version of the Internet- > > Draft. > _______________________________________________ > 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 --------------030409060802030006010107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Huilan,

If you are referring to the 'state' parameter (or some other way such as a session cookie that the client uses to track the state of the request), there are a few limitations:
a) it is an optional feature as far as the spec is concerned,
b) it is not sufficient to prevent a DDoS attack. See the discussion below regarding "3. CSRF defense/the 'state' parameter don't completely address this problem."

Regards,
Eric

On Wed, Mar 2, 2011 at 3:23 PM, Lu, Hui-Lan (Huilan) <huilan.lu@alcatel-lucent.com> wrote:
I agree with Tosten. A healthy client is not expected to issue an access token request unconditionally when receiving an authorization code at its redirect_uri. The client should do so only if it is in the right state with a correlatable authorization request pending.   
 
Best regards,

Huilan LU


CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Monday, February 07, 2011 3:56 PM
To: Eric
Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] validate authorization code in draft 12

Hi Eric,

I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful attack. For a typical web application this would require the attacker to login to this app and kick off the authorization process. This requires more than one additional http call.

What do you think?

regards,
Torsten. 

Am 21.01.2011 09:30, schrieb Eric:
Eran, and others,

A few of us had some discussions on the authorization code flow, as depicted in Fig. 3 of the current (12th) draft. We think that it is probably worthwhile to suggest in the specification that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). From what we have heard, this has been done in some of the current OAuth deployments. There are other people who do not think this is such a big security risk, although so far no one has objected that there is some risk here.

The issue is that according to the current draft, someone who      owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise : 

1. Cost magnification: the attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the AS; and he can co-ordinate the timing of such HTTPS connections across multiple clients relatively easily, if these clients blindly connect to the AS without first validating the authorization codes received.

Although the attacker could achieve something similar, say by including an iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web  users to visit that page, timing attacks using such a scheme is (say for the purpose of DDoS) more difficult .

2. Connection laundering: if the AS realizes it is flooded by HTTPS connections with illegitimate codes, it collects no useful information about the attacker, since the clients act as relays.  

3. CSRF defense/the 'state' parameter don't completely address this problem. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/ state parameter. This does cut down the effectiveness of the attack by a factor of 2, which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.html), the attacker still achieves a cost magnification.

Our proposal is that the OAuth specification suggests that an OAuth (Authorization Server) implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). The specifics of how to validate the authorization code may not need to be part of the core specification. We sketch a design below for consideration for future implementation. It might be reasonable to assume that OAuth implementations provide some API for the client to call to validate and send the authorization code to the AS. There are two possible schemes for implementation: a) if the client and the AS already share a symmetric secret, an HMAC key can be created from the shared secret, and the authorization code will be HMAC'ed and standard techniques can be employed in the client-side API implementation to detect replay and forgery attempts on the code; b) an alternative is for the AS to sign the code using the private key from its SSL certificate, and for the client API to validate the signature using the public key.

 

On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Draft -12 is finally out.

This is almost a complete rewrite of the entire document, with the primary goal of moving it back to a similar structure used in -05. I have been thinking about this for a few months and finally came up with a structure that combines the two approaches.

The draft includes some major cleanups, significantly simpler language, reduces repeated prose, and tried to keep prose to the introduction and normative language in the rest of the specification. I took out sections that broke the flow, and did my best to give this a linear narrative that is easy to follow.

The draft includes the following normative changes:

  o  Clarified 'token_type' as case insensitive.
  o  Authorization endpoint requires TLS when an access token is issued.
  o  Removed client assertion credentials, mandatory HTTP Basic authentication support for client credentials, WWW-Authenticate header, and the OAuth2 authentication scheme.
  o  Changed implicit grant (aka user-agent flow) error response from query to fragment.
  o  Removed the 'redirect_uri_mismatch' error code since in such a case, the authorization server must not send the error back to the client.
  o  Defined access token type registry.

I would like to spend the coming week receiving and applying feedback before requesting a WGLC for everything but the security considerations section (missing) 2/1.

EHL



> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Internet-Drafts@ietf.org
> Sent: Thursday, January 20, 2011 4:45 PM
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Open Authentication Protocol Working Group
> of the IETF.
>
>
>       Title           : The OAuth 2.0 Authorization Protocol
>       Author(s)       : E. Hammer-Lahav, et al.
>       Filename        : draft-ietf-oauth-v2-12.txt
>       Pages           : 46
>       Date            : 2011-01-20
>
> This specification describes the OAuth 2.0 authorization protocol.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the Internet-
> Draft.
_______________________________________________
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


--------------030409060802030006010107-- From huilan.lu@alcatel-lucent.com Thu Mar 3 20:07:12 2011 Return-Path: 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 D50293A6926 for ; Thu, 3 Mar 2011 20:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 Bgyww8EF7nQi for ; Thu, 3 Mar 2011 20:07:11 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 092143A6920 for ; Thu, 3 Mar 2011 20:07:10 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p2448DVg012947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2011 22:08:14 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2448Dvb030141 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 22:08:13 -0600 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 3 Mar 2011 22:08:12 -0600 From: "Lu, Hui-Lan (Huilan)" To: "'pflam@cs.stanford.edu'" Date: Thu, 3 Mar 2011 22:08:12 -0600 Thread-Topic: [OAUTH-WG] validate authorization code in draft 12 Thread-Index: AcvZiLRexNLE1cfeRumrbZrV7rgsdwAlfkmw Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058DBA1DCD@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4D6F64D0.3040608@cs.stanford.edu> In-Reply-To: <4D6F64D0.3040608@cs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] validate authorization code in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 04:07:12 -0000 Eric, =20 The state parameter helps simplify but is not necessary for state managemen= t. I would note that the client has total control of what information the p= arameter captures. So it could be devised to carry an index to the state ta= ble, a sequence number (for replay protection), and a signature (for authen= tication). The CSRF case is interesting. Let's consider the following scenario: 1. Rob (the resource owner) is tricked to send a service request to the cli= ent. 2. Upon receiving the request, the client redirects Rob to the authorizatio= n server as well as changes its internal state to pending authorization by = Bob. (Note that the client may try to authenticate Rob first. Rob could bec= ome suspicous of the authentication request. But let's assume that he plays= along.) 3. Upon receiving the authorization request, the authorization server authe= nticates Rob and asks for his approval of the client's request. 4. Upon seeing the approval dialogue box, Rob should become alarmed, becaus= e he didn't take the action in step 1 knowingly. He rejects the request.=20 5. The authorization server redirects the rejection response back to the cl= ient. 6. The client sends an apology to Rob explaining why it can not carry out h= is service request. So Rob needs to be totally clueless for the CSRF attacks to work. What is t= he likelihood for that to happen? Have I missed something? =20 Best regards, Huilan=20 ________________________________ From: pflam@cs.stanford.edu [mailto:pflam@cs.stanford.edu]=20 Sent: Thursday, March 03, 2011 4:52 AM To: Lu, Hui-Lan (Huilan) Cc: Torsten Lodderstedt; Eric; oauth@ietf.org Subject: Re: [OAUTH-WG] validate authorization code in draft 12 =09 =09 Hi Huilan, =09 If you are referring to the 'state' parameter (or some other way such as a= session cookie that the client uses to track the state of the request), th= ere are a few limitations: a) it is an optional feature as far as the spec is concerned, b) it is not sufficient to prevent a DDoS attack. See the discussion below= regarding "3. CSRF defense/the 'state' parameter don't completely address = this problem." =09 Regards, Eric =09 =09 On Wed, Mar 2, 2011 at 3:23 PM, Lu, Hui-Lan (Huilan) wrote: =09 I agree with Tosten. A healthy client is not expected to issue an access = token request unconditionally when receiving an authorization code at its r= edirect_uri. The client should do so only if it is in the right state with = a correlatable authorization request pending. =20 =20 Best regards, =09 Huilan LU =09 =09 CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain co= nfidential and proprietary information of Alcatel-Lucent and/or its affilia= ted entities. Access by the intended recipient only is authorized. Any liab= ility arising from any party acting, or refraining from acting, on any info= rmation contained in this e-mail is hereby excluded. If you are not the int= ended recipient, please notify the sender immediately, destroy the original= transmission and its attachments and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in an= y medium. Copyright in this e-mail and any attachments belongs to Alcatel-L= ucent and/or its affiliated entities. =09 =20 ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Torsten Lodderstedt Sent: Monday, February 07, 2011 3:56 PM To: Eric Cc: oauth@ietf.org=20 Subject: Re: [OAUTH-WG] validate authorization code in draft 12 =09 =09 =09 Hi Eric, =09 I'm trying to understand the attack you described. I would expect any cl= ient to mark its web sessions if it triggers an authorization process. If s= o, the attacker would need to forge a valid client session in the right sta= te (authz process in progress) in order to place a sucessful attack. For a = typical web application this would require the attacker to login to this ap= p and kick off the authorization process. This requires more than one addit= ional http call. =09 What do you think? =09 regards, Torsten.=20 =09 Am 21.01.2011 09:30, schrieb Eric:=20 Eran, and others, =09 A few of us had some discussions on the authorization code flow, as dep= icted in Fig. 3 of the current (12th) draft. We think that it is probably w= orthwhile to suggest in the specification that an OAuth implementation SHOU= LD provide a way for the client to validate the authorization code before s= ending it to the Authorization Server (AS). From what we have heard, this = has been done in some of the current OAuth deployments. There are other peo= ple who do not think this is such a big security risk, although so far no o= ne has objected that there is some risk here. =09 The issue is that according to the current draft, someone who owns= a botnet can locate the redirect URIs of clients that listen on HTTP, and = access them with random authorization codes, and cause HTTPS connections to= be made on the Authorization Server (AS). There are a few things that the = attacker can achieve with this OAuth flow that he cannot easily achieve oth= erwise :=20 =09 1. Cost magnification: the attacker incurs the cost of an HTTP connecti= on and causes an HTTPS connection to be made on the AS; and he can co-ordin= ate the timing of such HTTPS connections across multiple clients relatively= easily, if these clients blindly connect to the AS without first validatin= g the authorization codes received. =09 Although the attacker could achieve something similar, say by including= an iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure= web users to visit that page, timing attacks using such a scheme is (say = for the purpose of DDoS) more difficult . =09 2. Connection laundering: if the AS realizes it is flooded by HTTPS con= nections with illegitimate codes, it collects no useful information about t= he attacker, since the clients act as relays. =20 =09 3. CSRF defense/the 'state' parameter don't completely address this pro= blem. With such a defense, the attacker might need to incur an additional H= TTP request to obtain a valid CSRF code/ state parameter. This does cut dow= n the effectiveness of the attack by a factor of 2, which is good. However,= if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimate= d to be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency= .html ), the at= tacker still achieves a cost magnification. =09 Our proposal is that the OAuth specification suggests that an OAuth (Au= thorization Server) implementation SHOULD provide a way for the client to v= alidate the authorization code before sending it to the Authorization Serv= er (AS). The specifics of how to validate the authorization code may not ne= ed to be part of the core specification. We sketch a design below for consi= deration for future implementation. It might be reasonable to assume that O= Auth implementations provide some API for the client to call to validate an= d send the authorization code to the AS. There are two possible schemes for= implementation: a) if the client and the AS already share a symmetric secr= et, an HMAC key can be created from the shared secret, and the authorizatio= n code will be HMAC'ed and standard techniques can be employed in the clien= t-side API implementation to detect replay and forgery attempts on the code= ; b) an alternative is for the AS to sign the code using the private key fr= om its SSL certificate, and for the client API to validate the signature us= ing the public key. =09 =20 =09 =09 On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav wrote: =09 Draft -12 is finally out. =09 This is almost a complete rewrite of the entire document, with the pri= mary goal of moving it back to a similar structure used in -05. I have been= thinking about this for a few months and finally came up with a structure = that combines the two approaches. =09 The draft includes some major cleanups, significantly simpler language= , reduces repeated prose, and tried to keep prose to the introduction and n= ormative language in the rest of the specification. I took out sections tha= t broke the flow, and did my best to give this a linear narrative that is e= asy to follow. =09 The draft includes the following normative changes: =09 o Clarified 'token_type' as case insensitive. o Authorization endpoint requires TLS when an access token is issue= d. o Removed client assertion credentials, mandatory HTTP Basic authen= tication support for client credentials, WWW-Authenticate header, and the O= Auth2 authentication scheme. o Changed implicit grant (aka user-agent flow) error response from = query to fragment. o Removed the 'redirect_uri_mismatch' error code since in such a ca= se, the authorization server must not send the error back to the client. o Defined access token type registry. =09 I would like to spend the coming week receiving and applying feedback = before requesting a WGLC for everything but the security considerations sec= tion (missing) 2/1. =09 EHL =09 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf > Of Internet-Drafts@ietf.org > Sent: Thursday, January 20, 2011 4:45 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. > This draft is a work item of the Open Authentication Protocol Workin= g Group > of the IETF. > > > Title : The OAuth 2.0 Authorization Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-12.txt > Pages : 46 > Date : 2011-01-20 > > This specification describes the OAuth 2.0 authorization protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt =20 > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ =20 > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the In= ternet- > Draft. =09 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =09 =09 =09 =09 =09 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 =09 =09 =09 =09 From pflam@cs.stanford.edu Thu Mar 3 22:21:49 2011 Return-Path: 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 6DE603A6975 for ; Thu, 3 Mar 2011 22:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 1K2s1QBfIugi for ; Thu, 3 Mar 2011 22:21:42 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 25F5E3A6969 for ; Thu, 3 Mar 2011 22:21:41 -0800 (PST) Received: from secllab.stanford.edu ([171.64.65.88] helo=css-macbook-pro-9.local) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1PvOPY-0004Zm-Cr; Thu, 03 Mar 2011 22:22:50 -0800 Message-ID: <4D708537.8030000@cs.stanford.edu> Date: Thu, 03 Mar 2011 22:22:47 -0800 From: pflam@cs.stanford.edu User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0-OracleInternal Thunderbird/3.1.8 MIME-Version: 1.0 To: "Lu, Hui-Lan (Huilan)" Content-Type: multipart/alternative; boundary="------------000405060205020802070201" X-Scan-Signature: e64d3a2317fc6887b6826b0462acec30 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] validate authorization code in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 06:21:49 -0000 This is a multi-part message in MIME format. --------------000405060205020802070201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Huilan, The vulnerability being mentioned here is not that an attacker impersonates Rob. Please refer to the original discussion below: "The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise : ..." The point 3. about the state parameter/CSRF defense is that they can have the beneficial effect of making the above attack more difficult, but does not prevent it. Best regards, Eric On Thu, Mar 3, 2011 at 8:08 PM, Lu, Hui-Lan (Huilan)wrote: Eric, The state parameter helps simplify but is not necessary for state management. I would note that the client has total control of what information the parameter captures. So it could be devised to carry an index to the state table, a sequence number (for replay protection), and a signature (for authentication). The CSRF case is interesting. Let's consider the following scenario: 1. Rob (the resource owner) is tricked to send a service request to the client. 2. Upon receiving the request, the client redirects Rob to the authorization server as well as changes its internal state to pending authorization by Bob. (Note that the client may try to authenticate Rob first. Rob could become suspicous of the authentication request. But let's assume that he plays along.) 3. Upon receiving the authorization request, the authorization server authenticates Rob and asks for his approval of the client's request. 4. Upon seeing the approval dialogue box, Rob should become alarmed, because he didn't take the action in step 1 knowingly. He rejects the request. 5. The authorization server redirects the rejection response back to the client. 6. The client sends an apology to Rob explaining why it can not carry out his service request. So Rob needs to be totally clueless for the CSRF attacks to work. What is the likelihood for that to happen? Have I missed something? Best regards, Huilan ________________________________ From:pflam@cs.stanford.edu [mailto:pflam@cs.stanford.edu ] Sent: Thursday, March 03, 2011 4:52 AM To: Lu, Hui-Lan (Huilan) Cc: Torsten Lodderstedt; Eric;oauth@ietf.org Subject: Re: [OAUTH-WG] validate authorization code in draft 12 Hi Huilan, If you are referring to the 'state' parameter (or some other way such as a session cookie that the client uses to track the state of the request), there are a few limitations: a) it is an optional feature as far as the spec is concerned, b) it is not sufficient to prevent a DDoS attack. See the discussion below regarding "3. CSRF defense/the 'state' parameter don't completely address this problem." Regards, Eric On Wed, Mar 2, 2011 at 3:23 PM, Lu, Hui-Lan (Huilan) @alcatel-lucent.com > > wrote: I agree with Tosten. A healthy client is not expected to issue an access token request unconditionally when receiving an authorization code at its redirect_uri. The client should do so only if it is in the right state with a correlatable authorization request pending. Best regards, Huilan LU CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. ________________________________ From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org ] On Behalf Of Torsten Lodderstedt Sent: Monday, February 07, 2011 3:56 PM To: Eric Cc:oauth@ietf.org Subject: Re: [OAUTH-WG] validate authorization code in draft 12 Hi Eric, I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful attack. For a typical web application this would require the attacker to login to this app and kick off the authorization process. This requires more than one additional http call. What do you think? regards, Torsten. Am 21.01.2011 09:30, schrieb Eric: Eran, and others, A few of us had some discussions on the authorization code flow, as depicted in Fig. 3 of the current (12th) draft. We think that it is probably worthwhile to suggest in the specification that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the Authorization Server (AS). From what we have heard, this has been done in some of the current OAuth deployments. There are other people who do not think this is such a big security risk, although so far no one has objected that there is some risk here. The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise : 1. Cost magnification: the attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the AS; and he can co-ordinate the timing of such HTTPS connections across multiple clients relatively easily, if these clients blindly connect to the AS without first validating the authorization codes received. Although the attacker could achieve something similar, say by including an iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web users to visit that page, timing attacks using such a scheme is (say for the purpose of DDoS) more difficult . 2. Connection laundering: if the AS realizes it is flooded by HTTPS connections with illegitimate codes, it collects no useful information about the attacker, since the clients act as relays. 3. CSRF defense/the 'state' parameter don't completely address this problem. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/ state parameter. This does cut down the effectiveness of the attack by a factor of 2, which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x athttp://www.semicomplete.com/blog/geekery/ssl-latency.html > ), the attacker still achieves a cost magnification. Our proposal is that the OAuth specification suggests that an OAuth (Authorization Server) implementation SHOULD provide a way for the client to validate the authorization code before sending it to the Authorization Server (AS). The specifics of how to validate the authorization code may not need to be part of the core specification. We sketch a design below for consideration for future implementation. It might be reasonable to assume that OAuth implementations provide some API for the client to call to validate and send the authorization code to the AS. There are two possible schemes for implementation: a) if the client and the AS already share a symmetric secret, an HMAC key can be created from the shared secret, and the authorization code will be HMAC'ed and standard techniques can be employed in the client-side API implementation to detect replay and forgery attempts on the code; b) an alternative is for the AS to sign the code using the private key from its SSL certificate, and for the client API to validate the signature using the public key. On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav > > wrote: Draft -12 is finally out. This is almost a complete rewrite of the entire document, with the primary goal of moving it back to a similar structure used in -05. I have been thinking about this for a few months and finally came up with a structure that combines the two approaches. The draft includes some major cleanups, significantly simpler language, reduces repeated prose, and tried to keep prose to the introduction and normative language in the rest of the specification. I took out sections that broke the flow, and did my best to give this a linear narrative that is easy to follow. The draft includes the following normative changes: o Clarified 'token_type' as case insensitive. o Authorization endpoint requires TLS when an access token is issued. o Removed client assertion credentials, mandatory HTTP Basic authentication support for client credentials, WWW-Authenticate header, and the OAuth2 authentication scheme. o Changed implicit grant (aka user-agent flow) error response from query to fragment. o Removed the 'redirect_uri_mismatch' error code since in such a case, the authorization server must not send the error back to the client. o Defined access token type registry. I would like to spend the coming week receiving and applying feedback before requesting a WGLC for everything but the security considerations section (missing) 2/1. EHL > -----Original Message----- > From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org ] On Behalf > OfInternet-Drafts@ietf.org > Sent: Thursday, January 20, 2011 4:45 PM > To:i-d-announce@ietf.org > Cc:oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Authentication Protocol Working Group > of the IETF. > > > Title : The OAuth 2.0 Authorization Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-12.txt > Pages : 46 > Date : 2011-01-20 > > This specification describes the OAuth 2.0 authorization protocol. > > A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > > Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Internet- > Draft. _______________________________________________ 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 > --------------000405060205020802070201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Huilan,

The vulnerability being mentioned here is not that an attacker impersonates Rob. Please refer to the original discussion below:
"The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise : ..."

The point 3. about the state parameter/CSRF defense is that they can have the beneficial effect of making the above attack more difficult, but does not prevent it.

Best regards,
Eric


On Thu, Mar 3, 2011 at 8:08 PM, Lu, Hui-Lan (Huilan) <huilan.lu@alcatel-lucent.com> wrote:
Eric,

The state parameter helps simplify but is not necessary for state management. I would note that the client has total control of what information the parameter captures. So it could be devised to carry an index to the state table, a sequence number (for replay protection), and a signature (for authentication).


The CSRF case is interesting. Let's consider the following scenario:

1. Rob (the resource owner) is tricked to send a service request to the client.

2. Upon receiving the request, the client redirects Rob to the authorization server as well as changes its internal state to pending authorization by Bob. (Note that the client may try to authenticate Rob first. Rob could become suspicous of the authentication request. But let's assume that he plays along.)

3. Upon receiving the authorization request, the authorization server authenticates Rob and asks for his approval of the client's request.

4. Upon seeing the approval dialogue box, Rob should become alarmed, because he didn't take the action in step 1 knowingly. He rejects the request.

5. The authorization server redirects the rejection response back to the client.

6. The client sends an apology to Rob explaining why it can not carry out his service request.


So Rob needs to be totally clueless for the CSRF attacks to work. What is the likelihood for that to happen? Have I missed something?


Best regards,
Huilan

________________________________

       From: pflam@cs.stanford.edu [mailto:pflam@cs.stanford.edu]
       Sent: Thursday, March 03, 2011 4:52 AM
       To: Lu, Hui-Lan (Huilan)
       Cc: Torsten Lodderstedt; Eric; oauth@ietf.org
       Subject: Re: [OAUTH-WG] validate authorization code in draft 12


       Hi Huilan,

       If you are referring to the 'state' parameter (or some other way such as a session cookie that the client uses to track the state of the request), there are a few limitations:
       a) it is an optional feature as far as the spec is concerned,
       b) it is not sufficient to prevent a DDoS attack. See the discussion below regarding "3. CSRF defense/the 'state' parameter don't completely address this problem."

       Regards,
       Eric


       On Wed, Mar 2, 2011 at 3:23 PM, Lu, Hui-Lan (Huilan) <huilan.lu@alcatel-lucent.com> <mailto:huilan.lu@alcatel-lucent.com>  wrote:


               I agree with Tosten. A healthy client is not expected to issue an access token request unconditionally when receiving an authorization code at its redirect_uri. The client should do so only if it is in the right state with a correlatable authorization request pending.

               Best regards,

               Huilan LU


               CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.




________________________________

                       From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
                       Sent: Monday, February 07, 2011 3:56 PM
                       To: Eric
                       Cc: oauth@ietf.org

                       Subject: Re: [OAUTH-WG] validate authorization code in draft 12



                       Hi Eric,

                       I'm trying to understand the attack you described. I would expect any client to mark its web sessions if it triggers an authorization process. If so, the attacker would need to forge a valid client session in the right state (authz process in progress) in order to place a sucessful attack. For a typical web application this would require the attacker to login to this app and kick off the authorization process. This requires more than one additional http call.

                       What do you think?

                       regards,
                       Torsten.

                       Am 21.01.2011 09:30, schrieb Eric:

                               Eran, and others,

                               A few of us had some discussions on the authorization code flow, as depicted in Fig. 3 of the current (12th) draft. We think that it is probably worthwhile to suggest in the specification that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). From what we have heard, this has been done in some of the current OAuth deployments. There are other people who do not think this is such a big security risk, although so far no one has objected that there is some risk here.

                               The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise :

                               1. Cost magnification: the attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the AS; and he can co-ordinate the timing of such HTTPS connections across multiple clients relatively easily, if these clients blindly connect to the AS without first validating the authorization codes received.

                               Although the attacker could achieve something similar, say by including an iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web  users to visit that page, timing attacks using such a scheme is (say for the purpose of DDoS) more difficult .

                               2. Connection laundering: if the AS realizes it is flooded by HTTPS connections with illegitimate codes, it collects no useful information about the attacker, since the clients act as relays.

                               3. CSRF defense/the 'state' parameter don't completely address this problem. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/ state parameter. This does cut down the effectiveness of the attack by a factor of 2, which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.html <http://www.semicomplete.com/blog/geekery/ssl-latency.html> ), the attacker still achieves a cost magnification.

                               Our proposal is that the OAuth specification suggests that an OAuth (Authorization Server) implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). The specifics of how to validate the authorization code may not need to be part of the core specification. We sketch a design below for consideration for future implementation. It might be reasonable to assume that OAuth implementations provide some API for the client to call to validate and send the authorization code to the AS. There are two possible schemes for implementation: a) if the client and the AS already share a symmetric secret, an HMAC key can be created from the shared secret, and the authorization code will be HMAC'ed and standard techniques can be employed in the client-side API implementation to detect replay and forgery attempts on the code; b) an alternative is for the AS to sign the code using the private key from its SSL certificate, and for the client API to validate the signature using the public key.




                               On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> <mailto:eran@hueniverse.com>  wrote:


                                       Draft -12 is finally out.

                                       This is almost a complete rewrite of the entire document, with the primary goal of moving it back to a similar structure used in -05. I have been thinking about this for a few months and finally came up with a structure that combines the two approaches.

                                       The draft includes some major cleanups, significantly simpler language, reduces repeated prose, and tried to keep prose to the introduction and normative language in the rest of the specification. I took out sections that broke the flow, and did my best to give this a linear narrative that is easy to follow.

                                       The draft includes the following normative changes:

                                         o  Clarified 'token_type' as case insensitive.
                                         o  Authorization endpoint requires TLS when an access token is issued.
                                         o  Removed client assertion credentials, mandatory HTTP Basic authentication support for client credentials, WWW-Authenticate header, and the OAuth2 authentication scheme.
                                         o  Changed implicit grant (aka user-agent flow) error response from query to fragment.
                                         o  Removed the 'redirect_uri_mismatch' error code since in such a case, the authorization server must not send the error back to the client.
                                         o  Defined access token type registry.

                                       I would like to spend the coming week receiving and applying feedback before requesting a WGLC for everything but the security considerations section (missing) 2/1.

                                       EHL




                                       > -----Original Message-----
                                       > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
                                       > Of Internet-Drafts@ietf.org
                                       > Sent: Thursday, January 20, 2011 4:45 PM
                                       > To: i-d-announce@ietf.org
                                       > Cc: oauth@ietf.org
                                       > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
                                       >
                                       > A New Internet-Draft is available from the on-line Internet-Drafts directories.
                                       > This draft is a work item of the Open Authentication Protocol Working Group
                                       > of the IETF.
                                       >
                                       >
                                       >       Title           : The OAuth 2.0 Authorization Protocol
                                       >       Author(s)       : E. Hammer-Lahav, et al.
                                       >       Filename        : draft-ietf-oauth-v2-12.txt
                                       >       Pages           : 46
                                       >       Date            : 2011-01-20
                                       >
                                       > This specification describes the OAuth 2.0 authorization protocol.
                                       >
                                       > A URL for this Internet-Draft is:
                                       > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt <http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt>
                                       >
                                       > Internet-Drafts are also available by anonymous FTP at:
                                       > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
                                       >
                                       > Below is the data which will enable a MIME compliant mail reader
                                       > implementation to automatically retrieve the ASCII version of the Internet-
                                       > Draft.

                                       _______________________________________________
                                       OAuth mailing list
                                       OAuth@ietf.org
                                       https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>






                               _______________________________________________
                               OAuth mailing list
                               OAuth@ietf.org
                               https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>








--------------000405060205020802070201-- From huilan.lu@alcatel-lucent.com Fri Mar 4 10:35:02 2011 Return-Path: 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 DF9103A6A14 for ; Fri, 4 Mar 2011 10:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 jVkZVwRbEZXB for ; Fri, 4 Mar 2011 10:35:00 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 08F513A6A07 for ; Fri, 4 Mar 2011 10:34:59 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p24Ia37H019993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2011 12:36:03 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p24Ia1cq016020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Mar 2011 12:36:02 -0600 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 4 Mar 2011 12:36:02 -0600 From: "Lu, Hui-Lan (Huilan)" To: "'pflam@cs.stanford.edu'" Date: Fri, 4 Mar 2011 12:36:01 -0600 Thread-Topic: [OAUTH-WG] validate authorization code in draft 12 Thread-Index: AcvaNJj4q55qvYHRTGmLM0dSZP+/VQAXDmfw Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058DBA1DCE@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4D708537.8030000@cs.stanford.edu> In-Reply-To: <4D708537.8030000@cs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] validate authorization code in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 18:35:02 -0000 Eric, =20 I'm confused. I didn't talk about an attacker impersonating Rob. At any rat= e, inasmuch as we are back to square one, I would maintain that receipt of = an authorization code by the client alone is not sufficient for causing it = to issue an access token request to the authorization server. The client ha= s to have the right context and be in the right state for that to happen. I= should say that it is valid to address DDoS attacks. At issue is only the = plausibility of the chain reaction suggested. =20 =20 Best regards, Huilan=20 ________________________________ From: pflam@cs.stanford.edu [mailto:pflam@cs.stanford.edu]=20 Sent: Friday, March 04, 2011 1:23 AM To: Lu, Hui-Lan (Huilan) Cc: pflam@cs.stanford.edu; Torsten Lodderstedt; oauth@ietf.org Subject: Re: [OAUTH-WG] validate authorization code in draft 12 =09 =09 Hi Huilan, =09 The vulnerability being mentioned here is not that an attacker impersonate= s Rob. Please refer to the original discussion below: "The issue is that according to the current draft, someone who owns a botn= et can locate the redirect URIs of clients that listen on HTTP, and access = them with random authorization codes, and cause HTTPS connections to be mad= e on the Authorization Server (AS). There are a few things that the attacke= r can achieve with this OAuth flow that he cannot easily achieve otherwise = : ..."=20 =09 The point 3. about the state parameter/CSRF defense is that they can have = the beneficial effect of making the above attack more difficult, but does n= ot prevent it.=20 =09 Best regards, Eric From eran@hueniverse.com Fri Mar 4 12:12:28 2011 Return-Path: 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 830043A6845 for ; Fri, 4 Mar 2011 12:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] 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 MI02dR98spSy for ; Fri, 4 Mar 2011 12:12:27 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A4B4E3A6844 for ; Fri, 4 Mar 2011 12:12:27 -0800 (PST) Received: (qmail 7907 invoked from network); 4 Mar 2011 20:13:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Mar 2011 20:13:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Mar 2011 13:13:33 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , OAuth WG Date: Fri, 4 Mar 2011 13:13:22 -0700 Thread-Topic: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt Thread-Index: AcvYq/VRfyCqRH/sTkq26EXkRBWSkwB/KDJQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F0C441A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 20:12:28 -0000 Ready to go. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Tuesday, March 01, 2011 11:32 PM > To: OAuth WG > Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt >=20 > This is a Last Call for comments on >=20 > http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt >=20 > Please have your comments in no later than March 16. >=20 > Do remember to send a note in if you have read the document and have no > other comments other than "its ready to go" - we need those as much as we > need "I found a problem". >=20 > Thanks! > Hannes & Blaine >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Fri Mar 4 12:18:22 2011 Return-Path: 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 4689C3A6845 for ; Fri, 4 Mar 2011 12:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7a-UEgeCsmXW for ; Fri, 4 Mar 2011 12:18:21 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with ESMTP id 1413B3A6830 for ; Fri, 4 Mar 2011 12:18:20 -0800 (PST) Received: from source ([209.85.161.49]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTXFJUqd++qqgtOe/aPbDPy/FrdES1LXh@postini.com; Fri, 04 Mar 2011 12:19:31 PST Received: by fxm16 with SMTP id 16so3482004fxm.22 for ; Fri, 04 Mar 2011 12:19:27 -0800 (PST) Received: by 10.223.143.86 with SMTP id t22mr1343333fau.78.1299269967691; Fri, 04 Mar 2011 12:19:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.113.83 with HTTP; Fri, 4 Mar 2011 12:18:55 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234464F0C441A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234464F0C441A@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Fri, 4 Mar 2011 13:18:55 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 20:18:22 -0000 The title of the message might have been misleading ('cause it had 12 in it) but http://www.ietf.org/mail-archive/web/oauth/current/msg05551.html applies to -13 and, while it's minor, I'd like to see it addressed in future drafts. Thanks. On Fri, Mar 4, 2011 at 1:13 PM, Eran Hammer-Lahav wrote: > Ready to go. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Hannes Tschofenig >> Sent: Tuesday, March 01, 2011 11:32 PM >> To: OAuth WG >> Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt >> >> This is a Last Call for comments on >> >> http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt >> >> Please have your comments in no later than March 16. >> >> Do remember to send a note in if you have read the document and have no >> other comments other than "its ready to go" - we need those as much as we >> need "I found a problem". >> >> Thanks! >> Hannes & Blaine >> >> _______________________________________________ >> 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 > From pflam@cs.stanford.edu Fri Mar 4 19:10:05 2011 Return-Path: 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 717DD3A6A0C for ; Fri, 4 Mar 2011 19:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PuD8qC2dCGwE for ; Fri, 4 Mar 2011 19:10:04 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 557523A69FC for ; Fri, 4 Mar 2011 19:10:04 -0800 (PST) Received: from secllab.stanford.edu ([171.64.65.88] helo=css-macbook-pro-9.local) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Pvhtg-0003Ys-DH; Fri, 04 Mar 2011 19:11:13 -0800 Message-ID: <4D71A9CF.5050809@cs.stanford.edu> Date: Fri, 04 Mar 2011 19:11:11 -0800 From: pflam@cs.stanford.edu User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.0-OracleInternal Thunderbird/3.1.8 MIME-Version: 1.0 To: "Lu, Hui-Lan (Huilan)" Content-Type: multipart/alternative; boundary="------------030002010803010007010302" X-Scan-Signature: 702ae50298edc6602ea45f3868e8cc09 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] validate authorization code in draft 12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 03:10:05 -0000 This is a multi-part message in MIME format. --------------030002010803010007010302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Huilan, In the context of the OAuth protocol, can you describe how an innocent user can cause the right context and state to be established, and why a DDoS attacker can't accomplish the same, without making assumption on additional security measures that are not mandated or recommended by the OAuth specification? Best regards, Eric On Fri, Mar 4, 2011 at 10:36 AM, Lu, Hui-Lan (Huilan)wrote: Eric, I'm confused. I didn't talk about an attacker impersonating Rob. At any rate, inasmuch as we are back to square one, I would maintain that receipt of an authorization code by the client alone is not sufficient for causing it to issue an access token request to the authorization server. The client has to have the right context and be in the right state for that to happen. I should say that it is valid to address DDoS attacks. At issue is only the plausibility of the chain reaction suggested. Best regards, Huilan ________________________________ From:pflam@cs.stanford.edu [mailto:pflam@cs.stanford.edu ] Sent: Friday, March 04, 2011 1:23 AM To: Lu, Hui-Lan (Huilan) Cc:pflam@cs.stanford.edu ; Torsten Lodderstedt;oauth@ietf.org Subject: Re: [OAUTH-WG] validate authorization code in draft 12 Hi Huilan, The vulnerability being mentioned here is not that an attacker impersonates Rob. Please refer to the original discussion below: "The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise : ..." The point 3. about the state parameter/CSRF defense is that they can have the beneficial effect of making the above attack more difficult, but does not prevent it. Best regards, Eric --------------030002010803010007010302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Huilan,
 
In the context of the OAuth protocol, can you describe how an innocent user can cause the right context and state to be established, and why a DDoS attacker can't accomplish the same, without making assumption on additional security measures that are not mandated or recommended by the OAuth specification?

Best regards,
Eric



On Fri, Mar 4, 2011 at 10:36 AM, Lu, Hui-Lan (Huilan) <huilan.lu@alcatel-lucent.com> wrote:
Eric,

I'm confused. I didn't talk about an attacker impersonating Rob. At any rate, inasmuch as we are back to square one, I would maintain that receipt of an authorization code by the client alone is not sufficient for causing it to issue an access token request to the authorization server. The client has to have the right context and be in the right state for that to happen. I should say that it is valid to address DDoS attacks. At issue is only the plausibility of the chain reaction suggested.


Best regards,
Huilan

________________________________

       From: pflam@cs.stanford.edu [mailto:pflam@cs.stanford.edu]
       Sent: Friday, March 04, 2011 1:23 AM
       To: Lu, Hui-Lan (Huilan)
       Cc: pflam@cs.stanford.edu; Torsten Lodderstedt; oauth@ietf.org
       Subject: Re: [OAUTH-WG] validate authorization code in draft 12


       Hi Huilan,

       The vulnerability being mentioned here is not that an attacker impersonates Rob. Please refer to the original discussion below:
       "The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise : ..."

       The point 3. about the state parameter/CSRF defense is that they can have the beneficial effect of making the above attack more difficult, but does not prevent it.

       Best regards,
       Eric



--------------030002010803010007010302-- From skylar@kiva.org Fri Mar 4 19:21:36 2011 Return-Path: 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 D44113A6902 for ; Fri, 4 Mar 2011 19:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 143UECBHimGo for ; Fri, 4 Mar 2011 19:21:35 -0800 (PST) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by core3.amsl.com (Postfix) with SMTP id 50E403A68F9 for ; Fri, 4 Mar 2011 19:21:34 -0800 (PST) Received: from source ([74.125.83.172]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKTXGshA49gmKxgW8OT9Ohgi4CBFieIY50@postini.com; Fri, 04 Mar 2011 19:22:45 PST Received: by pve39 with SMTP id 39so430032pve.3 for ; Fri, 04 Mar 2011 19:22:44 -0800 (PST) Received: by 10.142.90.2 with SMTP id n2mr1140134wfb.157.1299295363084; Fri, 04 Mar 2011 19:22:43 -0800 (PST) Received: from [10.0.1.9] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id w11sm145836wfh.18.2011.03.04.19.22.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2011 19:22:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Fri, 4 Mar 2011 19:21:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92D3BF86-64A0-4280-9387-60E5A0966A90@kiva.org> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 03:21:36 -0000 Marius, did you have an alternative to suggest for this? Not that it has to be in the spec, but it would be nice to have a best = practice for this as it's a common case. > On Fri, Jan 28, 2011 at 10:25 AM, Eran Hammer-Lahav wrote: > > -12 3.1.1: > > > > The redirection URI MUST be an absolute URI and MAY include a = query > > component, which MUST be retained by the authorization server when > > adding additional query parameters. > > > > 'oob' is not an absolute URI. >=20 > Good point, I missed the absolute part. Thanks for pointing this out. >=20 > Let me think about it, the URN you suggested is a good start. >=20 > Marius >=20 > From: Marius Scurtescu [mailto:mscurtescu at google.com] > Sent: Friday, January 28, 2011 10:07 AM > To: Eran Hammer-Lahav > Cc: Skylar Woodward; OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension >=20 > On Fri, Jan 28, 2011 at 8:21 AM, Eran Hammer-Lahav > wrote: > > Why not: > > > > urn:ietf:wg:oauth:2.0:oob > > From torsten@lodderstedt.net Sun Mar 6 11:19:26 2011 Return-Path: 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 0D3FC3A684F for ; Sun, 6 Mar 2011 11:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 tCtmRhf88nU0 for ; Sun, 6 Mar 2011 11:19:24 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id A5B5A3A684A for ; Sun, 6 Mar 2011 11:19:23 -0800 (PST) Received: from [87.142.250.245] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PwJVK-0002GN-1k; Sun, 06 Mar 2011 20:20:34 +0100 Message-ID: <4D73DE81.5050103@lodderstedt.net> Date: Sun, 06 Mar 2011 20:20:33 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian Campbell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 19:19:26 -0000 +1 Am 02.03.2011 15:05, schrieb Brian Campbell: > I propose that the "or native applications" text be dropped from the > first paragraph in section 4.2 Implicit Grant [1]. > > There is clearly some disagreement about what is most appropriate for > mobile/native applications and many, including myself, don't feel that > the implicit grant works well to support them (due to the lack of a > refresh token and need to repeat the authorization steps). I > understand that the text in section 4 is non-normative, however, I > feel that the mention of native apps in 4.2 biases thinking in a > particular way (it's already led to one lengthy internal discussion > that I'd rather not have again and again). I believe it'd be more > appropriate for the draft to remain silent on how native apps should > acquire tokens and leave it up to implementations/deployments to > decide (or an extension draft as Marius has proposed). > > The "or native applications" text in is also somewhat inconsistent > with the text in the following sentence that talks about the > authentication of the client being based on the user-agent's > same-origin policy. > > Removing those three words is a small change but one that I feel would > be beneficial on a number of fronts. > > Thanks, > Brian > > > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 > > On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav wrote: >> Feel free to propose alternative preamble for the implicit and authorization code sections, describing the characteristics of what they are good for. It should fit in a single paragraph. Such a proposal would fit right in with last call feedback to -13. >> >> EHL >> >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>> Sent: Wednesday, February 16, 2011 1:39 PM >>> To: Eran Hammer-Lahav >>> Cc: Brian Campbell; OAuth WG >>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>> >>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>> wrote: >>>> The reason why we don't return a refresh token in the implicit grant is >>> exactly because there is no client authentication... >>> >>> Not sure that's the main reason. AFAIK it is because the response is sent >>> through the user-agent and it could leak. >>> >>> >>>> These are all well-balanced flows with specific security properties. If you >>> need something else, even if it is just a tweak, it must be considered a >>> different flow. That doesn't mean you need to register a new grant type, just >>> that you are dealing with different implementation details unique to your >>> server. >>> >>> The Authorization Code flow, with no client secret, is perfectly fine for Native >>> Apps IMO. >>> >>> Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mkent@proofpoint.com Sun Mar 6 13:17:39 2011 Return-Path: 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 103B728C0CE for ; Sun, 6 Mar 2011 13:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] 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 FLeS1UkpyIYu for ; Sun, 6 Mar 2011 13:17:33 -0800 (PST) Received: from mx2.proofpoint.com (mx2.proofpoint.com [208.86.202.10]) by core3.amsl.com (Postfix) with ESMTP id 3498D28B797 for ; Sun, 6 Mar 2011 13:17:32 -0800 (PST) Received: from CUP-POSTAL1.corp.proofpoint.com (cup-sv11.corp.proofpoint.com [10.20.7.111]) by admin1009 (8.14.3/8.14.3) with ESMTP id p26LIiCS015372 for ; Sun, 6 Mar 2011 13:18:44 -0800 Received: from 99.123.4.33 ([99.123.4.33]) by CUP-POSTAL1.corp.proofpoint.com ([10.20.7.22]) via Exchange Front-End Server owa.proofpoint.com ([10.20.7.23]) with Microsoft Exchange Server HTTP-DAV ; Sun, 6 Mar 2011 21:18:44 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Sun, 06 Mar 2011 13:18:43 -0800 From: Mark Kent To: "oauth@ietf.org" Message-ID: Thread-Topic: draft-ietf-oauth-v2-13 comments Thread-Index: AcvcRBIdj4Jn5D8EPUCvBXh/THroSA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3382262323_37138903" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-06_04:2011-03-04, 2011-03-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103060096 Subject: [OAUTH-WG] draft-ietf-oauth-v2-13 comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 21:17:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3382262323_37138903 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable First up, nice work with the latest version =AD it=B9s considerably easier to follow than previous version. Based on a simple attempt to implement a compliant authentication server, I have the following requests for clarification: 1. The error response mechanism for the authorization endpoint depends on the response_type being requested. Assuming that the client and redirect UR= I are valid, the endpoint might place the error information in the query string (for repsonse_type =B3code=B2, section 4.1.2.1) or in the fragment (for response type =B3token=B2, section 4.2.2.1). I believe it is ambiguous what should be done if the response_type is missing, or invalid. Clarification would be appreciated. 2. The error response for the authorization endpoint is directed to include the state, if a state were supplied in the request (sections 4.1.2.1, 4.2.2.1). Assuming that including multiple state parameters in the request makes the request malformed, how should the server include state in the error response if the request contains multiple state parameters? I could see justifications for a number of options (not including the state, including all the state parameters, including just the first state parameter, etc). Clarification would be appreciated. Note that, if multiple state parameters may be legally included in the request, this same question applies to the grant response, rather than the error response. 3. I believe that section 5.2 is ambiguous as to the error code that should be returned from the token endpoint when the client credentials are valid, when the client is authorized to use the authorization code grant type in general, but when the authorization code supplied is not valid for the client. I could see unauthorized_client being right, but the wording of the section doesn=B9t include the exact case above. Please clarify. 4. I believe that section 5.2 is ambiguous as to the error code that should be returned from the token endpoint when the grant type is =B3password=B2, and the resource owner=B9s credentials are invalid. Section 4.3.3 implies that such a request is =B3invalid=B2, suggesting that invalid_request is the correct response, but section 5.2 could be clearer on this. Please clarify. In addition, I wonder if the authors have given any thought to the applicability of the protocol in a federated authentication domain environment, for example where the authorization endpoint and token endpoints are on different servers that retain a trust relationship with each other. Clearly, in this case, the format of the authorization code is an integration point, much in the same way as the access token is in the currently provided use cases. Whereas a number of access token formats are provided in companion specifications, I see no references for authorization codes. Any thoughts on this would be gratefully received. Mark. --B_3382262323_37138903 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable draft-ietf-oauth-v2-13 comments First up, nice work with the latest version – it’s considerabl= y easier to follow than previous version. Based on a simple attempt to imple= ment a compliant authentication server, I have the following requests for cl= arification:

  1. The error response mechanism for the authorization e= ndpoint depends on the response_type being requested. Assuming that the clie= nt and redirect URI are valid, the endpoint might place the error informatio= n in the query string (for repsonse_type “code”, section 4.1.2.1= ) or in the fragment (for response type “token”, section 4.2.2.1= ). I believe it is ambiguous what should be done if the response_type is mis= sing, or invalid. Clarification would be appreciated.
  2. The error response for the authorization endpoint is dir= ected to include the state, if a state were supplied in the request (section= s 4.1.2.1, 4.2.2.1). Assuming that including multiple state parameters in th= e request makes the request malformed, how should the server include state i= n the error response if the request contains multiple state parameters? I co= uld see justifications for a number of options (not including the state, inc= luding all the state parameters, including just the first state parameter, e= tc). Clarification would be appreciated. Note that, if multiple state parame= ters may be legally included in the request, this same question applies to t= he grant response, rather than the error response.
  3. I believe that section 5.2 is ambiguous as to the error = code that should be returned from the token endpoint when the client credent= ials are valid, when the client is authorized to use the authorization code = grant type in general, but when the authorization code supplied is not valid= for the client. I could see unauthorized_client being right, but the wordin= g of the section doesn’t include the exact case above. Please clarify.
  4. I believe that section 5.2 is ambiguous as to the error = code that should be returned from the token endpoint when the grant type is = “password”, and the resource owner’s credentials are inval= id. Section 4.3.3 implies that such a request is “invalid”, sugg= esting that invalid_request is the correct response, but section 5.2 could b= e clearer on this. Please clarify.

In addition, I wonder if the authors have given any thought to the applicab= ility of the protocol in a federated authentication domain environment, for = example where the authorization endpoint and token endpoints are on differen= t servers that retain a trust relationship with each other. Clearly, in this= case, the format of the authorization code is an integration point, much in= the same way as the access token is in the currently provided use cases. Wh= ereas a number of access token formats are provided in companion specificati= ons, I see no references for authorization codes. Any thoughts on this would= be gratefully received.

Mark. --B_3382262323_37138903-- From dick.hardt@gmail.com Sun Mar 6 14:11:01 2011 Return-Path: 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 40B5228C0CE for ; Sun, 6 Mar 2011 14:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 H4TAqp5W1qSh for ; Sun, 6 Mar 2011 14:10:57 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id F2F783A688B for ; Sun, 6 Mar 2011 14:10:56 -0800 (PST) Received: by yxk30 with SMTP id 30so1768007yxk.31 for ; Sun, 06 Mar 2011 14:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=mUvCp0QRIXpoB+kZjepMueB9y7NooRqrw462vNVPMPc=; b=rBMkQ51rqfWNvOwYIUKegvksX0s3LjQGUhEngaJjF8nYyrwZ+p3B0PIfZSsnN7YtNN RipPrRrCh5OS1/5R+S7R+alv3j/cmihLqo8MCRq3q8GcMuPj8bApo5cEUZ12isI2zOAg bDBCFJxyRo5RTIYJHoLraDVwKOzDbs9A6Vniw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=pF9VAvvc91SKdYS6psl1laBqTMcrUFMC9sJ0kbaJ2xadFFQAWCZZ0R5zFlYA6sNgAO 4y5y7ITQsa+s8Zldv/AKPLgMIzgAgLal9JF1gjZGY3KmrSBUfN04ZIHNMkcn6eUx54dZ Md1O+QZo9OUMxMD+1vq8d6QOCkfjnt2MjxKM0= Received: by 10.150.115.18 with SMTP id n18mr3663007ybc.195.1299449528512; Sun, 06 Mar 2011 14:12:08 -0800 (PST) Received: from [192.168.1.100] (64-46-1-217.dyn.novuscom.net [64.46.1.217]) by mx.google.com with ESMTPS id v35sm1214732yba.16.2011.03.06.14.12.05 (version=SSLv3 cipher=OTHER); Sun, 06 Mar 2011 14:12:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Sun, 6 Mar 2011 14:12:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 22:11:01 -0000 -1 Many sites are using OAuth (or something like it) in native apps now.=20 One of the objectives of having a standard is to bring best practices = and standardization to how to solve a problem rather than "a million = freakin unique snowflakes" where developers have to learn and code each = mechanism to enable authorization to a native app. Brian's suggested = wording may make sense in the context of where OAuth is now -- but it = signals that the WG has been unable to solve what I think many viewed as = an important aspect of the WG. fwiw: I think a number of important constituents have opted out of the = dialogue. An unfortunate situation. On 2011-03-02, at 6:05 AM, Brian Campbell wrote: > I propose that the "or native applications" text be dropped from the > first paragraph in section 4.2 Implicit Grant [1]. >=20 > There is clearly some disagreement about what is most appropriate for > mobile/native applications and many, including myself, don't feel that > the implicit grant works well to support them (due to the lack of a > refresh token and need to repeat the authorization steps). I > understand that the text in section 4 is non-normative, however, I > feel that the mention of native apps in 4.2 biases thinking in a > particular way (it's already led to one lengthy internal discussion > that I'd rather not have again and again). I believe it'd be more > appropriate for the draft to remain silent on how native apps should > acquire tokens and leave it up to implementations/deployments to > decide (or an extension draft as Marius has proposed). >=20 > The "or native applications" text in is also somewhat inconsistent > with the text in the following sentence that talks about the > authentication of the client being based on the user-agent's > same-origin policy. >=20 > Removing those three words is a small change but one that I feel would > be beneficial on a number of fronts. >=20 > Thanks, > Brian >=20 >=20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 >=20 > On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav = wrote: >> Feel free to propose alternative preamble for the implicit and = authorization code sections, describing the characteristics of what they = are good for. It should fit in a single paragraph. Such a proposal would = fit right in with last call feedback to -13. >>=20 >> EHL >>=20 >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>> Sent: Wednesday, February 16, 2011 1:39 PM >>> To: Eran Hammer-Lahav >>> Cc: Brian Campbell; OAuth WG >>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>>=20 >>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>> wrote: >>>> The reason why we don't return a refresh token in the implicit = grant is >>> exactly because there is no client authentication... >>>=20 >>> Not sure that's the main reason. AFAIK it is because the response is = sent >>> through the user-agent and it could leak. >>>=20 >>>=20 >>>> These are all well-balanced flows with specific security = properties. If you >>> need something else, even if it is just a tweak, it must be = considered a >>> different flow. That doesn't mean you need to register a new grant = type, just >>> that you are dealing with different implementation details unique to = your >>> server. >>>=20 >>> The Authorization Code flow, with no client secret, is perfectly = fine for Native >>> Apps IMO. >>>=20 >>> Marius >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon Mar 7 01:59:15 2011 Return-Path: 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 415F63A6916 for ; Mon, 7 Mar 2011 01:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 dcMyBMuT8vC1 for ; Mon, 7 Mar 2011 01:59:14 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 05AAA3A68EC for ; Mon, 7 Mar 2011 01:59:13 -0800 (PST) Received: from [79.253.43.171] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PwXEm-0005A7-L2; Mon, 07 Mar 2011 11:00:24 +0100 Message-ID: <4D74ACB8.3040707@lodderstedt.net> Date: Mon, 07 Mar 2011 11:00:24 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dick Hardt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 09:59:15 -0000 Hi Dick, I agree with you, the OAuth standard should offer clear patterns for native apps. All native apps I'm familiar with use the authorization code, which is because of its support for refresh tokens. But the current text of the spec only suggests to use the implict grant flow to implement native apps whereas previous versions mentioned authz code and password flow as well. So in my opinion, the text is misleading to developers. And that's not only a feeling since I already meet people, which have been misguided :-(. I think at least the misleading words shall be removed. Better would be to come up with a consensus after a discussion in the group. regards, Torsten. Am 06.03.2011 23:12, schrieb Dick Hardt: > -1 > > Many sites are using OAuth (or something like it) in native apps now. > > One of the objectives of having a standard is to bring best practices and standardization to how to solve a problem rather than "a million freakin unique snowflakes" where developers have to learn and code each mechanism to enable authorization to a native app. Brian's suggested wording may make sense in the context of where OAuth is now -- but it signals that the WG has been unable to solve what I think many viewed as an important aspect of the WG. > > fwiw: I think a number of important constituents have opted out of the dialogue. An unfortunate situation. > > On 2011-03-02, at 6:05 AM, Brian Campbell wrote: > >> I propose that the "or native applications" text be dropped from the >> first paragraph in section 4.2 Implicit Grant [1]. >> >> There is clearly some disagreement about what is most appropriate for >> mobile/native applications and many, including myself, don't feel that >> the implicit grant works well to support them (due to the lack of a >> refresh token and need to repeat the authorization steps). I >> understand that the text in section 4 is non-normative, however, I >> feel that the mention of native apps in 4.2 biases thinking in a >> particular way (it's already led to one lengthy internal discussion >> that I'd rather not have again and again). I believe it'd be more >> appropriate for the draft to remain silent on how native apps should >> acquire tokens and leave it up to implementations/deployments to >> decide (or an extension draft as Marius has proposed). >> >> The "or native applications" text in is also somewhat inconsistent >> with the text in the following sentence that talks about the >> authentication of the client being based on the user-agent's >> same-origin policy. >> >> Removing those three words is a small change but one that I feel would >> be beneficial on a number of fronts. >> >> Thanks, >> Brian >> >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 >> >> On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav wrote: >>> Feel free to propose alternative preamble for the implicit and authorization code sections, describing the characteristics of what they are good for. It should fit in a single paragraph. Such a proposal would fit right in with last call feedback to -13. >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>> Sent: Wednesday, February 16, 2011 1:39 PM >>>> To: Eran Hammer-Lahav >>>> Cc: Brian Campbell; OAuth WG >>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>>> >>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>>> wrote: >>>>> The reason why we don't return a refresh token in the implicit grant is >>>> exactly because there is no client authentication... >>>> >>>> Not sure that's the main reason. AFAIK it is because the response is sent >>>> through the user-agent and it could leak. >>>> >>>> >>>>> These are all well-balanced flows with specific security properties. If you >>>> need something else, even if it is just a tweak, it must be considered a >>>> different flow. That doesn't mean you need to register a new grant type, just >>>> that you are dealing with different implementation details unique to your >>>> server. >>>> >>>> The Authorization Code flow, with no client secret, is perfectly fine for Native >>>> Apps IMO. >>>> >>>> Marius >> _______________________________________________ >> 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 From jricher@mitre.org Mon Mar 7 05:55:34 2011 Return-Path: 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 195AE3A696B for ; Mon, 7 Mar 2011 05:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 HBmfkAx11DWw for ; Mon, 7 Mar 2011 05:55:33 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id E77193A6998 for ; Mon, 7 Mar 2011 05:55:32 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1FE0F21B1228; Mon, 7 Mar 2011 08:56:46 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 18AE921B1219; Mon, 7 Mar 2011 08:56:46 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 7 Mar 2011 08:56:45 -0500 From: "Richer, Justin P." To: Torsten Lodderstedt , Dick Hardt Date: Mon, 7 Mar 2011 08:54:26 -0500 Thread-Topic: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) Thread-Index: Acvcrn7U/8pjBuf2RbG6w8ZjZVLl4wAIK08D Message-ID: References: , <4D74ACB8.3040707@lodderstedt.net> In-Reply-To: <4D74ACB8.3040707@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 13:55:34 -0000 Agree with Torsten - having the mention in just that one place doesn't make= sense. It should be removed or replicated throughout, but I think we might= want a paragraph addressing native apps more deeply in the introduction. W= e don't want to give the (incorrect) impression that the implicit flow is t= he only or even preferred flow for native apps. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Torsten = Lodderstedt [torsten@lodderstedt.net] Sent: Monday, March 07, 2011 5:00 AM To: Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 f= eedback deadline) Hi Dick, I agree with you, the OAuth standard should offer clear patterns for native apps. All native apps I'm familiar with use the authorization code, which is because of its support for refresh tokens. But the current text of the spec only suggests to use the implict grant flow to implement native apps whereas previous versions mentioned authz code and password flow as well. So in my opinion, the text is misleading to developers. And that's not only a feeling since I already meet people, which have been misguided :-(. I think at least the misleading words shall be removed. Better would be to come up with a consensus after a discussion in the group. regards, Torsten. Am 06.03.2011 23:12, schrieb Dick Hardt: > -1 > > Many sites are using OAuth (or something like it) in native apps now. > > One of the objectives of having a standard is to bring best practices and= standardization to how to solve a problem rather than "a million freakin u= nique snowflakes" where developers have to learn and code each mechanism to= enable authorization to a native app. Brian's suggested wording may make s= ense in the context of where OAuth is now -- but it signals that the WG has= been unable to solve what I think many viewed as an important aspect of th= e WG. > > fwiw: I think a number of important constituents have opted out of the di= alogue. An unfortunate situation. > > On 2011-03-02, at 6:05 AM, Brian Campbell wrote: > >> I propose that the "or native applications" text be dropped from the >> first paragraph in section 4.2 Implicit Grant [1]. >> >> There is clearly some disagreement about what is most appropriate for >> mobile/native applications and many, including myself, don't feel that >> the implicit grant works well to support them (due to the lack of a >> refresh token and need to repeat the authorization steps). I >> understand that the text in section 4 is non-normative, however, I >> feel that the mention of native apps in 4.2 biases thinking in a >> particular way (it's already led to one lengthy internal discussion >> that I'd rather not have again and again). I believe it'd be more >> appropriate for the draft to remain silent on how native apps should >> acquire tokens and leave it up to implementations/deployments to >> decide (or an extension draft as Marius has proposed). >> >> The "or native applications" text in is also somewhat inconsistent >> with the text in the following sentence that talks about the >> authentication of the client being based on the user-agent's >> same-origin policy. >> >> Removing those three words is a small change but one that I feel would >> be beneficial on a number of fronts. >> >> Thanks, >> Brian >> >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 >> >> On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav = wrote: >>> Feel free to propose alternative preamble for the implicit and authoriz= ation code sections, describing the characteristics of what they are good f= or. It should fit in a single paragraph. Such a proposal would fit right in= with last call feedback to -13. >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>> Sent: Wednesday, February 16, 2011 1:39 PM >>>> To: Eran Hammer-Lahav >>>> Cc: Brian Campbell; OAuth WG >>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>>> >>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>>> wrote: >>>>> The reason why we don't return a refresh token in the implicit grant = is >>>> exactly because there is no client authentication... >>>> >>>> Not sure that's the main reason. AFAIK it is because the response is s= ent >>>> through the user-agent and it could leak. >>>> >>>> >>>>> These are all well-balanced flows with specific security properties. = If you >>>> need something else, even if it is just a tweak, it must be considered= a >>>> different flow. That doesn't mean you need to register a new grant typ= e, just >>>> that you are dealing with different implementation details unique to y= our >>>> server. >>>> >>>> The Authorization Code flow, with no client secret, is perfectly fine = for Native >>>> Apps IMO. >>>> >>>> Marius >> _______________________________________________ >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From huilan.lu@alcatel-lucent.com Mon Mar 7 07:08:14 2011 Return-Path: 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 0CFC23A68F2 for ; Mon, 7 Mar 2011 07:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 ZhETBnjyGqdD for ; Mon, 7 Mar 2011 07:08:12 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id B432C3A692D for ; Mon, 7 Mar 2011 07:08:11 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p27F9N1r018910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Mar 2011 09:09:23 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p27F9M5Y030097 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 7 Mar 2011 09:09:23 -0600 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 7 Mar 2011 09:09:22 -0600 From: "Lu, Hui-Lan (Huilan)" To: "'Richer, Justin P.'" , Torsten Lodderstedt , Dick Hardt Date: Mon, 7 Mar 2011 09:09:21 -0600 Thread-Topic: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) Thread-Index: Acvcrn7U/8pjBuf2RbG6w8ZjZVLl4wAIK08DAAKa1PA= Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058DBA1DCF@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: , <4D74ACB8.3040707@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:08:14 -0000 +1 Best regards, Huilan LU CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential and proprietary information of Alcatel-Lucent and/or its affiliate= d entities. Access by the intended recipient only is authorized. Any liabil= ity arising from any party acting, or refraining from acting, on any inform= ation contained in this e-mail is hereby excluded. If you are not the inten= ded recipient, please notify the sender immediately, destroy the original t= ransmission and its attachments and do not disclose the contents to any oth= er person, use it for any purpose, or store or copy the information in any = medium. Copyright in this e-mail and any attachments belongs to Alcatel-Luc= ent and/or its affiliated entities.=20 =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Richer, Justin P. > Sent: Monday, March 07, 2011 8:54 AM > To: Torsten Lodderstedt; Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] slightly alternative preamble (was:=20 > Re: Draft -12 feedback deadline) >=20 > Agree with Torsten - having the mention in just that one=20 > place doesn't make sense. It should be removed or replicated=20 > throughout, but I think we might want a paragraph addressing=20 > native apps more deeply in the introduction. We don't want to=20 > give the (incorrect) impression that the implicit flow is the=20 > only or even preferred flow for native apps. >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On=20 > Behalf Of Torsten Lodderstedt [torsten@lodderstedt.net] > Sent: Monday, March 07, 2011 5:00 AM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] slightly alternative preamble (was:=20 > Re: Draft -12 feedback deadline) >=20 > Hi Dick, >=20 > I agree with you, the OAuth standard should offer clear=20 > patterns for native apps. >=20 > All native apps I'm familiar with use the authorization code,=20 > which is because of its support for refresh tokens. But the=20 > current text of the spec only suggests to use the implict=20 > grant flow to implement native apps whereas previous versions=20 > mentioned authz code and password flow as well. So in my=20 > opinion, the text is misleading to developers. And that's not=20 > only a feeling since I already meet people, which have been=20 > misguided :-(. >=20 > I think at least the misleading words shall be removed.=20 > Better would be to come up with a consensus after a=20 > discussion in the group. >=20 > regards, > Torsten. >=20 > Am 06.03.2011 23:12, schrieb Dick Hardt: > > -1 > > > > Many sites are using OAuth (or something like it) in native=20 > apps now. > > > > One of the objectives of having a standard is to bring best=20 > practices and standardization to how to solve a problem=20 > rather than "a million freakin unique snowflakes" where=20 > developers have to learn and code each mechanism to enable=20 > authorization to a native app. Brian's suggested wording may=20 > make sense in the context of where OAuth is now -- but it=20 > signals that the WG has been unable to solve what I think=20 > many viewed as an important aspect of the WG. > > > > fwiw: I think a number of important constituents have opted=20 > out of the dialogue. An unfortunate situation. > > > > On 2011-03-02, at 6:05 AM, Brian Campbell wrote: > > > >> I propose that the "or native applications" text be=20 > dropped from the=20 > >> first paragraph in section 4.2 Implicit Grant [1]. > >> > >> There is clearly some disagreement about what is most=20 > appropriate for=20 > >> mobile/native applications and many, including myself, don't feel=20 > >> that the implicit grant works well to support them (due to=20 > the lack=20 > >> of a refresh token and need to repeat the authorization steps). I=20 > >> understand that the text in section 4 is non-normative, however, I=20 > >> feel that the mention of native apps in 4.2 biases thinking in a=20 > >> particular way (it's already led to one lengthy internal=20 > discussion=20 > >> that I'd rather not have again and again). I believe it'd be more=20 > >> appropriate for the draft to remain silent on how native=20 > apps should=20 > >> acquire tokens and leave it up to implementations/deployments to=20 > >> decide (or an extension draft as Marius has proposed). > >> > >> The "or native applications" text in is also somewhat inconsistent=20 > >> with the text in the following sentence that talks about the=20 > >> authentication of the client being based on the user-agent's=20 > >> same-origin policy. > >> > >> Removing those three words is a small change but one that I feel=20 > >> would be beneficial on a number of fronts. > >> > >> Thanks, > >> Brian > >> > >> > >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 > >> > >> On Wed, Feb 16, 2011 at 2:57 PM, Eran=20 > Hammer-Lahav wrote: > >>> Feel free to propose alternative preamble for the=20 > implicit and authorization code sections, describing the=20 > characteristics of what they are good for. It should fit in a=20 > single paragraph. Such a proposal would fit right in with=20 > last call feedback to -13. > >>> > >>> EHL > >>> > >>>> -----Original Message----- > >>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>>> Sent: Wednesday, February 16, 2011 1:39 PM > >>>> To: Eran Hammer-Lahav > >>>> Cc: Brian Campbell; OAuth WG > >>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline > >>>> > >>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav=20 > >>>> wrote: > >>>>> The reason why we don't return a refresh token in the implicit=20 > >>>>> grant is > >>>> exactly because there is no client authentication... > >>>> > >>>> Not sure that's the main reason. AFAIK it is because the=20 > response=20 > >>>> is sent through the user-agent and it could leak. > >>>> > >>>> > >>>>> These are all well-balanced flows with specific security=20 > >>>>> properties. If you > >>>> need something else, even if it is just a tweak, it must be=20 > >>>> considered a different flow. That doesn't mean you need=20 > to register=20 > >>>> a new grant type, just that you are dealing with different=20 > >>>> implementation details unique to your server. > >>>> > >>>> The Authorization Code flow, with no client secret, is perfectly=20 > >>>> fine for Native Apps IMO. > >>>> > >>>> Marius > >> _______________________________________________ > >> 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 > _______________________________________________ > 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 > = From bcampbell@pingidentity.com Mon Mar 7 07:16:39 2011 Return-Path: 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 930193A67E1 for ; Mon, 7 Mar 2011 07:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.977 X-Spam-Level: X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 65gVE2PXcOfS for ; Mon, 7 Mar 2011 07:16:38 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with ESMTP id 40A203A67D3 for ; Mon, 7 Mar 2011 07:16:37 -0800 (PST) Received: from source ([209.85.161.45]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTXT3HuyB5Sv8nOXaDKlnVFGOepsfFpl+@postini.com; Mon, 07 Mar 2011 07:17:51 PST Received: by mail-fx0-f45.google.com with SMTP id 11so4704283fxm.18 for ; Mon, 07 Mar 2011 07:17:50 -0800 (PST) Received: by 10.223.143.86 with SMTP id t22mr562134fau.78.1299510993557; Mon, 07 Mar 2011 07:16:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.16.73 with HTTP; Mon, 7 Mar 2011 07:15:33 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Mon, 7 Mar 2011 08:15:33 -0700 Message-ID: To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:16:39 -0000 I don't disagree with any of that, Dick. But in the absence of any specific solution or recommendation from the WG regarding native apps, I am simply asking that the somewhat misleading text be removed from the framework spec. On Sun, Mar 6, 2011 at 3:12 PM, Dick Hardt wrote: > -1 > > Many sites are using OAuth (or something like it) in native apps now. > > One of the objectives of having a standard is to bring best practices and= standardization to how to solve a problem rather than "a million freakin u= nique snowflakes" where developers have to learn and code each mechanism to= enable authorization to a native app. Brian's suggested wording may make s= ense in the context of where OAuth is now -- but it signals that the WG has= been unable to solve what I think many viewed as an important aspect of th= e WG. > > fwiw: I think a number of important constituents have opted out of the di= alogue. An unfortunate situation. > > On 2011-03-02, at 6:05 AM, Brian Campbell wrote: > >> I propose that the "or native applications" text be dropped from the >> first paragraph in section 4.2 Implicit Grant =A0[1]. >> >> There is clearly some disagreement about what is most appropriate for >> mobile/native applications and many, including myself, don't feel that >> the implicit grant works well to support them (due to the lack of a >> refresh token and need to repeat the authorization steps). =A0I >> understand that the text in section 4 is non-normative, however, I >> feel that the mention of native apps in 4.2 biases thinking in a >> particular way (it's already led to one lengthy internal discussion >> that I'd rather not have again and again). =A0I believe it'd be more >> appropriate for the draft to remain silent on how native apps should >> acquire tokens and leave it up to implementations/deployments to >> decide (or an extension draft as Marius has proposed). >> >> The "or native applications" text in is also somewhat inconsistent >> with the text in the following sentence that talks about the >> authentication of the client being based on the user-agent's >> same-origin policy. >> >> Removing those three words is a small change but one that I feel would >> be beneficial on a number of fronts. >> >> Thanks, >> Brian >> >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 >> >> On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav = wrote: >>> Feel free to propose alternative preamble for the implicit and authoriz= ation code sections, describing the characteristics of what they are good f= or. It should fit in a single paragraph. Such a proposal would fit right in= with last call feedback to -13. >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>> Sent: Wednesday, February 16, 2011 1:39 PM >>>> To: Eran Hammer-Lahav >>>> Cc: Brian Campbell; OAuth WG >>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>>> >>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>>> wrote: >>>>> The reason why we don't return a refresh token in the implicit grant = is >>>> exactly because there is no client authentication... >>>> >>>> Not sure that's the main reason. AFAIK it is because the response is s= ent >>>> through the user-agent and it could leak. >>>> >>>> >>>>> These are all well-balanced flows with specific security properties. = If you >>>> need something else, even if it is just a tweak, it must be considered= a >>>> different flow. That doesn't mean you need to register a new grant typ= e, just >>>> that you are dealing with different implementation details unique to y= our >>>> server. >>>> >>>> The Authorization Code flow, with no client secret, is perfectly fine = for Native >>>> Apps IMO. >>>> >>>> Marius >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > From skylar@kiva.org Mon Mar 7 11:36:41 2011 Return-Path: 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 9294D3A681D for ; Mon, 7 Mar 2011 11:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Ir-5VB6it9IT for ; Mon, 7 Mar 2011 11:36:40 -0800 (PST) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by core3.amsl.com (Postfix) with SMTP id C36A93A6809 for ; Mon, 7 Mar 2011 11:36:39 -0800 (PST) Received: from source ([209.85.161.169]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTXU0EN6qfoLM49l82yMuKYGTrBKPs7RC@postini.com; Mon, 07 Mar 2011 11:37:54 PST Received: by gxk2 with SMTP id 2so2280965gxk.14 for ; Mon, 07 Mar 2011 11:37:52 -0800 (PST) Received: by 10.90.22.29 with SMTP id 29mr5608459agv.32.1299526671758; Mon, 07 Mar 2011 11:37:51 -0800 (PST) Received: from [10.0.1.4] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id w4sm4177447anw.36.2011.03.07.11.37.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2011 11:37:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Mon, 7 Mar 2011 11:37:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <4D74ACB8.3040707@lodderstedt.net> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:36:41 -0000 Justin has well stated my view on this. Folks here have explained how = the flows can work for (or doesn't prohibit) a native app, but it also = seems clear that new readers don't pick up how native apps fit into the = flow in a 1st or 2nd pass. So, in short, I agree with Brian's suggestion of (1) removing choice = references to native apps, and (2) as a further (and preferred) step, a = better preamble (possibly with further supporting edits) on the role of = native apps. It seems Justin and Torsten are suggesting the same. To go further than step 1 I agree we need some discussion on the story = for native apps. For my part, here's how I see them fitting in: - The general assumption is that Native apps can't keep secrets. This is = mostly true except... - Native apps with secured distribution (eg, controlled access by = corporate IT departments who also can modify app preferences w/ the = provider) can claim the apps keep secrets. (A sample use case are Kiva = field partners who develop simple enterprise apps for use inside a = firewall). - In truth, the question of secrets or no secrets (can authenticate or = spoofable) is of primary importance for choosing a flow. - In the common case, Native apps without secrets, an implicit flow or = auth-code flow can be used. If an auth-code flow is used, there should = be no client authentication. Alternatively, providers may instruct such = clients to authenticate with an empty secret (since such clients should = never be issued secrets to begin with). - In the uncommon case of native apps who can keep secrets, an implicit = flow cannot be used. The app must present credentials which requires an = auth-code (or other) flow. - I think there should be some note added to the auth-code flow on how a = native app chooses and makes use of a redirect_uri. This was present in = draft 10 and was (i think) key to understanding the auth-code story for = native apps. I do not have strong opinions on the client-assertion flows for native = apps nor the issuance of refresh tokens in an implicit flow. It does = seem that some find it important to be able to issue refresh tokens to = clients without secrets. I don't see a good argument to restrict this = from a policy point of view (rather it seems more of issue of mechanics = and/or fragment parsing), but it does seem the policy should be = consistent. That is, if as an issue of policy, refresh tokens are not = issued to apps without credentials, the policy applies for auth-code = flows or implicit flows. skylar On Mar 7, 2011, at 5:54 AM, Richer, Justin P. wrote: > Agree with Torsten - having the mention in just that one place doesn't = make sense. It should be removed or replicated throughout, but I think = we might want a paragraph addressing native apps more deeply in the = introduction. We don't want to give the (incorrect) impression that the = implicit flow is the only or even preferred flow for native apps. >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of = Torsten Lodderstedt [torsten@lodderstedt.net] > Sent: Monday, March 07, 2011 5:00 AM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft = -12 feedback deadline) >=20 > Hi Dick, >=20 > I agree with you, the OAuth standard should offer clear patterns for > native apps. >=20 > All native apps I'm familiar with use the authorization code, which is > because of its support for refresh tokens. But the current text of the > spec only suggests to use the implict grant flow to implement native > apps whereas previous versions mentioned authz code and password flow = as > well. So in my opinion, the text is misleading to developers. And = that's > not only a feeling since I already meet people, which have been > misguided :-(. >=20 > I think at least the misleading words shall be removed. Better would = be > to come up with a consensus after a discussion in the group. >=20 > regards, > Torsten. >=20 > Am 06.03.2011 23:12, schrieb Dick Hardt: >> -1 >>=20 >> Many sites are using OAuth (or something like it) in native apps now. >>=20 >> One of the objectives of having a standard is to bring best practices = and standardization to how to solve a problem rather than "a million = freakin unique snowflakes" where developers have to learn and code each = mechanism to enable authorization to a native app. Brian's suggested = wording may make sense in the context of where OAuth is now -- but it = signals that the WG has been unable to solve what I think many viewed as = an important aspect of the WG. >>=20 >> fwiw: I think a number of important constituents have opted out of = the dialogue. An unfortunate situation. >>=20 >> On 2011-03-02, at 6:05 AM, Brian Campbell wrote: >>=20 >>> I propose that the "or native applications" text be dropped from the >>> first paragraph in section 4.2 Implicit Grant [1]. >>>=20 >>> There is clearly some disagreement about what is most appropriate = for >>> mobile/native applications and many, including myself, don't feel = that >>> the implicit grant works well to support them (due to the lack of a >>> refresh token and need to repeat the authorization steps). I >>> understand that the text in section 4 is non-normative, however, I >>> feel that the mention of native apps in 4.2 biases thinking in a >>> particular way (it's already led to one lengthy internal discussion >>> that I'd rather not have again and again). I believe it'd be more >>> appropriate for the draft to remain silent on how native apps should >>> acquire tokens and leave it up to implementations/deployments to >>> decide (or an extension draft as Marius has proposed). >>>=20 >>> The "or native applications" text in is also somewhat inconsistent >>> with the text in the following sentence that talks about the >>> authentication of the client being based on the user-agent's >>> same-origin policy. >>>=20 >>> Removing those three words is a small change but one that I feel = would >>> be beneficial on a number of fronts. >>>=20 >>> Thanks, >>> Brian >>>=20 >>>=20 >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 >>>=20 >>> On Wed, Feb 16, 2011 at 2:57 PM, Eran = Hammer-Lahav wrote: >>>> Feel free to propose alternative preamble for the implicit and = authorization code sections, describing the characteristics of what they = are good for. It should fit in a single paragraph. Such a proposal would = fit right in with last call feedback to -13. >>>>=20 >>>> EHL >>>>=20 >>>>> -----Original Message----- >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>> Sent: Wednesday, February 16, 2011 1:39 PM >>>>> To: Eran Hammer-Lahav >>>>> Cc: Brian Campbell; OAuth WG >>>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>>>>=20 >>>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>>>> wrote: >>>>>> The reason why we don't return a refresh token in the implicit = grant is >>>>> exactly because there is no client authentication... >>>>>=20 >>>>> Not sure that's the main reason. AFAIK it is because the response = is sent >>>>> through the user-agent and it could leak. >>>>>=20 >>>>>=20 >>>>>> These are all well-balanced flows with specific security = properties. If you >>>>> need something else, even if it is just a tweak, it must be = considered a >>>>> different flow. That doesn't mean you need to register a new grant = type, just >>>>> that you are dealing with different implementation details unique = to your >>>>> server. >>>>>=20 >>>>> The Authorization Code flow, with no client secret, is perfectly = fine for Native >>>>> Apps IMO. >>>>>=20 >>>>> Marius >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 From dick.hardt@gmail.com Mon Mar 7 12:07:58 2011 Return-Path: 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 3AB383A67B3 for ; Mon, 7 Mar 2011 12:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SFcgAUowaqrl for ; Mon, 7 Mar 2011 12:07:54 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id EAF023A6765 for ; Mon, 7 Mar 2011 12:07:53 -0800 (PST) Received: by pzk30 with SMTP id 30so1223281pzk.31 for ; Mon, 07 Mar 2011 12:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=cCPR+2+gKhbxVsKBgbFod12KSlvChsRAITEom/nObjA=; b=P240AJ2sXWtmfu78Qde/Iqk7DZ67XBzRNY97tD75uWwVKorE/uQKWtwr3TAhqJGzW2 fwJ+5ednnN+wrPnL1DGV/1yZLrjWE/4bMzBESYyP3KceXfFjrQQpKPU7IbhsuNDCftKn f3QF8jEb6B8BWA1wZnzaKIpkPuI0ZdIREYfiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=awermE+gCyuz7dQEuhDR7XZ7K2FRSVDe30fkd/ue88Z5ITR5dUEfwdQITFwa10cXuB pu8l9sbeuniH74fifZKY0qBNcMSZIdz/DEiTeZYOD3RkMFeIu+CWIIy/ZZuJaLKpDLBP ON6KP2g1iZDGR4N+StY14nQnKQraZkaL8mJF8= Received: by 10.142.222.16 with SMTP id u16mr3570901wfg.326.1299528547441; Mon, 07 Mar 2011 12:09:07 -0800 (PST) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id m10sm4862244wfl.11.2011.03.07.12.09.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2011 12:09:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Mon, 7 Mar 2011 12:09:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Campbell X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 20:07:58 -0000 Brian: I agree with your comments if native apps are not going to be = supported in OAuth v2.=20 my -1 is towards dropping native app support, and your suggestion was = the easiest thread to comment on. On 2011-03-07, at 7:15 AM, Brian Campbell wrote: > I don't disagree with any of that, Dick. But in the absence of any > specific solution or recommendation from the WG regarding native apps, > I am simply asking that the somewhat misleading text be removed from > the framework spec. >=20 > On Sun, Mar 6, 2011 at 3:12 PM, Dick Hardt = wrote: >> -1 >>=20 >> Many sites are using OAuth (or something like it) in native apps now. >>=20 >> One of the objectives of having a standard is to bring best practices = and standardization to how to solve a problem rather than "a million = freakin unique snowflakes" where developers have to learn and code each = mechanism to enable authorization to a native app. Brian's suggested = wording may make sense in the context of where OAuth is now -- but it = signals that the WG has been unable to solve what I think many viewed as = an important aspect of the WG. >>=20 >> fwiw: I think a number of important constituents have opted out of = the dialogue. An unfortunate situation. >>=20 >> On 2011-03-02, at 6:05 AM, Brian Campbell wrote: >>=20 >>> I propose that the "or native applications" text be dropped from the >>> first paragraph in section 4.2 Implicit Grant [1]. >>>=20 >>> There is clearly some disagreement about what is most appropriate = for >>> mobile/native applications and many, including myself, don't feel = that >>> the implicit grant works well to support them (due to the lack of a >>> refresh token and need to repeat the authorization steps). I >>> understand that the text in section 4 is non-normative, however, I >>> feel that the mention of native apps in 4.2 biases thinking in a >>> particular way (it's already led to one lengthy internal discussion >>> that I'd rather not have again and again). I believe it'd be more >>> appropriate for the draft to remain silent on how native apps should >>> acquire tokens and leave it up to implementations/deployments to >>> decide (or an extension draft as Marius has proposed). >>>=20 >>> The "or native applications" text in is also somewhat inconsistent >>> with the text in the following sentence that talks about the >>> authentication of the client being based on the user-agent's >>> same-origin policy. >>>=20 >>> Removing those three words is a small change but one that I feel = would >>> be beneficial on a number of fronts. >>>=20 >>> Thanks, >>> Brian >>>=20 >>>=20 >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 >>>=20 >>> On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav = wrote: >>>> Feel free to propose alternative preamble for the implicit and = authorization code sections, describing the characteristics of what they = are good for. It should fit in a single paragraph. Such a proposal would = fit right in with last call feedback to -13. >>>>=20 >>>> EHL >>>>=20 >>>>> -----Original Message----- >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>> Sent: Wednesday, February 16, 2011 1:39 PM >>>>> To: Eran Hammer-Lahav >>>>> Cc: Brian Campbell; OAuth WG >>>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>>>>=20 >>>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>>>> wrote: >>>>>> The reason why we don't return a refresh token in the implicit = grant is >>>>> exactly because there is no client authentication... >>>>>=20 >>>>> Not sure that's the main reason. AFAIK it is because the response = is sent >>>>> through the user-agent and it could leak. >>>>>=20 >>>>>=20 >>>>>> These are all well-balanced flows with specific security = properties. If you >>>>> need something else, even if it is just a tweak, it must be = considered a >>>>> different flow. That doesn't mean you need to register a new grant = type, just >>>>> that you are dealing with different implementation details unique = to your >>>>> server. >>>>>=20 >>>>> The Authorization Code flow, with no client secret, is perfectly = fine for Native >>>>> Apps IMO. >>>>>=20 >>>>> Marius >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 From eran@hueniverse.com Mon Mar 7 13:10:07 2011 Return-Path: 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 0E3913A6820 for ; Mon, 7 Mar 2011 13:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 5O9IaHr1KsYb for ; Mon, 7 Mar 2011 13:10:05 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4C7513A6826 for ; Mon, 7 Mar 2011 13:09:59 -0800 (PST) Received: (qmail 21742 invoked from network); 7 Mar 2011 19:46:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Mar 2011 19:46:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Mar 2011 12:46:07 -0700 From: Eran Hammer-Lahav To: Skylar Woodward , "Richer, Justin P." Date: Mon, 7 Mar 2011 12:45:50 -0700 Thread-Topic: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) Thread-Index: Acvc/y7PdbCJoHwAS/Cue5a2zov9wwAAHgSw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234464F336BE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: , <4D74ACB8.3040707@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:10:07 -0000 I don't have strong views on keeping the reference to native apps, but the = spec no longer offers advice on picking a grant type, other than pointing o= ut the importance of being able to keep a secret. The term native app is un= defined. What is needed is a separate guide for helping newcomers pick the right gra= nt type for their specific needs. I also want to point out that this is a standard, not a tutorial. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Skylar Woodward > Sent: Monday, March 07, 2011 11:38 AM > To: Richer, Justin P. > Cc: OAuth WG > Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 > feedback deadline) >=20 > Justin has well stated my view on this. Folks here have explained how th= e > flows can work for (or doesn't prohibit) a native app, but it also seems = clear > that new readers don't pick up how native apps fit into the flow in a 1st= or > 2nd pass. >=20 > So, in short, I agree with Brian's suggestion of (1) removing choice refe= rences > to native apps, and (2) as a further (and preferred) step, a better pream= ble > (possibly with further supporting edits) on the role of native apps. It s= eems > Justin and Torsten are suggesting the same. >=20 > To go further than step 1 I agree we need some discussion on the story fo= r > native apps. For my part, here's how I see them fitting in: >=20 > - The general assumption is that Native apps can't keep secrets. This is = mostly > true except... > - Native apps with secured distribution (eg, controlled access by corpora= te IT > departments who also can modify app preferences w/ the provider) can > claim the apps keep secrets. (A sample use case are Kiva field partners = who > develop simple enterprise apps for use inside a firewall). > - In truth, the question of secrets or no secrets (can authenticate or > spoofable) is of primary importance for choosing a flow. > - In the common case, Native apps without secrets, an implicit flow or au= th- > code flow can be used. If an auth-code flow is used, there should be no c= lient > authentication. Alternatively, providers may instruct such clients to > authenticate with an empty secret (since such clients should never be iss= ued > secrets to begin with). > - In the uncommon case of native apps who can keep secrets, an implicit f= low > cannot be used. The app must present credentials which requires an auth- > code (or other) flow. > - I think there should be some note added to the auth-code flow on how a > native app chooses and makes use of a redirect_uri. This was present in > draft 10 and was (i think) key to understanding the auth-code story for n= ative > apps. >=20 > I do not have strong opinions on the client-assertion flows for native ap= ps > nor the issuance of refresh tokens in an implicit flow. It does seem that= some > find it important to be able to issue refresh tokens to clients without s= ecrets. > I don't see a good argument to restrict this from a policy point of view = (rather > it seems more of issue of mechanics and/or fragment parsing), but it does > seem the policy should be consistent. That is, if as an issue of policy, = refresh > tokens are not issued to apps without credentials, the policy applies for= auth- > code flows or implicit flows. >=20 > skylar >=20 >=20 > On Mar 7, 2011, at 5:54 AM, Richer, Justin P. wrote: >=20 > > Agree with Torsten - having the mention in just that one place doesn't > make sense. It should be removed or replicated throughout, but I think we > might want a paragraph addressing native apps more deeply in the > introduction. We don't want to give the (incorrect) impression that the > implicit flow is the only or even preferred flow for native apps. > > > > -- Justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of > > Torsten Lodderstedt [torsten@lodderstedt.net] > > Sent: Monday, March 07, 2011 5:00 AM > > To: Dick Hardt > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft > > -12 feedback deadline) > > > > Hi Dick, > > > > I agree with you, the OAuth standard should offer clear patterns for > > native apps. > > > > All native apps I'm familiar with use the authorization code, which is > > because of its support for refresh tokens. But the current text of the > > spec only suggests to use the implict grant flow to implement native > > apps whereas previous versions mentioned authz code and password flow > > as well. So in my opinion, the text is misleading to developers. And > > that's not only a feeling since I already meet people, which have been > > misguided :-(. > > > > I think at least the misleading words shall be removed. Better would > > be to come up with a consensus after a discussion in the group. > > > > regards, > > Torsten. > > > > Am 06.03.2011 23:12, schrieb Dick Hardt: > >> -1 > >> > >> Many sites are using OAuth (or something like it) in native apps now. > >> > >> One of the objectives of having a standard is to bring best practices = and > standardization to how to solve a problem rather than "a million freakin > unique snowflakes" where developers have to learn and code each > mechanism to enable authorization to a native app. Brian's suggested > wording may make sense in the context of where OAuth is now -- but it > signals that the WG has been unable to solve what I think many viewed as = an > important aspect of the WG. > >> > >> fwiw: I think a number of important constituents have opted out of the > dialogue. An unfortunate situation. > >> > >> On 2011-03-02, at 6:05 AM, Brian Campbell wrote: > >> > >>> I propose that the "or native applications" text be dropped from the > >>> first paragraph in section 4.2 Implicit Grant [1]. > >>> > >>> There is clearly some disagreement about what is most appropriate > >>> for mobile/native applications and many, including myself, don't > >>> feel that the implicit grant works well to support them (due to the > >>> lack of a refresh token and need to repeat the authorization steps). > >>> I understand that the text in section 4 is non-normative, however, I > >>> feel that the mention of native apps in 4.2 biases thinking in a > >>> particular way (it's already led to one lengthy internal discussion > >>> that I'd rather not have again and again). I believe it'd be more > >>> appropriate for the draft to remain silent on how native apps should > >>> acquire tokens and leave it up to implementations/deployments to > >>> decide (or an extension draft as Marius has proposed). > >>> > >>> The "or native applications" text in is also somewhat inconsistent > >>> with the text in the following sentence that talks about the > >>> authentication of the client being based on the user-agent's > >>> same-origin policy. > >>> > >>> Removing those three words is a small change but one that I feel > >>> would be beneficial on a number of fronts. > >>> > >>> Thanks, > >>> Brian > >>> > >>> > >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 > >>> > >>> On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer- > Lahav wrote: > >>>> Feel free to propose alternative preamble for the implicit and > authorization code sections, describing the characteristics of what they = are > good for. It should fit in a single paragraph. Such a proposal would fit = right in > with last call feedback to -13. > >>>> > >>>> EHL > >>>> > >>>>> -----Original Message----- > >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>>>> Sent: Wednesday, February 16, 2011 1:39 PM > >>>>> To: Eran Hammer-Lahav > >>>>> Cc: Brian Campbell; OAuth WG > >>>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline > >>>>> > >>>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav > >>>>> wrote: > >>>>>> The reason why we don't return a refresh token in the implicit > >>>>>> grant is > >>>>> exactly because there is no client authentication... > >>>>> > >>>>> Not sure that's the main reason. AFAIK it is because the response > >>>>> is sent through the user-agent and it could leak. > >>>>> > >>>>> > >>>>>> These are all well-balanced flows with specific security > >>>>>> properties. If you > >>>>> need something else, even if it is just a tweak, it must be > >>>>> considered a different flow. That doesn't mean you need to > >>>>> register a new grant type, just that you are dealing with > >>>>> different implementation details unique to your server. > >>>>> > >>>>> The Authorization Code flow, with no client secret, is perfectly > >>>>> fine for Native Apps IMO. > >>>>> > >>>>> Marius > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Tue Mar 8 06:25:26 2011 Return-Path: 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 B5A4F3A67B7 for ; Tue, 8 Mar 2011 06:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sw4eqmAIXPo4 for ; Tue, 8 Mar 2011 06:25:23 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 626993A688F for ; Tue, 8 Mar 2011 06:25:08 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1AA0A21B000E; Tue, 8 Mar 2011 09:26:20 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 12A952B78336; Tue, 8 Mar 2011 09:26:20 -0500 (EST) Received: from [129.83.50.23] (129.83.50.23) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Tue, 8 Mar 2011 09:26:19 -0500 From: Justin Richer To: Skylar Woodward In-Reply-To: References: , <4D74ACB8.3040707@lodderstedt.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 8 Mar 2011 09:26:03 -0500 Message-ID: <1299594363.8411.8.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:25:26 -0000 Also, there's a big difference between "can keep secrets" and "can be packed/shipped with secrets". Many native apps fit into the former category but not the latter, which makes storage of refresh tokens and other long-term credentials reasonable, but not server-issued client secrets. -- Justin On Mon, 2011-03-07 at 14:37 -0500, Skylar Woodward wrote: > Justin has well stated my view on this. Folks here have explained how the flows can work for (or doesn't prohibit) a native app, but it also seems clear that new readers don't pick up how native apps fit into the flow in a 1st or 2nd pass. > > So, in short, I agree with Brian's suggestion of (1) removing choice references to native apps, and (2) as a further (and preferred) step, a better preamble (possibly with further supporting edits) on the role of native apps. It seems Justin and Torsten are suggesting the same. > > To go further than step 1 I agree we need some discussion on the story for native apps. For my part, here's how I see them fitting in: > > - The general assumption is that Native apps can't keep secrets. This is mostly true except... > - Native apps with secured distribution (eg, controlled access by corporate IT departments who also can modify app preferences w/ the provider) can claim the apps keep secrets. (A sample use case are Kiva field partners who develop simple enterprise apps for use inside a firewall). > - In truth, the question of secrets or no secrets (can authenticate or spoofable) is of primary importance for choosing a flow. > - In the common case, Native apps without secrets, an implicit flow or auth-code flow can be used. If an auth-code flow is used, there should be no client authentication. Alternatively, providers may instruct such clients to authenticate with an empty secret (since such clients should never be issued secrets to begin with). > - In the uncommon case of native apps who can keep secrets, an implicit flow cannot be used. The app must present credentials which requires an auth-code (or other) flow. > - I think there should be some note added to the auth-code flow on how a native app chooses and makes use of a redirect_uri. This was present in draft 10 and was (i think) key to understanding the auth-code story for native apps. > > I do not have strong opinions on the client-assertion flows for native apps nor the issuance of refresh tokens in an implicit flow. It does seem that some find it important to be able to issue refresh tokens to clients without secrets. I don't see a good argument to restrict this from a policy point of view (rather it seems more of issue of mechanics and/or fragment parsing), but it does seem the policy should be consistent. That is, if as an issue of policy, refresh tokens are not issued to apps without credentials, the policy applies for auth-code flows or implicit flows. > > skylar > > > On Mar 7, 2011, at 5:54 AM, Richer, Justin P. wrote: > > > Agree with Torsten - having the mention in just that one place doesn't make sense. It should be removed or replicated throughout, but I think we might want a paragraph addressing native apps more deeply in the introduction. We don't want to give the (incorrect) impression that the implicit flow is the only or even preferred flow for native apps. > > > > -- Justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt [torsten@lodderstedt.net] > > Sent: Monday, March 07, 2011 5:00 AM > > To: Dick Hardt > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) > > > > Hi Dick, > > > > I agree with you, the OAuth standard should offer clear patterns for > > native apps. > > > > All native apps I'm familiar with use the authorization code, which is > > because of its support for refresh tokens. But the current text of the > > spec only suggests to use the implict grant flow to implement native > > apps whereas previous versions mentioned authz code and password flow as > > well. So in my opinion, the text is misleading to developers. And that's > > not only a feeling since I already meet people, which have been > > misguided :-(. > > > > I think at least the misleading words shall be removed. Better would be > > to come up with a consensus after a discussion in the group. > > > > regards, > > Torsten. > > > > Am 06.03.2011 23:12, schrieb Dick Hardt: > >> -1 > >> > >> Many sites are using OAuth (or something like it) in native apps now. > >> > >> One of the objectives of having a standard is to bring best practices and standardization to how to solve a problem rather than "a million freakin unique snowflakes" where developers have to learn and code each mechanism to enable authorization to a native app. Brian's suggested wording may make sense in the context of where OAuth is now -- but it signals that the WG has been unable to solve what I think many viewed as an important aspect of the WG. > >> > >> fwiw: I think a number of important constituents have opted out of the dialogue. An unfortunate situation. > >> > >> On 2011-03-02, at 6:05 AM, Brian Campbell wrote: > >> > >>> I propose that the "or native applications" text be dropped from the > >>> first paragraph in section 4.2 Implicit Grant [1]. > >>> > >>> There is clearly some disagreement about what is most appropriate for > >>> mobile/native applications and many, including myself, don't feel that > >>> the implicit grant works well to support them (due to the lack of a > >>> refresh token and need to repeat the authorization steps). I > >>> understand that the text in section 4 is non-normative, however, I > >>> feel that the mention of native apps in 4.2 biases thinking in a > >>> particular way (it's already led to one lengthy internal discussion > >>> that I'd rather not have again and again). I believe it'd be more > >>> appropriate for the draft to remain silent on how native apps should > >>> acquire tokens and leave it up to implementations/deployments to > >>> decide (or an extension draft as Marius has proposed). > >>> > >>> The "or native applications" text in is also somewhat inconsistent > >>> with the text in the following sentence that talks about the > >>> authentication of the client being based on the user-agent's > >>> same-origin policy. > >>> > >>> Removing those three words is a small change but one that I feel would > >>> be beneficial on a number of fronts. > >>> > >>> Thanks, > >>> Brian > >>> > >>> > >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 > >>> > >>> On Wed, Feb 16, 2011 at 2:57 PM, Eran Hammer-Lahav wrote: > >>>> Feel free to propose alternative preamble for the implicit and authorization code sections, describing the characteristics of what they are good for. It should fit in a single paragraph. Such a proposal would fit right in with last call feedback to -13. > >>>> > >>>> EHL > >>>> > >>>>> -----Original Message----- > >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >>>>> Sent: Wednesday, February 16, 2011 1:39 PM > >>>>> To: Eran Hammer-Lahav > >>>>> Cc: Brian Campbell; OAuth WG > >>>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline > >>>>> > >>>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav > >>>>> wrote: > >>>>>> The reason why we don't return a refresh token in the implicit grant is > >>>>> exactly because there is no client authentication... > >>>>> > >>>>> Not sure that's the main reason. AFAIK it is because the response is sent > >>>>> through the user-agent and it could leak. > >>>>> > >>>>> > >>>>>> These are all well-balanced flows with specific security properties. If you > >>>>> need something else, even if it is just a tweak, it must be considered a > >>>>> different flow. That doesn't mean you need to register a new grant type, just > >>>>> that you are dealing with different implementation details unique to your > >>>>> server. > >>>>> > >>>>> The Authorization Code flow, with no client secret, is perfectly fine for Native > >>>>> Apps IMO. > >>>>> > >>>>> Marius > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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 > From jricher@mitre.org Tue Mar 8 07:11:01 2011 Return-Path: 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 E4D293A68CB for ; Tue, 8 Mar 2011 07:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 hh2ZvrBX1oJC for ; Tue, 8 Mar 2011 07:10:59 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id E98513A689F for ; Tue, 8 Mar 2011 07:10:58 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BA8AE2B7813B; Tue, 8 Mar 2011 10:12:12 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B46E22B780E7; Tue, 8 Mar 2011 10:12:12 -0500 (EST) Received: from [129.83.50.23] (129.83.50.23) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Tue, 8 Mar 2011 10:12:12 -0500 From: Justin Richer To: Brian Eaton In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 8 Mar 2011 10:11:56 -0500 Message-ID: <1299597116.8411.14.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 15:11:01 -0000 Very strongly agree, repeat my suggestion to name the parameter "oauth2_token". -- Justin On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: > My two cents: > > We've already taken three user visible outages because the OAuth2 spec > reused the "oauth_token" parameter in a way that was not compatible > with the OAuth1 spec. > > Luckily they were all caught before they caused serious damage. > > Generic parameter names are not useful. They lead to confused > developers and confused code. If code needs to treat the values > differently, the names should be different as well. > > Cheers, > Brian > > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt wrote: > > There was some discussion on the type for the authorization header being > > OAUTH / MAC / BEARER etc. Did we have a resolution? > > As for section 2.2 and 2.3, should we not have a more neutral solution as > > well and use "authorization_token" instead of oauth_token. The idea is that > > the parameter corresponds to the authorization header and NOT the value of > > it. The value of such a parameter an be an encoded value that corresponds to > > the authorization header. For example: > > GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host: > > server.example.com > > instead of > > GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: server.example.com > > The concern is that if for some reason you switch to "MAC" tokens, then you > > have to change parameter names. Why not keep them consistent? > > Apologies if this was already resolved. > > Phil > > phil.hunt@oracle.com > > > > > > > > > > _______________________________________________ > > 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 From wmills@yahoo-inc.com Tue Mar 8 08:26:54 2011 Return-Path: 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 9CE2A3A692F for ; Tue, 8 Mar 2011 08:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 q2-Q3X1AtVTr for ; Tue, 8 Mar 2011 08:26:53 -0800 (PST) Received: from web121409.mail.ne1.yahoo.com (web121409.mail.ne1.yahoo.com [98.138.90.103]) by core3.amsl.com (Postfix) with SMTP id 51B0F3A6938 for ; Tue, 8 Mar 2011 08:26:46 -0800 (PST) Received: (qmail 68905 invoked by uid 60001); 8 Mar 2011 16:27:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1299601672; bh=DikoN/3QO5eICuf/z7NfQmos9kYzc0pmVCoFE0RbkmU=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=atafEUDl0y19V1/8UhMGJF47mAAQ8OZorJeUqDm7FdLJ9KRnE4E++6y1xjlABYeeXrhCNJZ3hHyqp7ECs5OA6qybsT90Bjinf0uAmmqtbc1cMS8wZt1vUdyt0q8l+Y9VdXpBpgq5sTVCa1R+JCOSIrP9pTQ2E2/QCPnPZygVZaw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=DorJHGzzFTphdKlaJ/V8fNw+0cUw4iy22pVLCxIBIklO53vV8FeRzFIciF/cRyrUFufJcET3m4733s4x/qU5Uv0jiVAdIy1dHiDz3RIUw31YU3etWuJKowo0meCkHZEvYkBRZGmuMuPfitATVAb33zCytFMLEcsupi+Ep5y7szc=; Message-ID: <388439.68556.qm@web121409.mail.ne1.yahoo.com> X-YMail-OSG: 2lDzAzEVM1k_vd9aoUrvXgLDZGVjpo2FiC3GuTlWXs97uFD AbfYEelWFpy4dkPILoGYqmeLzeRP5Imvj74DN9NqlLxZcKDUjmtDhXdh6Dgp .4F80_vBPx8iiiPntjCNQ2nr2r9NZhzIzgjLL9igPFDr3tXuAi5awx4d5s.k cS2H726lli3m8V7x5xPRnu6IAxTdnzbMe_D_Rd6C61KlfutIQZQjKfxmVSK. n3ISe6ArZwwHsG6dL9WXfCuYldlTHLFgwmSytz432doiEZgzWlj_XrdzEI4n PaCmWnIOR_y08myG0AMcaVa1vg5pXippBCRzGQFD9MHGrGQ-- Received: from [209.131.62.115] by web121409.mail.ne1.yahoo.com via HTTP; Tue, 08 Mar 2011 08:27:51 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.109.292656 Date: Tue, 8 Mar 2011 08:27:51 -0800 (PST) From: "William J. Mills" To: Justin Richer , Brian Eaton MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1450758639-1299601671=:68556" Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:26:54 -0000 --0-1450758639-1299601671=:68556 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable A major difference is now there is a scheme name that is differentiating.= =A0 You no longer have to parse the entire variable set to figure out what = is going on.=A0 Now the scheme name determines things.=A0 Now that we have = schemes I don't see re-using parameter names as a problem.=0A=0A=0A=0A_____= ___________________________=0AFrom: Justin Richer =0ATo:= Brian Eaton =0ACc: OAuth WG =0ASent: Tu= esday, March 8, 2011 7:11 AM=0ASubject: Re: [OAUTH-WG] OAuth Bearer Token d= raft=0A=0AVery strongly agree, repeat my suggestion to name the parameter= =0A"oauth2_token".=0A=0A-- Justin=0A=0AOn Fri, 2011-02-25 at 14:49 -0500, B= rian Eaton wrote:=0A> My two cents:=0A> =0A> We've already taken three user= visible outages because the OAuth2 spec=0A> reused the "oauth_token" param= eter in a way that was not compatible=0A> with the OAuth1 spec.=0A> =0A> Lu= ckily they were all caught before they caused serious damage.=0A> =0A> Gene= ric parameter names are not useful.=A0 They lead to confused=0A> developers= and confused code.=A0 If code needs to treat the values=0A> differently, t= he names should be different as well.=0A> =0A> Cheers,=0A> Brian=0A> =0A> O= n Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt wrote:=0A= > > There was some discussion on the type for the authorization header bein= g=0A> > OAUTH / MAC / BEARER etc. Did we have a resolution?=0A> > As for se= ction 2.2 and 2.3, should we not have a more neutral solution as=0A> > well= and use "authorization_token" instead of oauth_token. The idea is that=0A>= > the parameter corresponds to the authorization header and NOT the value = of=0A> > it. The value of such a parameter an be an encoded value that corr= esponds to=0A> > the authorization header.=A0 For example:=0A> > GET /resou= rce?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host:=0A> > server.exa= mple.com=0A> > instead of=0A> > GET /resource?oauth_token=3DvF9dft4qmT HTTP= /1.1 Host: server.example.com=0A> > The concern is that if for some reason = you switch to "MAC" tokens, then you=0A> > have to change parameter names. = Why not keep them consistent?=0A> > Apologies if this was already resolved.= =0A> > Phil=0A> > phil.hunt@oracle.com=0A> >=0A> >=0A> >=0A> >=0A> > ______= _________________________________________=0A> > OAuth mailing list=0A> > OA= uth@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/oauth=0A> >=0A> >= =0A> _______________________________________________=0A> OAuth mailing list= =0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A=0A= =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A=0A --0-1450758639-1299601671=:68556 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
A major di= fference is now there is a scheme name that is differentiating.  You n= o longer have to parse the entire variable set to figure out what is going = on.  Now the scheme name determines things.  Now that we have sch= emes I don't see re-using parameter names as a problem.

= From: Justin Richer <jr= icher@mitre.org>
To:= Brian Eaton <beaton@google.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Tuesday, March 8, 2011 7:11 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Tok= en draft

Very strongly agree, repeat my suggestion to name t= he parameter
"oauth2_token".

-- Justin

On Fri, 2011-02-25= at 14:49 -0500, Brian Eaton wrote:
> My two cents:
>
> = We've already taken three user visible outages because the OAuth2 spec
&= gt; reused the "oauth_token" parameter in a way that was not compatible
= > with the OAuth1 spec.
>
> Luckily they were all caught be= fore they caused serious damage.
>
> Generic parameter names a= re not useful.  They lead to confused
> developers and confused = code.  If code needs to treat the values
> differently, the name= s should be different as well.
>
> Cheers,
> Brian
&g= t;
> On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
> > There was some discussi= on on the type for the authorization header being
> > OAUTH / MAC = / BEARER etc. Did we have a resolution?
> > As for section 2.2 and= 2.3, should we not have a more neutral solution as
> > well and u= se "authorization_token" instead of oauth_token. The idea is that
> &= gt; the parameter corresponds to the authorization header and NOT the value= of
> > it. The value of such a parameter an be an encoded value t= hat corresponds to
> > the authorization header.  For example= :
> > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1= .1 Host:
> > server.example.com
> > instead of
> &g= t; GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: server.example.com=
> > The concern is that if for some reason you switch to "MAC" tokens, then you
> > have to change parameter names. Why not keep= them consistent?
> > Apologies if this was already resolved.
&= gt; > Phil
> > phil.hunt@oracle.com
> >
&= gt; >
> >
> >
> > ___________________________= ____________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >=
> >
> _______________________________________________
&g= t; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

<= br>_______________________________________________
OAuth mailing listOAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth


<= /div>

=0A=0A --0-1450758639-1299601671=:68556-- From jricher@mitre.org Tue Mar 8 08:40:26 2011 Return-Path: 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 ACDE73A6827 for ; Tue, 8 Mar 2011 08:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 d256huuLH1fQ for ; Tue, 8 Mar 2011 08:40:22 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 5E3F83A6912 for ; Tue, 8 Mar 2011 08:40:21 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7A5321B0684; Tue, 8 Mar 2011 11:41:35 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E110521B066F; Tue, 8 Mar 2011 11:41:35 -0500 (EST) Received: from [129.83.50.23] (129.83.50.23) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Tue, 8 Mar 2011 11:41:35 -0500 From: Justin Richer To: "William J. Mills" In-Reply-To: <388439.68556.qm@web121409.mail.ne1.yahoo.com> References: <388439.68556.qm@web121409.mail.ne1.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 8 Mar 2011 11:41:19 -0500 Message-ID: <1299602479.8411.25.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:40:26 -0000 I don't understand this comment. If you're using query/form parameters, there are no schemes involved in the process. -- Justin On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: > A major difference is now there is a scheme name that is > differentiating. You no longer have to parse the entire variable set > to figure out what is going on. Now the scheme name determines > things. Now that we have schemes I don't see re-using parameter names > as a problem. > > > > > ______________________________________________________________________ > From: Justin Richer > To: Brian Eaton > Cc: OAuth WG > Sent: Tuesday, March 8, 2011 7:11 AM > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > Very strongly agree, repeat my suggestion to name the parameter > "oauth2_token". > > -- Justin > > On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: > > My two cents: > > > > We've already taken three user visible outages because the OAuth2 > spec > > reused the "oauth_token" parameter in a way that was not compatible > > with the OAuth1 spec. > > > > Luckily they were all caught before they caused serious damage. > > > > Generic parameter names are not useful. They lead to confused > > developers and confused code. If code needs to treat the values > > differently, the names should be different as well. > > > > Cheers, > > Brian > > > > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt > wrote: > > > There was some discussion on the type for the authorization header > being > > > OAUTH / MAC / BEARER etc. Did we have a resolution? > > > As for section 2.2 and 2.3, should we not have a more neutral > solution as > > > well and use "authorization_token" instead of oauth_token. The > idea is that > > > the parameter corresponds to the authorization header and NOT the > value of > > > it. The value of such a parameter an be an encoded value that > corresponds to > > > the authorization header. For example: > > > GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host: > > > server.example.com > > > instead of > > > GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: > server.example.com > > > The concern is that if for some reason you switch to "MAC" tokens, > then you > > > have to change parameter names. Why not keep them consistent? > > > Apologies if this was already resolved. > > > Phil > > > phil.hunt@oracle.com > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > From wmills@yahoo-inc.com Tue Mar 8 09:03:51 2011 Return-Path: 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 E338C3A68DC for ; Tue, 8 Mar 2011 09:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 xU8HZHPtAECv for ; Tue, 8 Mar 2011 09:03:50 -0800 (PST) Received: from nm15.bullet.mail.ne1.yahoo.com (nm15.bullet.mail.ne1.yahoo.com [98.138.90.78]) by core3.amsl.com (Postfix) with SMTP id 4A29D3A67FB for ; Tue, 8 Mar 2011 09:03:50 -0800 (PST) Received: from [98.138.90.52] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 17:05:02 -0000 Received: from [98.138.89.246] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 17:05:02 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 17:05:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 566473.43400.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 99579 invoked by uid 60001); 8 Mar 2011 17:05:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1299603902; bh=xd0AnWbdUNUGME1hFagmX5cjhmkH5mo7taHakoq/Tgo=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=ID1b0grq7RpbqePmOS0TLGgNcobMjInbGvFmqDBqTBeF1ebkk3CT9vjaAyjTWmRf1XVZbQ9g+gbKvqQJqFoP3NxKrBHMQ0pDnJPvZYSua8AvjEBzJvGKrplt6PtHmcmRGitEjArIO9vOQ1MRByNc1fwjdM08mNsLsgQ/jUjMwVw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=rDaNnE/6fO40XmmrgC4gZN5NJtYPCxq4dd7g5OfInjoBt7K957a32Osj7wHwZ4DE/tZMwygmoclhppWLGtAoHmsWMYfL3zVsByQ5d7ZEHZQFuv73UX1DpDLrlSQ3w7V50Fr1SaeaZEwI5OjZ7dop8Yf9lE5HGWOLzZIlS7KetSo=; Message-ID: <332918.97656.qm@web121403.mail.ne1.yahoo.com> X-YMail-OSG: AG4Xxm8VM1mOR6rumN5107dJFJl62z.q.1ukRY6.a1N5Jga lymsbUPfZmjB1Eq.7nyFtlzNXX.1Crm_HqpM.Mmgc.A_aU7bzEA_gxcjt1PV tTCNsKRYNwUu_j2spoGE3RuQjtIU1CSpaNmFX5pI_RQOMQ3M1FAB2Ky7Bn5W iZ6Nx9akEQsK55x3SZwPTIGMaR_6_EUQKYfxXMG2vLF9Xk6B0jLBdXy2pB5i c88QVb4v8KW7A8Wy9QFHid2HZCWxV5ET7NgE6il4Go5Nel0vB5BfejMa2V_j orWtWT7.o5r.XjBnr..lK_PaDBWuy1eIHBSpkKurhTol.3w-- Received: from [209.131.62.115] by web121403.mail.ne1.yahoo.com via HTTP; Tue, 08 Mar 2011 09:05:02 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.109.292656 Date: Tue, 8 Mar 2011 09:05:02 -0800 (PST) From: "William J. Mills" To: Justin Richer MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-731354174-1299603902=:97656" Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:03:52 -0000 --0-731354174-1299603902=:97656 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable That's because I'm focused on my use case, which is using the Authorization= header.=A0 In query args/form parameters we definitely need better differe= ntiation.=0A=0A=0A=0A________________________________=0AFrom: Justin Richer= =0ATo: William J. Mills =0ACc: Br= ian Eaton ; OAuth WG =0ASent: Tuesday, M= arch 8, 2011 8:41 AM=0ASubject: Re: [OAUTH-WG] OAuth Bearer Token draft=0A= =0AI don't understand this comment. If you're using query/form parameters,= =0Athere are no schemes involved in the process.=0A=0A-- Justin=0A=0A=0AOn = Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote:=0A> A major differe= nce is now there is a scheme name that is=0A> differentiating.=A0 You no lo= nger have to parse the entire variable set=0A> to figure out what is going = on.=A0 Now the scheme name determines=0A> things.=A0 Now that we have schem= es I don't see re-using parameter names=0A> as a problem.=0A> =0A> =0A> =0A= > =0A> ____________________________________________________________________= __=0A> From: Justin Richer =0A> To: Brian Eaton =0A> Cc: OAuth WG =0A> Sent: Tuesday, March 8, 2= 011 7:11 AM=0A> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft=0A> =0A> V= ery strongly agree, repeat my suggestion to name the parameter=0A> "oauth2_= token".=0A> =0A> -- Justin=0A> =0A> On Fri, 2011-02-25 at 14:49 -0500, Bria= n Eaton wrote:=0A> > My two cents:=0A> > =0A> > We've already taken three u= ser visible outages because the OAuth2=0A> spec=0A> > reused the "oauth_tok= en" parameter in a way that was not compatible=0A> > with the OAuth1 spec.= =0A> > =0A> > Luckily they were all caught before they caused serious damag= e.=0A> > =0A> > Generic parameter names are not useful.=A0 They lead to con= fused=0A> > developers and confused code.=A0 If code needs to treat the val= ues=0A> > differently, the names should be different as well.=0A> > =0A> > = Cheers,=0A> > Brian=0A> > =0A> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hun= t =0A> wrote:=0A> > > There was some discussion on th= e type for the authorization header=0A> being=0A> > > OAUTH / MAC / BEARER = etc. Did we have a resolution?=0A> > > As for section 2.2 and 2.3, should w= e not have a more neutral=0A> solution as=0A> > > well and use "authorizati= on_token" instead of oauth_token. The=0A> idea is that=0A> > > the paramete= r corresponds to the authorization header and NOT the=0A> value of=0A> > > = it. The value of such a parameter an be an encoded value that=0A> correspon= ds to=0A> > > the authorization header.=A0 For example:=0A> > > GET /resour= ce?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host:=0A> > > server.ex= ample.com=0A> > > instead of=0A> > > GET /resource?oauth_token=3DvF9dft4qmT= HTTP/1.1 Host:=0A> server.example.com=0A> > > The concern is that if for s= ome reason you switch to "MAC" tokens,=0A> then you=0A> > > have to change = parameter names. Why not keep them consistent?=0A> > > Apologies if this wa= s already resolved.=0A> > > Phil=0A> > > phil.hunt@oracle.com=0A> > >=0A> >= >=0A> > >=0A> > >=0A> > > _______________________________________________= =0A> > > OAuth mailing list=0A> > > OAuth@ietf.org=0A> > > https://www.ietf= .org/mailman/listinfo/oauth=0A> > >=0A> > >=0A> > _________________________= ______________________=0A> > OAuth mailing list=0A> > OAuth@ietf.org=0A> > = https://www.ietf.org/mailman/listinfo/oauth=0A> =0A> =0A> _________________= ______________________________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/oauth=0A> =0A> =0A> =0A> =0A=0A=0A = --0-731354174-1299603902=:97656 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
That's bec= ause I'm focused on my use case, which is using the Authorization header.&n= bsp; In query args/form parameters we definitely need better differentiatio= n.

From: Justin Richer <jricher@mitre.org>
To: William J. Mills <wmills@yahoo-inc.com>
= Cc: Brian Eaton <beaton@go= ogle.com>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, March 8, 2011 8:41 AM
Subject: Re: [OAUTH-WG] OAuth Bear= er Token draft

I don't understand this comment. If you're us= ing query/form parameters,
there are no schemes involved in the process.=

-- Justin


On Tue, 2011-03-08 at 11:27 -0500, William J.= Mills wrote:
> A major difference is now there is a scheme name that= is
> differentiating.  You no longer have to parse the entire v= ariable set
> to figure out what is going on.  Now the scheme na= me determines
> things.  Now that we have schemes I don't see re= -using parameter names
> as a problem.
>
>
>
= >
> _____________________________________________________________= _________
> From: Justin Richer <jricher@mitre.org>
> = To: Brian Eaton <beaton@google.com>
> Cc: OA= uth WG <oauth@ietf.org>
> Sent: Tuesday, March 8, 2011 7:11 AM
= > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>
> Very= strongly agree, repeat my suggestion to name the parameter
> "oauth2= _token".
>
> -- Justin
>
> On Fri, 2011-02-25 at = 14:49 -0500, Brian Eaton wrote:
> > My two cents:
> > > > We've already taken three user visible outages because the OAuth= 2
> spec
> > reused the "oauth_token" parameter in a way tha= t was not compatible
> > with the OAuth1 spec.
> >
&g= t; > Luckily they were all caught before they caused serious damage.
= > >
> > Generic parameter names are not useful.  They = lead to confused
> > developers and confused code.  If code needs to treat the values
> > differently, the names should be di= fferent as well.
> >
> > Cheers,
> > Brian
&= gt; >
> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt <phil.hunt@oracle.com>
> wrote:
> > > There was so= me discussion on the type for the authorization header
> being
>= ; > > OAUTH / MAC / BEARER etc. Did we have a resolution?
> >= ; > As for section 2.2 and 2.3, should we not have a more neutral
>= ; solution as
> > > well and use "authorization_token" instead = of oauth_token. The
> idea is that
> > > the parameter co= rresponds to the authorization header and NOT the
> value of
> = > > it. The value of such a parameter an be an encoded value that
= > corresponds to
> > > the authorization header.  For example:
> > > GET /resource?authorization_token=3DBEARER+= vF9dft4qmT HTTP/1.1 Host:
> > > server.example.com
> >= > instead of
> > > GET /resource?oauth_token=3DvF9dft4qmT H= TTP/1.1 Host:
> server.example.com
> > > The concern is t= hat if for some reason you switch to "MAC" tokens,
> then you
>= > > have to change parameter names. Why not keep them consistent?> > > Apologies if this was already resolved.
> > > P= hil
> > > phil.hunt@oracle.com
> > >
&g= t; > >
> > >
> > >
> > > ________= _______________________________________
> > > OAuth mailing lis= t
> > > OAuth@ietf.org
> > > htt= ps://www.ietf.org/mailman/listinfo/oauth
> > >
> >= >
> > _______________________________________________
> = > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ie= tf.org/mailman/listinfo/oauth
>
>
> _______________= ________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>= ;
>
>





=0A=0A <= /body> --0-731354174-1299603902=:97656-- From wmills@yahoo-inc.com Tue Mar 8 09:10:45 2011 Return-Path: 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 5E4BC3A6928 for ; Tue, 8 Mar 2011 09:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 j3IA9rqEiAge for ; Tue, 8 Mar 2011 09:10:38 -0800 (PST) Received: from web121404.mail.ne1.yahoo.com (web121404.mail.ne1.yahoo.com [98.138.90.98]) by core3.amsl.com (Postfix) with SMTP id 00B8C3A68F5 for ; Tue, 8 Mar 2011 09:10:34 -0800 (PST) Received: (qmail 98426 invoked by uid 60001); 8 Mar 2011 17:11:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1299604306; bh=2kuLDoCw6tvIdvLWl0Ssc1rOSuF3NgVC69JPo4Kf5io=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=f5ZmLSPiR8MUANV/tw5UT4KDnRInL/Fd3ufaY/h3IMxwPm0NyJvUNYVwU6r/PMuGleF29Upn2qjuSaK80zXtGi9zaZJNd70Dl7r23m15GyPSzBoclzKqh71Qlj8Xo9VMgM5kE2utKbkLZVTSbzoZosWbxtDHMH92hUPpaU0czAw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=ba465LG59VIaf8Py0qa3i393ZCHen01E7fLIowBYv7Q3rJ3lHfNl4sk8/UvJIcZV88j4i5UQsDRWBBAcwM7WF4MNtq9mxPqhoEVJdKMrl1kFtHs5RbOEU7ma5H7/D9HH48vKXJQ9Hp43uX6TY4Fyx4s60eJBjd0100U2hvJXgnk=; Message-ID: <836580.97993.qm@web121404.mail.ne1.yahoo.com> X-YMail-OSG: YNisdWAVM1mawGzk7OqSDrwx5fDriuecFXS_d1ZvXGz1f6K .peSTPMdf78tIQm756AU4jIQ2YqjF.AX41ndk0kZwREPQ8Fi_Nm7QG48axI. c.mKfeJ3yu17oM4FoswDkmtdk3CxiGlvBwUoWrT4XqC3ZYBWRyaIhPoJAYfH yNbLeY0BuXu7o1d7lKs_KnoOvUQxOG0fp01_2p4QIwzPWFUGmC9cmY4fkIHy roJ3zsAA4ayAS7s_kyR_KkX3mQvDDCJj2nZfFOFgoutpoPY_owv1o.WF2pK. 6fYT_JqeExl28.uC0KUjPq3illw-- Received: from [209.131.62.115] by web121404.mail.ne1.yahoo.com via HTTP; Tue, 08 Mar 2011 09:11:46 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.109.292656 Date: Tue, 8 Mar 2011 09:11:46 -0800 (PST) From: "William J. Mills" To: Justin Richer MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1858112419-1299604306=:97993" Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:10:45 -0000 --0-1858112419-1299604306=:97993 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So is a different namespace for each new mechanism right, or should a param= eter be added to parallel the authorization scheme name?=A0 Seems like it w= ould be clean to define oauth_scheme and use the same value as defined for = the auth scheme name.=0A=0A=0A=0A________________________________=0AFrom: J= ustin Richer =0ATo: William J. Mills =0ACc: Brian Eaton ; OAuth WG =0ASent= : Tuesday, March 8, 2011 8:41 AM=0ASubject: Re: [OAUTH-WG] OAuth Bearer Tok= en draft=0A=0AI don't understand this comment. If you're using query/form p= arameters,=0Athere are no schemes involved in the process.=0A=0A-- Justin= =0A=0A=0AOn Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote:=0A> A m= ajor difference is now there is a scheme name that is=0A> differentiating.= =A0 You no longer have to parse the entire variable set=0A> to figure out w= hat is going on.=A0 Now the scheme name determines=0A> things.=A0 Now that = we have schemes I don't see re-using parameter names=0A> as a problem.=0A> = =0A> =0A> =0A> =0A> _______________________________________________________= _______________=0A> From: Justin Richer =0A> To: Brian E= aton =0A> Cc: OAuth WG =0A> Sent: Tuesda= y, March 8, 2011 7:11 AM=0A> Subject: Re: [OAUTH-WG] OAuth Bearer Token dra= ft=0A> =0A> Very strongly agree, repeat my suggestion to name the parameter= =0A> "oauth2_token".=0A> =0A> -- Justin=0A> =0A> On Fri, 2011-02-25 at 14:4= 9 -0500, Brian Eaton wrote:=0A> > My two cents:=0A> > =0A> > We've already = taken three user visible outages because the OAuth2=0A> spec=0A> > reused t= he "oauth_token" parameter in a way that was not compatible=0A> > with the = OAuth1 spec.=0A> > =0A> > Luckily they were all caught before they caused s= erious damage.=0A> > =0A> > Generic parameter names are not useful.=A0 They= lead to confused=0A> > developers and confused code.=A0 If code needs to t= reat the values=0A> > differently, the names should be different as well.= =0A> > =0A> > Cheers,=0A> > Brian=0A> > =0A> > On Fri, Feb 25, 2011 at 11:3= 8 AM, Phil Hunt =0A> wrote:=0A> > > There was some di= scussion on the type for the authorization header=0A> being=0A> > > OAUTH /= MAC / BEARER etc. Did we have a resolution?=0A> > > As for section 2.2 and= 2.3, should we not have a more neutral=0A> solution as=0A> > > well and us= e "authorization_token" instead of oauth_token. The=0A> idea is that=0A> > = > the parameter corresponds to the authorization header and NOT the=0A> val= ue of=0A> > > it. The value of such a parameter an be an encoded value that= =0A> corresponds to=0A> > > the authorization header.=A0 For example:=0A> >= > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host:=0A>= > > server.example.com=0A> > > instead of=0A> > > GET /resource?oauth_toke= n=3DvF9dft4qmT HTTP/1.1 Host:=0A> server.example.com=0A> > > The concern is= that if for some reason you switch to "MAC" tokens,=0A> then you=0A> > > h= ave to change parameter names. Why not keep them consistent?=0A> > > Apolog= ies if this was already resolved.=0A> > > Phil=0A> > > phil.hunt@oracle.com= =0A> > >=0A> > >=0A> > >=0A> > >=0A> > > __________________________________= _____________=0A> > > OAuth mailing list=0A> > > OAuth@ietf.org=0A> > > htt= ps://www.ietf.org/mailman/listinfo/oauth=0A> > >=0A> > >=0A> > ____________= ___________________________________=0A> > OAuth mailing list=0A> > OAuth@ie= tf.org=0A> > https://www.ietf.org/mailman/listinfo/oauth=0A> =0A> =0A> ____= ___________________________________________=0A> OAuth mailing list=0A> OAut= h@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A> =0A> =0A> = =0A> =0A=0A=0A --0-1858112419-1299604306=:97993 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So is a di= fferent namespace for each new mechanism right, or should a parameter be ad= ded to parallel the authorization scheme name?  Seems like it would be= clean to define oauth_scheme and use the same value as defined for the aut= h scheme name.

Fro= m: Justin Richer <jricher@mitre.org>
To: William J. Mills <wmills@yahoo-inc.co= m>
Cc: Brian Eaton &= lt;beaton@google.com>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, March 8, 2011 8:41 = AM
Subject: Re: [OAUTH-= WG] OAuth Bearer Token draft

I don't understand this comment= . If you're using query/form parameters,
there are no schemes involved i= n the process.

-- Justin


On Tue, 2011-03-08 at 11:27 -05= 00, William J. Mills wrote:
> A major difference is now there is a sc= heme name that is
> differentiating.  You no longer have to pars= e the entire variable set
> to figure out what is going on.  Now= the scheme name determines
> things.  Now that we have schemes = I don't see re-using parameter names
> as a problem.
>
>=
>
>
> _______________________________________________= _______________________
> From: Justin Richer <jricher@mitre.org>
> To: Br= ian Eaton <beaton@google.com>
> Cc: OAuth WG <oauth@ietf.org>
> Sent: Tuesday, March 8, 2011 7:11 AM
> Subject: Re: [OA= UTH-WG] OAuth Bearer Token draft
>
> Very strongly agree, repe= at my suggestion to name the parameter
> "oauth2_token".
>
= > -- Justin
>
> On Fri, 2011-02-25 at 14:49 -0500, Brian Ea= ton wrote:
> > My two cents:
> >
> > We've alre= ady taken three user visible outages because the OAuth2
> spec
>= ; > reused the "oauth_token" parameter in a way that was not compatible<= br>> > with the OAuth1 spec.
> >
> > Luckily they = were all caught before they caused serious damage.
> >
> &g= t; Generic parameter names are not useful.  They lead to confused
>= ; > developers and confused code.  If code needs to treat the value= s
> > differently, the names should be different as well.
> = >
> > Cheers,
> > Brian
> >
> > On= Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt <phil.hunt@oracle.com= >
> wrote:
> > > There was some discussion on the type= for the authorization header
> being
> > > OAUTH / MAC /= BEARER etc. Did we have a resolution?
> > > As for section 2.2= and 2.3, should we not have a more neutral
> solution as
> >= ; > well and use "authorization_token" instead of oauth_token. The
&g= t; idea is that
> > > the parameter corresponds to the authoriz= ation header and NOT the
> value of
> > > it. The value of such a parameter an be an encoded value that
> corresponds = to
> > > the authorization header.  For example:
> &= gt; > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Hos= t:
> > > server.example.com
> > > instead of
>= ; > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host:
> s= erver.example.com
> > > The concern is that if for some reason = you switch to "MAC" tokens,
> then you
> > > have to chan= ge parameter names. Why not keep them consistent?
> > > Apologi= es if this was already resolved.
> > > Phil
> > > <= a ymailto=3D"mailto:phil.hunt@oracle.com" href=3D"mailto:phil.hunt@oracle.c= om">phil.hunt@oracle.com
> > >
> > >
> &g= t; >
> > >
> > > _______________________________= ________________
> > > OAuth mailing list
> > > OAuth@iet= f.org
> > > https://www.ietf.org/mailman/listinfo/oauth<= br>> > >
> > >
> > __________________________= _____________________
> > OAuth mailing list
> > OAuth@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAut= h mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/list= info/oauth
>
>
>
>





=0A=0A --0-1858112419-1299604306=:97993-- From bobaman@google.com Tue Mar 8 10:01:24 2011 Return-Path: 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 586C43A6928 for ; Tue, 8 Mar 2011 10:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 E5ETCXvwOx3k for ; Tue, 8 Mar 2011 10:01:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 42C9D3A68F7 for ; Tue, 8 Mar 2011 10:01:22 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p28I2bVd007207 for ; Tue, 8 Mar 2011 10:02:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299607357; bh=1+IlfViyuhjmAqPzMVqUXLD8PtQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=RDZsAhiTJlHRH2/dKKPzI9IvSIZVo0gzK/z7Gxal/6rXhaEyuVFRZYMOPOfcvh3oF Y7zGm3+7AXYL84da5pEbA== Received: from qyk32 (qyk32.prod.google.com [10.241.83.160]) by wpaz21.hot.corp.google.com with ESMTP id p28I25SS026918 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 10:02:35 -0800 Received: by qyk32 with SMTP id 32so4525446qyk.1 for ; Tue, 08 Mar 2011 10:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=kEao7V2/XomtzNR+aG9HsgVOl1/Rx6h2tSJgb6Ps04o=; b=iWPj3xjWs+rQi2jQRbebTTGVLpITMXiF0adq6DUimOCGDjC87o9+ihg1xgb2E5oniM /BZetTvia2GvxCkO9ulA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=XirJXe+rueZPbq5Xgi3E5yRkh/uYpy+B7xHg5ngo5lh1MPJnDDh37pNkwQA5D7dYlD zkiHvfNRaeyux9wl7CWw== Received: by 10.229.78.32 with SMTP id i32mr4341183qck.5.1299607355278; Tue, 08 Mar 2011 10:02:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.105.90 with HTTP; Tue, 8 Mar 2011 10:01:55 -0800 (PST) In-Reply-To: <836580.97993.qm@web121404.mail.ne1.yahoo.com> References: <836580.97993.qm@web121404.mail.ne1.yahoo.com> From: Bob Aman Date: Tue, 8 Mar 2011 10:01:55 -0800 Message-ID: To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:01:24 -0000 > So is a different namespace for each new mechanism right, or should a > parameter be added to parallel the authorization scheme name?=C2=A0 Seems= like it > would be clean to define oauth_scheme and use the same value as defined f= or > the auth scheme name. I'd much rather do it this way. There is value in reusing parameter names (at least for my client implementation anyways), as long as the scheme can be trivially determined. From eran@hueniverse.com Tue Mar 8 10:01:24 2011 Return-Path: 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 6993F3A68F7 for ; Tue, 8 Mar 2011 10:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 QvEmUV1RcPjc for ; Tue, 8 Mar 2011 10:01:23 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 08ED43A68AF for ; Tue, 8 Mar 2011 10:01:23 -0800 (PST) Received: (qmail 28180 invoked from network); 8 Mar 2011 18:02:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Mar 2011 18:02:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 8 Mar 2011 11:02:34 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Justin Richer Date: Tue, 8 Mar 2011 11:02:29 -0700 Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: AcvduwDXv+NbJ5HCQHWeM0W1EqQ/HA== Message-ID: In-Reply-To: <836580.97993.qm@web121404.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C99BAEE5E033eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:01:24 -0000 --_000_C99BAEE5E033eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I hope this will be the last time we define a query parameter for deliverin= g what should be sent via a request header field. Infringing on a service's= namespace is always a bad idea, no matter what prefix we put next to it. EHL From: "William J. Mills" = > Reply-To: "William J. Mills" > Date: Tue, 8 Mar 2011 10:11:46 -0700 To: Justin Richer > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft So is a different namespace for each new mechanism right, or should a param= eter be added to parallel the authorization scheme name? Seems like it wou= ld be clean to define oauth_scheme and use the same value as defined for th= e auth scheme name. ________________________________ From: Justin Richer > To: William J. Mills > Cc: Brian Eaton >; OAuth WG > Sent: Tuesday, March 8, 2011 8:41 AM Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I don't understand this comment. If you're using query/form parameters, there are no schemes involved in the process. -- Justin On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: > A major difference is now there is a scheme name that is > differentiating. You no longer have to parse the entire variable set > to figure out what is going on. Now the scheme name determines > things. Now that we have schemes I don't see re-using parameter names > as a problem. > > > > > ______________________________________________________________________ > From: Justin Richer > > To: Brian Eaton > > Cc: OAuth WG > > Sent: Tuesday, March 8, 2011 7:11 AM > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > Very strongly agree, repeat my suggestion to name the parameter > "oauth2_token". > > -- Justin > > On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: > > My two cents: > > > > We've already taken three user visible outages because the OAuth2 > spec > > reused the "oauth_token" parameter in a way that was not compatible > > with the OAuth1 spec. > > > > Luckily they were all caught before they caused serious damage. > > > > Generic parameter names are not useful. They lead to confused > > developers and confused code. If code needs to treat the values > > differently, the names should be different as well. > > > > Cheers, > > Brian > > > > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt > > wrote: > > > There was some discussion on the type for the authorization header > being > > > OAUTH / MAC / BEARER etc. Did we have a resolution? > > > As for section 2.2 and 2.3, should we not have a more neutral > solution as > > > well and use "authorization_token" instead of oauth_token. The > idea is that > > > the parameter corresponds to the authorization header and NOT the > value of > > > it. The value of such a parameter an be an encoded value that > corresponds to > > > the authorization header. For example: > > > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: > > > server.example.com > > > instead of > > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: > server.example.com > > > The concern is that if for some reason you switch to "MAC" tokens, > then you > > > have to change parameter names. Why not keep them consistent? > > > Apologies if this was already resolved. > > > Phil > > > phil.hunt@oracle.com > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --_000_C99BAEE5E033eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I hope this will be the = last time we define a query parameter for delivering what should be sent vi= a a request header field. Infringing on a service's namespace is always a b= ad idea, no matter what prefix we put next to it.

= EHL

From: = "William J. Mills" <wmills@yaho= o-inc.com>
Reply-To: "Wi= lliam J. Mills" <wmills@yahoo-in= c.com>
Date: Tue, 8 Mar = 2011 10:11:46 -0700
To: Justin = Richer <jricher@mitre.org>Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
<= br>
So = is a different namespace for each new mechanism right, or should a paramete= r be added to parallel the authorization scheme name?  Seems like it w= ould be clean to define oauth_scheme and use the same value as defined for = the auth scheme name.

From: Justin Richer <jricher@mitre.org>
To: William J. Mills <wmills= @yahoo-inc.com>
Cc:<= /b> Brian Eaton <beaton@google.com<= /a>>; OAuth WG <oauth@ietf.org&= gt;
Sent: Tuesday, Marc= h 8, 2011 8:41 AM
Subject:<= /b> Re: [OAUTH-WG] OAuth Bearer Token draft

I don't understa= nd this comment. If you're using query/form parameters,
there are no sch= emes involved in the process.

-- Justin


On Tue, 2011-03-= 08 at 11:27 -0500, William J. Mills wrote:
> A major difference is no= w there is a scheme name that is
> differentiating.  You no long= er have to parse the entire variable set
> to figure out what is goin= g on.  Now the scheme name determines
> things.  Now that w= e have schemes I don't see re-using parameter names
> as a problem.>
>
>
>
> ________________________________= ______________________________________
> From: Justin Richer <jrich= er@mitre.org>
> To: Brian Eaton <beaton@google.com>> Cc: OAuth WG <oauth@ietf.org>
> Sent: Tuesday, March 8, 201= 1 7:11 AM
> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
> =
> Very strongly agree, repeat my suggestion to name the parameter> "oauth2_token".
>
> -- Justin
>
> On Fri, 2= 011-02-25 at 14:49 -0500, Brian Eaton wrote:
> > My two cents:
= > >
> > We've already taken three user visible outages beca= use the OAuth2
> spec
> > reused the "oauth_token" parameter= in a way that was not compatible
> > with the OAuth1 spec.
>= ; >
> > Luckily they were all caught before they caused seriou= s damage.
> >
> > Generic parameter names are not useful.  They lead to confused
>= ; > developers and confused code.  If code needs to treat the value= s
> > differently, the names should be different as well.
> = >
> > Cheers,
> > Brian
> >
> > On= Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt <phil.hunt@oracle.com= >
> wrote:
> > > There was some discussion on the type= for the authorization header
> being
> > > OAUTH / MAC /= BEARER etc. Did we have a resolution?
> > > As for section 2.2= and 2.3, should we not have a more neutral
> solution as
> >= ; > well and use "authorization_token" instead of oauth_token. The
&g= t; idea is that
> > > the parameter corresponds to the authoriz= ation header and NOT the
> value of
> > > it. The value of such a parameter an be an encoded value that
> corresponds = to
> > > the authorization header.  For example:
> &= gt; > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Hos= t:
> > > server.example.com
> > > instead of
>= ; > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host:
> s= erver.example.com
> > > The concern is that if for some reason = you switch to "MAC" tokens,
> then you
> > > have to chan= ge parameter names. Why not keep them consistent?
> > > Apologi= es if this was already resolved.
> > > Phil
> > > <= a ymailto=3D"mailto:phil.hunt@oracle.com" href=3D"mailto:phil.hunt@oracle.c= om">phil.hunt@oracle.com
> > >
> > >
> &g= t; >
> > >
> > > _______________________________= ________________
> > > 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
>
= >
> _______________________________________________
> OAuth= mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listi= nfo/oauth
>
>
>
>




=

--_000_C99BAEE5E033eranhueniversecom_-- From wmills@yahoo-inc.com Tue Mar 8 10:45:03 2011 Return-Path: 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 606FF3A6906 for ; Tue, 8 Mar 2011 10:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 BsEZs9mlURuP for ; Tue, 8 Mar 2011 10:45:01 -0800 (PST) Received: from web121404.mail.ne1.yahoo.com (web121404.mail.ne1.yahoo.com [98.138.90.98]) by core3.amsl.com (Postfix) with SMTP id 083F23A68AF for ; Tue, 8 Mar 2011 10:44:51 -0800 (PST) Received: (qmail 62141 invoked by uid 60001); 8 Mar 2011 18:46:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1299609966; bh=TfogBNiV+vqAx+RRrLhiItWpiVPHiuiOB9v2or28Lww=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=a0f8qTxRWnk6m66HTWGaANdZ/X9jd7I8FYnts7oRm1fK79vHMR8R0F5oE/o8csTdVjdUIBT6fASNOCRYWoeW/MccM8TrXUBzkCzt/f+Vbj1olMkOBy+9B6+FOEsxGQaFcJxvOWyRgPmOlYM4wZdh93pfXpUSKcKmcAn44mV/tcM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=sATeRcG+4Qztv/d/QDYd/BK+DKl1bt4MQs84uWqckAw9fGwsSjdqj//TcLCuVru7a/q6TXjDCEjW15u1c4DfzV3mdrj8FRQtK1xf8tSpwDBOV7k/1NkTgaJthkMsiuv+KUTsV1qZp3Z8UimKcf0gEx1gQN+p9TtZbRO+4Ru7deQ=; Message-ID: <608482.61869.qm@web121404.mail.ne1.yahoo.com> X-YMail-OSG: JJ7kdBAVM1kBk420VIX0Cmq7tEpmeYFyezQf0wW5ckOrWqI OIt88CgVSzm78jeZWY_MFCKtpDY7U9Jmad3E3rpXASl5ti5Tv5d2UE8JUida 714d87jfWdNXm6tiaElr2qdSV1p19PQm5k0GQMyAGYf8rybtVa6y45zVqA8G tbBKQ8rh71G8MJ.d.iCT0WZ8iCbibx3FPPSVrJ9hiSYPVm93XmUynmgIXG.U m_weMIpv1QbYWjg96fOOB7l85OOp4c0.2wh1H5ULWU4bTSyRpoVEmSSlKjq1 sLeUzVqO.tp6NtBKKAyON6yKjeg-- Received: from [209.131.62.115] by web121404.mail.ne1.yahoo.com via HTTP; Tue, 08 Mar 2011 10:46:06 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.109.292656 Date: Tue, 8 Mar 2011 10:46:06 -0800 (PST) From: "William J. Mills" To: Eran Hammer-Lahav , Justin Richer MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-14006193-1299609966=:61869" Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:45:03 -0000 --0-14006193-1299609966=:61869 Content-Type: text/plain; charset=us-ascii Then a single extra reservation is preferable to N, yes? From: Eran Hammer-Lahav To: William J. Mills ; Justin Richer Cc: OAuth WG Sent: Tuesday, March 8, 2011 10:02 AM Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I hope this will be the last time we define a query parameter for delivering what should be sent via a request header field. Infringing on a service's namespace is always a bad idea, no matter what prefix we put next to it. EHL From: "William J. Mills" Reply-To: "William J. Mills" Date: Tue, 8 Mar 2011 10:11:46 -0700 To: Justin Richer Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft So is a different namespace for each new mechanism right, or should a parameter be added to parallel the authorization scheme name? Seems like it would be clean to define oauth_scheme and use the same value as defined for the auth scheme name. From: Justin Richer To: William J. Mills Cc: Brian Eaton ; OAuth WG Sent: Tuesday, March 8, 2011 8:41 AM Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I don't understand this comment. If you're using query/form parameters, there are no schemes involved in the process. -- Justin On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: > A major difference is now there is a scheme name that is > differentiating. You no longer have to parse the entire variable set > to figure out what is going on. Now the scheme name determines > things. Now that we have schemes I don't see re-using parameter names > as a problem. > > > > > ______________________________________________________________________ > From: Justin Richer > To: Brian Eaton > Cc: OAuth WG > Sent: Tuesday, March 8, 2011 7:11 AM > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > Very strongly agree, repeat my suggestion to name the parameter > "oauth2_token". > > -- Justin > > On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: > > My two cents: > > > > We've already taken three user visible outages because the OAuth2 > spec > > reused the "oauth_token" parameter in a way that was not compatible > > with the OAuth1 spec. > > > > Luckily they were all caught before they caused serious damage. > > > > Generic parameter names are not useful. They lead to confused > > developers and confused code. If code needs to treat the values > > differently, the names should be different as well. > > > > Cheers, > > Brian > > > > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt > wrote: > > > There was some discussion on the type for the authorization header > being > > > OAUTH / MAC / BEARER etc. Did we have a resolution? > > > As for section 2.2 and 2.3, should we not have a more neutral > solution as > > > well and use "authorization_token" instead of oauth_token. The > idea is that > > > the parameter corresponds to the authorization header and NOT the > value of > > > it. The value of such a parameter an be an encoded value that > corresponds to > > > the authorization header. For example: > > > GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host: > > > server.example.com > > > instead of > > > GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host: > server.example.com > > > The concern is that if for some reason you switch to "MAC" tokens, > then you > > > have to change parameter names. Why not keep them consistent? > > > Apologies if this was already resolved. > > > Phil > > > phil.hunt@oracle.com > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --0-14006193-1299609966=:61869 Content-Type: text/html; charset=us-ascii
Then a single extra reservation is preferable to N, yes?

From: Eran Hammer-Lahav <eran@hueniverse.com>
To: William J. Mills <wmills@yahoo-inc.com>; Justin Richer <jricher@mitre.org>
Cc: OAuth WG <oauth@ietf.org>
Sent: Tuesday, March 8, 2011 10:02 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

I hope this will be the last time we define a query parameter for delivering what should be sent via a request header field. Infringing on a service's namespace is always a bad idea, no matter what prefix we put next to it.

EHL

From: "William J. Mills" <wmills@yahoo-inc.com>
Reply-To: "William J. Mills" <wmills@yahoo-inc.com>
Date: Tue, 8 Mar 2011 10:11:46 -0700
To: Justin Richer <jricher@mitre.org>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

So is a different namespace for each new mechanism right, or should a parameter be added to parallel the authorization scheme name?  Seems like it would be clean to define oauth_scheme and use the same value as defined for the auth scheme name.

From: Justin Richer <jricher@mitre.org>
To: William J. Mills <wmills@yahoo-inc.com>
Cc: Brian Eaton <beaton@google.com>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, March 8, 2011 8:41 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

I don't understand this comment. If you're using query/form parameters,
there are no schemes involved in the process.

-- Justin


On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote:
> A major difference is now there is a scheme name that is
> differentiating.  You no longer have to parse the entire variable set
> to figure out what is going on.  Now the scheme name determines
> things.  Now that we have schemes I don't see re-using parameter names
> as a problem.
>
>
>
>
> ______________________________________________________________________
> From: Justin Richer <jricher@mitre.org>
> To: Brian Eaton <beaton@google.com>
> Cc: OAuth WG <oauth@ietf.org>
> Sent: Tuesday, March 8, 2011 7:11 AM
> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>
> Very strongly agree, repeat my suggestion to name the parameter
> "oauth2_token".
>
> -- Justin
>
> On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote:
> > My two cents:
> >
> > We've already taken three user visible outages because the OAuth2
> spec
> > reused the "oauth_token" parameter in a way that was not compatible
> > with the OAuth1 spec.
> >
> > Luckily they were all caught before they caused serious damage.
> >
> > Generic parameter names are not useful.  They lead to confused
> > developers and confused code.  If code needs to treat the values
> > differently, the names should be different as well.
> >
> > Cheers,
> > Brian
> >
> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt <phil.hunt@oracle.com>
> wrote:
> > > There was some discussion on the type for the authorization header
> being
> > > OAUTH / MAC / BEARER etc. Did we have a resolution?
> > > As for section 2.2 and 2.3, should we not have a more neutral
> solution as
> > > well and use "authorization_token" instead of oauth_token. The
> idea is that
> > > the parameter corresponds to the authorization header and NOT the
> value of
> > > it. The value of such a parameter an be an encoded value that
> corresponds to
> > > the authorization header.  For example:
> > > GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host:
> > > server.example.com
> > > instead of
> > > GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host:
> server.example.com
> > > The concern is that if for some reason you switch to "MAC" tokens,
> then you
> > > have to change parameter names. Why not keep them consistent?
> > > Apologies if this was already resolved.
> > > Phil
> > > phil.hunt@oracle.com
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>








--0-14006193-1299609966=:61869-- From eran@hueniverse.com Tue Mar 8 10:59:08 2011 Return-Path: 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 6BA9E3A69AC for ; Tue, 8 Mar 2011 10:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 wkFJgzEtU02V for ; Tue, 8 Mar 2011 10:59:06 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id CA74A3A69A0 for ; Tue, 8 Mar 2011 10:59:06 -0800 (PST) Received: (qmail 15685 invoked from network); 8 Mar 2011 19:00:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Mar 2011 19:00:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 8 Mar 2011 12:00:06 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Justin Richer Date: Tue, 8 Mar 2011 12:00:08 -0700 Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: AcvdwwluD/8BWZTyQH+nvycFFazKeQ== Message-ID: In-Reply-To: <608482.61869.qm@web121404.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C99BBB55E058eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 18:59:08 -0000 --_000_C99BBB55E058eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If there was an actual reason to think more of these will be needed. The only attractive feature of bearer tokens are their simplicity. There ca= n be nothing simpler. And as such, sending them over in a query parameter h= as obvious benefits inline with this simplicity (with the well-known securi= ty issues that must be taken into consideration). The reasons for supporting query GET parameters and body POST parameters ar= e ease of use and client limitations in accessing the authorization header.= The second is pretty much a non-issue at this point (it was 3 years ago wh= en 1.0 was released). Every other token type is going to be more complex and will require more pa= rameters than just the token. In such an environment, a single parameter na= me will not be helpful. Using a parameter prefix might be, but it just gets= ugly (oauth_bearer_token, oauth_something_signature, etc.). My point is that instead of building yet another extension point, we should= come up with a reasonable solution for bearer tokens and simply state that= we do not expect any other token type to use this method. That all other t= oken types should use an HTTP header, or a special multi-part body. EHL From: "William J. Mills" = > Reply-To: "William J. Mills" > Date: Tue, 8 Mar 2011 11:46:06 -0700 To: Eran Hammer-lahav >, Ju= stin Richer > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft Then a single extra reservation is preferable to N, yes? From: Eran Hammer-Lahav > To: William J. Mills >; J= ustin Richer > Cc: OAuth WG > Sent: Tuesday, March 8, 2011 10:02 AM Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I hope this will be the last time we define a query parameter for deliverin= g what should be sent via a request header field. Infringing on a service's= namespace is always a bad idea, no matter what prefix we put next to it. EHL From: "William J. Mills" = > Reply-To: "William J. Mills" > Date: Tue, 8 Mar 2011 10:11:46 -0700 To: Justin Richer > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft So is a different namespace for each new mechanism right, or should a param= eter be added to parallel the authorization scheme name? Seems like it wou= ld be clean to define oauth_scheme and use the same value as defined for th= e auth scheme name. From: Justin Richer > To: William J. Mills > Cc: Brian Eaton >; OAuth WG > Sent: Tuesday, March 8, 2011 8:41 AM Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I don't understand this comment. If you're using query/form parameters, there are no schemes involved in the process. -- Justin On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: > A major difference is now there is a scheme name that is > differentiating. You no longer have to parse the entire variable set > to figure out what is going on. Now the scheme name determines > things. Now that we have schemes I don't see re-using parameter names > as a problem. > > > > > ______________________________________________________________________ > From: Justin Richer > > To: Brian Eaton > > Cc: OAuth WG > > Sent: Tuesday, March 8, 2011 7:11 AM > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > Very strongly agree, repeat my suggestion to name the parameter > "oauth2_token". > > -- Justin > > On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: > > My two cents: > > > > We've already taken three user visible outages because the OAuth2 > spec > > reused the "oauth_token" parameter in a way that was not compatible > > with the OAuth1 spec. > > > > Luckily they were all caught before they caused serious damage. > > > > Generic parameter names are not useful. They lead to confused > > developers and confused code. If code needs to treat the values > > differently, the names should be different as well. > > > > Cheers, > > Brian > > > > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt > > wrote: > > > There was some discussion on the type for the authorization header > being > > > OAUTH / MAC / BEARER etc. Did we have a resolution? > > > As for section 2.2 and 2.3, should we not have a more neutral > solution as > > > well and use "authorization_token" instead of oauth_token. The > idea is that > > > the parameter corresponds to the authorization header and NOT the > value of > > > it. The value of such a parameter an be an encoded value that > corresponds to > > > the authorization header. For example: > > > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: > > > server.example.com > > > instead of > > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: > server.example.com > > > The concern is that if for some reason you switch to "MAC" tokens, > then you > > > have to change parameter names. Why not keep them consistent? > > > Apologies if this was already resolved. > > > Phil > > > phil.hunt@oracle.com > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --_000_C99BBB55E058eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If there was an actual r= eason to think more of these will be needed.

The o= nly attractive feature of bearer tokens are their simplicity. There can be = nothing simpler. And as such, sending them over in a query parameter has ob= vious benefits inline with this simplicity (with the well-known security is= sues that must be taken into consideration).

The r= easons for supporting query GET parameters and body POST parameters are eas= e of use and client limitations in accessing the authorization header. The = second is pretty much a non-issue at this point (it was 3 years ago when 1.= 0 was released).

Every other token type is going t= o be more complex and will require more parameters than just the token. In = such an environment, a single parameter name will not be helpful. Using a p= arameter prefix might be, but it just gets ugly (oauth_bearer_token, oauth_= something_signature, etc.).

My point is that inste= ad of building yet another extension point, we should come up with a reason= able solution for bearer tokens and simply state that we do not expect any = other token type to use this method. That all other token types should use = an HTTP header, or a special multi-part body.

EHL<= /div>



From: "William J. Mills" <wmills@yahoo-inc.com>
Reply-To: "William J. Mills" <wmills@yahoo-inc.com>
Date: Tue, 8 Mar 2011 11:46:06 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>, Justin Richer <jricher@mitre.org>
Cc: OAuth WG <oauth@ietf.org<= /a>>
Subject: Re: [OAUTH-WG]= OAuth Bearer Token draft

Then a single extra reservation is preferable to= N, yes?

<= span style=3D"font-weight: bold;">From: Eran Hammer-Lahav <eran@hueniverse.com>
To: William J. Mills <wmills@yahoo-inc.com>; Justin Riche= r <jricher@mitre.org>
= Cc: OAuth WG <oauth@ietf.org>
Sent: Tuesday, March 8, 2011 10:02 AM
Subject: Re: [OAUTH-WG] OAuth Bearer T= oken draft

I hope this will b= e the last time we define a query parameter for delivering what should be s= ent via a request header field. Infringing on a service's namespace is alwa= ys a bad idea, no matter what prefix we put next to it.

EHL

From: "Wi= lliam J. Mills" <wmills@yahoo-in= c.com>
Reply-To: "Will= iam J. Mills" <wmills@yahoo-inc.= com>
Date: Tue, 8 Mar = 2011 10:11:46 -0700
To: Justi= n Richer <jricher@mitre.org>Cc: OAuth WG <oauth@ietf.org>
= Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

=
So is a di= fferent namespace for each new mechanism right, or should a parameter be added to parallel the authorization scheme name?&nbs= p; Seems like it would be clean to define oauth_scheme and use the same val= ue as defined for the auth scheme name.

From: Jus= tin Richer <jricher@mitre.org><= br>To: William J. Mills &l= t;wmills@yahoo-inc.com>
<= b>Cc: Brian Eaton <be= aton@google.com>; OAuth WG <oauth@iet= f.org>
Sent: Tue= sday, March 8, 2011 8:41 AM
Subjec= t: Re: [OAUTH-WG] OAuth Bearer Token draft

I don'= t understand this comment. If you're using query/form parameters,
there = are no schemes involved in the process.

-- Justin


On Tue= , 2011-03-08 at 11:27 -0500, William J. Mills wrote:
> A major differ= ence is now there is a scheme name that is
> differentiating.  Y= ou no longer have to parse the entire variable set
> to figure out wh= at is going on.  Now the scheme name determines
> things.  = Now that we have schemes I don't see re-using parameter names
> as a problem.>
>
>
>
> _________________________________= _____________________________________
> From: Justin Richer <jricher@mitre.org>
> To: Brian E= aton <beaton@google.com>
>= ; Cc: OAuth WG <oauth@ietf.org>
&g= t; Sent: Tuesday, March 8, 2011 7:11 AM
> Subject: Re: [OAUTH-WG] OAu= th Bearer Token draft
>
> Very strongly agree, repeat my sugge= stion to name the parameter
> "oauth2_token".
>
> -- Jus= tin
>
> On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote:<= br>> > My two cents:
> >
> > We've already taken three user visib= le outages because the OAuth2
> spec
> > reused the "oauth_t= oken" parameter in a way that was not compatible
> > with the OAut= h1 spec.
> >
> > Luckily they were all caught before the= y caused serious damage.
> >
> > Generic parameter names are not useful.  They lead to confused
>= ; > developers and confused code.  If code needs to treat the value= s
> > differently, the names should be different as well.
> = >
> > Cheers,
> > Brian
> >
> > On= Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt <phil.hunt@oracle.com>
> wrote:
> > > = There was some discussion on the type for the authorization header
> = being
> > > OAUTH / MAC / BEARER etc. Did we have a resolution?=
> > > As for section 2.2 and 2.3, should we not have a more ne= utral
> solution as
> > > well and use "authorization_tok= en" instead of oauth_token. The
> idea is that
> > > the = parameter corresponds to the authorization header and NOT the
> value of
> > > it. The value of such a parameter an be an encoded value that
> corresponds = to
> > > the authorization header.  For example:
> &= gt; > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Hos= t:
> > > server.example.com
> > > instead of
>= ; > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host:
> s= erver.example.com
> > > The concern is that if for some reason = you switch to "MAC" tokens,
> then you
> > > have to chan= ge parameter names. Why not keep them consistent?
> > > Apologi= es if this was already resolved.
> > > Phil
> > > <= a rel=3D"nofollow" ymailto=3D"mailto:phil.hunt@oracle.com" target=3D"_blank= " href=3D"mailto:phil.hunt@oracle.com">phil.hunt@oracle.com
> >= ; >
> > >
> > >
> > >
> > &= gt; _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org<= /a>
> > > https://www.ietf.org/mailman/listinfo= /oauth
> > >
> > >
> > _______________= ________________________________
> > OAuth mailing list
> &g= t; OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
&g= t; _______________________________________________
> OAuth mailing li= st
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> >
>








--_000_C99BBB55E058eranhueniversecom_-- From skylar@kiva.org Tue Mar 8 11:21:14 2011 Return-Path: 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 0FEAD3A693A for ; Tue, 8 Mar 2011 11:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 zdzfP28rzqbt for ; Tue, 8 Mar 2011 11:21:09 -0800 (PST) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by core3.amsl.com (Postfix) with SMTP id 9A77A3A680F for ; Tue, 8 Mar 2011 11:21:07 -0800 (PST) Received: from source ([74.125.83.50]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKTXaB7l0NarSqpvng9FYGpEFA6b55/8gl@postini.com; Tue, 08 Mar 2011 11:22:24 PST Received: by mail-gw0-f50.google.com with SMTP id a20so3288582gwa.9 for ; Tue, 08 Mar 2011 11:22:22 -0800 (PST) Received: by 10.236.182.233 with SMTP id o69mr5759723yhm.30.1299612140883; Tue, 08 Mar 2011 11:22:20 -0800 (PST) Received: from [10.0.1.4] (c-24-5-80-5.hsd1.ca.comcast.net [24.5.80.5]) by mx.google.com with ESMTPS id g63sm704807yhd.15.2011.03.08.11.22.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 11:22:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <1299594363.8411.8.camel@ground> Date: Tue, 8 Mar 2011 11:22:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7D0E0886-92B6-4386-94C2-6CC5AF553E7B@kiva.org> References: , <4D74ACB8.3040707@lodderstedt.net> <1299594363.8411.8.camel@ground> To: Justin Richer X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 19:21:14 -0000 To clarify, when I say "can keep secrets" I mean "can be packed/shipped = with secrets." Good point. I assume all OAuth clients can keep secrets in the more general sense = you implied. Otherwise, even bearer tokens would be useless. On Mar 8, 2011, at 6:26 AM, Justin Richer wrote: > Also, there's a big difference between "can keep secrets" and "can be > packed/shipped with secrets". Many native apps fit into the former > category but not the latter, which makes storage of refresh tokens and > other long-term credentials reasonable, but not server-issued client > secrets. >=20 > -- Justin >=20 > On Mon, 2011-03-07 at 14:37 -0500, Skylar Woodward wrote: >> Justin has well stated my view on this. Folks here have explained = how the flows can work for (or doesn't prohibit) a native app, but it = also seems clear that new readers don't pick up how native apps fit into = the flow in a 1st or 2nd pass. >>=20 >> So, in short, I agree with Brian's suggestion of (1) removing choice = references to native apps, and (2) as a further (and preferred) step, a = better preamble (possibly with further supporting edits) on the role of = native apps. It seems Justin and Torsten are suggesting the same. >>=20 >> To go further than step 1 I agree we need some discussion on the = story for native apps. For my part, here's how I see them fitting in: >>=20 >> - The general assumption is that Native apps can't keep secrets. This = is mostly true except... >> - Native apps with secured distribution (eg, controlled access by = corporate IT departments who also can modify app preferences w/ the = provider) can claim the apps keep secrets. (A sample use case are Kiva = field partners who develop simple enterprise apps for use inside a = firewall). >> - In truth, the question of secrets or no secrets (can authenticate = or spoofable) is of primary importance for choosing a flow. >> - In the common case, Native apps without secrets, an implicit flow = or auth-code flow can be used. If an auth-code flow is used, there = should be no client authentication. Alternatively, providers may = instruct such clients to authenticate with an empty secret (since such = clients should never be issued secrets to begin with). >> - In the uncommon case of native apps who can keep secrets, an = implicit flow cannot be used. The app must present credentials which = requires an auth-code (or other) flow. >> - I think there should be some note added to the auth-code flow on = how a native app chooses and makes use of a redirect_uri. This was = present in draft 10 and was (i think) key to understanding the auth-code = story for native apps. >>=20 >> I do not have strong opinions on the client-assertion flows for = native apps nor the issuance of refresh tokens in an implicit flow. It = does seem that some find it important to be able to issue refresh tokens = to clients without secrets. I don't see a good argument to restrict this = from a policy point of view (rather it seems more of issue of mechanics = and/or fragment parsing), but it does seem the policy should be = consistent. That is, if as an issue of policy, refresh tokens are not = issued to apps without credentials, the policy applies for auth-code = flows or implicit flows. >>=20 >> skylar >>=20 >>=20 >> On Mar 7, 2011, at 5:54 AM, Richer, Justin P. wrote: >>=20 >>> Agree with Torsten - having the mention in just that one place = doesn't make sense. It should be removed or replicated throughout, but I = think we might want a paragraph addressing native apps more deeply in = the introduction. We don't want to give the (incorrect) impression that = the implicit flow is the only or even preferred flow for native apps. >>>=20 >>> -- Justin >>> ________________________________________ >>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of = Torsten Lodderstedt [torsten@lodderstedt.net] >>> Sent: Monday, March 07, 2011 5:00 AM >>> To: Dick Hardt >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] slightly alternative preamble (was: Re: = Draft -12 feedback deadline) >>>=20 >>> Hi Dick, >>>=20 >>> I agree with you, the OAuth standard should offer clear patterns for >>> native apps. >>>=20 >>> All native apps I'm familiar with use the authorization code, which = is >>> because of its support for refresh tokens. But the current text of = the >>> spec only suggests to use the implict grant flow to implement native >>> apps whereas previous versions mentioned authz code and password = flow as >>> well. So in my opinion, the text is misleading to developers. And = that's >>> not only a feeling since I already meet people, which have been >>> misguided :-(. >>>=20 >>> I think at least the misleading words shall be removed. Better would = be >>> to come up with a consensus after a discussion in the group. >>>=20 >>> regards, >>> Torsten. >>>=20 >>> Am 06.03.2011 23:12, schrieb Dick Hardt: >>>> -1 >>>>=20 >>>> Many sites are using OAuth (or something like it) in native apps = now. >>>>=20 >>>> One of the objectives of having a standard is to bring best = practices and standardization to how to solve a problem rather than "a = million freakin unique snowflakes" where developers have to learn and = code each mechanism to enable authorization to a native app. Brian's = suggested wording may make sense in the context of where OAuth is now -- = but it signals that the WG has been unable to solve what I think many = viewed as an important aspect of the WG. >>>>=20 >>>> fwiw: I think a number of important constituents have opted out of = the dialogue. An unfortunate situation. >>>>=20 >>>> On 2011-03-02, at 6:05 AM, Brian Campbell wrote: >>>>=20 >>>>> I propose that the "or native applications" text be dropped from = the >>>>> first paragraph in section 4.2 Implicit Grant [1]. >>>>>=20 >>>>> There is clearly some disagreement about what is most appropriate = for >>>>> mobile/native applications and many, including myself, don't feel = that >>>>> the implicit grant works well to support them (due to the lack of = a >>>>> refresh token and need to repeat the authorization steps). I >>>>> understand that the text in section 4 is non-normative, however, I >>>>> feel that the mention of native apps in 4.2 biases thinking in a >>>>> particular way (it's already led to one lengthy internal = discussion >>>>> that I'd rather not have again and again). I believe it'd be more >>>>> appropriate for the draft to remain silent on how native apps = should >>>>> acquire tokens and leave it up to implementations/deployments to >>>>> decide (or an extension draft as Marius has proposed). >>>>>=20 >>>>> The "or native applications" text in is also somewhat inconsistent >>>>> with the text in the following sentence that talks about the >>>>> authentication of the client being based on the user-agent's >>>>> same-origin policy. >>>>>=20 >>>>> Removing those three words is a small change but one that I feel = would >>>>> be beneficial on a number of fronts. >>>>>=20 >>>>> Thanks, >>>>> Brian >>>>>=20 >>>>>=20 >>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-4.2 >>>>>=20 >>>>> On Wed, Feb 16, 2011 at 2:57 PM, Eran = Hammer-Lahav wrote: >>>>>> Feel free to propose alternative preamble for the implicit and = authorization code sections, describing the characteristics of what they = are good for. It should fit in a single paragraph. Such a proposal would = fit right in with last call feedback to -13. >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>>> Sent: Wednesday, February 16, 2011 1:39 PM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: Brian Campbell; OAuth WG >>>>>>> Subject: Re: [OAUTH-WG] Draft -12 feedback deadline >>>>>>>=20 >>>>>>> On Wed, Feb 16, 2011 at 12:28 PM, Eran Hammer-Lahav >>>>>>> wrote: >>>>>>>> The reason why we don't return a refresh token in the implicit = grant is >>>>>>> exactly because there is no client authentication... >>>>>>>=20 >>>>>>> Not sure that's the main reason. AFAIK it is because the = response is sent >>>>>>> through the user-agent and it could leak. >>>>>>>=20 >>>>>>>=20 >>>>>>>> These are all well-balanced flows with specific security = properties. If you >>>>>>> need something else, even if it is just a tweak, it must be = considered a >>>>>>> different flow. That doesn't mean you need to register a new = grant type, just >>>>>>> that you are dealing with different implementation details = unique to your >>>>>>> server. >>>>>>>=20 >>>>>>> The Authorization Code flow, with no client secret, is perfectly = fine for Native >>>>>>> Apps IMO. >>>>>>>=20 >>>>>>> Marius >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >>=20 >=20 >=20 From doog@google.com Tue Mar 8 13:50:42 2011 Return-Path: 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 890E43A659B for ; Tue, 8 Mar 2011 13:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 kP+4PHOW6Nx0 for ; Tue, 8 Mar 2011 13:50:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A4D143A63C9 for ; Tue, 8 Mar 2011 13:50:40 -0800 (PST) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p28Lptsl010230 for ; Tue, 8 Mar 2011 13:51:55 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299621115; bh=1HKUnupylag7bTmlUC52Xg/a4M8=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=I/mH3WZSUX3+8e/5mm4xk8b0iUAe+misOEUiZXiZSAYcoF2NqkBmMGqNBx1OwRtPg VLXMZh10bLGxFPWuSJmHw== Received: from gwj22 (gwj22.prod.google.com [10.200.10.22]) by hpaq5.eem.corp.google.com with ESMTP id p28LprtA010368 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 13:51:54 -0800 Received: by gwj22 with SMTP id 22so2599163gwj.13 for ; Tue, 08 Mar 2011 13:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=nFn/fQuY7q9sx0cMVl48+62odG4ornDNjhgIEzk6zmQ=; b=n1QwBNuJrOkpzjXXb9E6XSzQNCyXpA5dWHeom4tGtkNnSaqI5i+WcX5A3RqwNtXcCL Q+gBwyoxsVqpH/6gHhfw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=fmfQKUobd00k/PfDpIjIaMpkvKMt/a1ic2ygfsgnCy1vOJ2a6S/d1KWUwFlajUxA1O YgUAOefTK+3XSRoMG3DQ== Received: by 10.150.144.12 with SMTP id r12mr4081724ybd.216.1299621113202; Tue, 08 Mar 2011 13:51:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.151.79.15 with HTTP; Tue, 8 Mar 2011 13:51:33 -0800 (PST) From: Doug Kramer Date: Tue, 8 Mar 2011 13:51:33 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cd56aa8cb8b89049dff9e7d X-System-Of-Record: true Subject: [OAUTH-WG] Typo on 2.0 home page X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 22:08:52 -0000 --000e0cd56aa8cb8b89049dff9e7d Content-Type: text/plain; charset=ISO-8859-1 Your 2.0 home page http://oauth.net/2/ has a typo: "is can" The latest version of the spec is can be found at: -Doug --000e0cd56aa8cb8b89049dff9e7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Your 2.0 home page http://oauth.net/2/ = has a typo: "is can"

<= span class=3D"Apple-style-span" style=3D"color: rgb(30, 37, 13); font-famil= y: 'Lucida Grande', Calibri, Arial, sans-serif; font-size: 14px; li= ne-height: 21px; ">The latest version of the spec is can be fo= und at:

-Doug
--000e0cd56aa8cb8b89049dff9e7d-- From fcorella@pomcor.com Tue Mar 8 14:28:41 2011 Return-Path: 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 082503A677C for ; Tue, 8 Mar 2011 14:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 QJ8FSuiKVsIf for ; Tue, 8 Mar 2011 14:28:39 -0800 (PST) Received: from nm3.bullet.mail.ac4.yahoo.com (nm3.bullet.mail.ac4.yahoo.com [98.139.52.200]) by core3.amsl.com (Postfix) with SMTP id 194433A6774 for ; Tue, 8 Mar 2011 14:28:39 -0800 (PST) Received: from [98.139.52.194] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 22:29:51 -0000 Received: from [98.139.52.151] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 22:29:51 -0000 Received: from [127.0.0.1] by omp1034.mail.ac4.yahoo.com with NNFMP; 08 Mar 2011 22:29:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 690298.75390.bm@omp1034.mail.ac4.yahoo.com Received: (qmail 28893 invoked by uid 60001); 8 Mar 2011 22:29:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299623391; bh=GHzu5onyH0wZXJlccLttUuXIp3flyVuQobwK16mGfzs=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3r2LFlf3JP1ggBFLPQpC8oiaULXXkHgzlPFrJY175XTszC8UkSVsFlIJqCyNN4zE4AURE3UgzffC+GRrlL6SaKGq0AZWf2u3FbCFykBcfl355X9PRFNEzVk+8hOUXoO9RsuQC8RD2KgrwfLSfcL0jiFZS/47J+nWz5f5EYv+nZc= Message-ID: <561716.97093.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: bqsO7DIVM1lvtUNunHxwGys2ed0LYAT5BtP30_j1F.xDcDc fkYV.aGwFN0tUjCLOVOCGZmRByrmIa6dvEOopfELJgi.ANqA5QhSd0AfqgAt Mr9SRGRMu6_1loIAYEXmNyQAY6q6CM.LUTl47_VcB_7PHgNzEyx.CCnpBRcN 3IyvS8..5s_X9OdhVd3EJaYAd28eHk7ZDH7d3FVlrV7LpNpryK6RWO21CzVa zdAef6AoP2miiL_9TY_R1PXwESqdW8WNNL0gH_pgStoeS8wONd1gD.cS5PAO 2aaOJna7bvzbGOfRf.mJn2RoDjXUTGvYItpH9dIPvH1dg18..SqaGP.t3kPh 8CPQQ Received: from [67.91.91.101] by web55801.mail.re3.yahoo.com via HTTP; Tue, 08 Mar 2011 14:29:51 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.295617 Date: Tue, 8 Mar 2011 14:29:51 -0800 (PST) From: Francisco Corella To: OAuth WG , Hannes Tschofenig In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-604205700-1299623391=:97093" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 22:28:41 -0000 --0-604205700-1299623391=:97093 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In my opinion the protocol has serious problems. The authorization code is a credential that provides access to protected resources via the client, as well as user authentication when OAuth is used for social login.=A0 If an attacker observes or intercepts the authorization code, the attacker can present the code to the client, use the client to gain access to the user's protected resources, and log in to the client impersonating the user.=A0 Therefore the authorization code cannot be sent to the client without TLS protection.=A0 The protocol must require the redirect_uri to use the https scheme.=A0 The redirect_uri is shown as an https URI in the examples, but examples are not enough.=A0 If TLS is not required, implementations may use http.=A0 At this time the Facebook developer documentation shows http rather than https in its examples, and implementations seem to use http, as can be seen by searching the Web for "oauth redirect_uri". The protocol has the same well-known vulnerability to phishing attacks as OpenID.=A0 The attack on OpenID described by Ben Laurie in http://www.links.org/?p=3D187 is equally applicable to this protocol. The protocol should require the use of TLS at the authorization endpoint; without it, the user is defenseless against the attack.=A0 The protocol should also require the user to be already logged in at the authorization server, so that the server will not ask for credentials. If implementors take no precautions, the protocol is vulnerable to Login CSRF attacks.=A0 Adam Barth confirmed this in a message to the IETF websec mailing list: > Last time I looked into Login CSRF issues with > OAuth, the protocol had a large problem and every implementation I > experimented with was trivially vulnerable. A countermeasure against Login CSRF must be provided in the security considerations section.=A0 The security considerations section should also suggest countermeasures against DOS attacks.=A0 But the section is not written yet.=A0 I would think that the absence of a security considerations section in and of itself means that the protocol is not ready. I also must point out the danger to the Web posed by a protocol that is used for social login and requires registration.=A0 Millions of Web applications already use Facebook for social login.=A0 If social login becomes a de facto standard for user authentication, Web applications will have to support login with Facebook just to be able to authenticate their users.=A0 If that requires registration, then Facebook will have the power to disable any Web application by revoking its registration.=A0 That would be bad for all parties involved, including Facebook, which would then face regulation by the governments of many countries. Francisco --- On Wed, 3/2/11, Hannes Tschofenig wrote: From: Hannes Tschofenig Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt To: "OAuth WG" Date: Wednesday, March 2, 2011, 7:32 AM This is a Last Call for comments on=20 http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt Please have your comments in no later than March 16. Do remember to send a note in if you have read the document and have no=20 other comments other than "its ready to go" - we need those as much as we n= eed "I found a problem". Thanks! Hannes & Blaine _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0-604205700-1299623391=:97093 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In my opinion the protocol has serious proble= ms.

The authorization code is a credential that provides access toprotected resources via the client, as well as user authentication
whe= n OAuth is used for social login.  If an attacker observes or
inter= cepts the authorization code, the attacker can present the code
to the c= lient, use the client to gain access to the user's protected
resources, = and log in to the client impersonating the user.  Therefore
the aut= horization code cannot be sent to the client without TLS
protection.&nbs= p; The protocol must require the redirect_uri to use the
https scheme.&n= bsp; The redirect_uri is shown as an https URI in the
examples, but exam= ples are not enough.  If TLS is not required,
implementations may u= se http.  At this time the Facebook developer
documentation shows h= ttp rather than https in its examples, and
implementations seem to use http= , as can be seen by searching the Web
for "oauth redirect_uri".

T= he protocol has the same well-known vulnerability to phishing attacks
as= OpenID.  The attack on OpenID described by Ben Laurie in
http://ww= w.links.org/?p=3D187 is equally applicable to this protocol.
The protoco= l should require the use of TLS at the authorization
endpoint; without i= t, the user is defenseless against the attack.  The
protocol should= also require the user to be already logged in at the
authorization serv= er, so that the server will not ask for credentials.

If implementors= take no precautions, the protocol is vulnerable to
Login CSRF attacks.&= nbsp; Adam Barth confirmed this in a message to the
IETF websec mailing = list:

> Last time I looked into Login CSRF issues with
> OA= uth, the protocol had a large problem and every implementation I
> experimented with was trivially vulnerable.

A countermeas= ure against Login CSRF must be provided in the security
considerations s= ection.  The security considerations section should
also suggest co= untermeasures against DOS attacks.  But the section is
not written = yet.  I would think that the absence of a security
considerations s= ection in and of itself means that the protocol is not
ready.

I a= lso must point out the danger to the Web posed by a protocol that
is use= d for social login and requires registration.  Millions of Web
appl= ications already use Facebook for social login.  If social login
be= comes a de facto standard for user authentication, Web applications
will= have to support login with Facebook just to be able to
authenticate the= ir users.  If that requires registration, then
Facebook will have t= he power to disable any Web application by
revoking its registration.  That would be bad for all parties
involved, includi= ng Facebook, which would then face regulation by the
governments of many= countries.

Francisco

--- On Wed, 3/2/11, Hannes Tschofeni= g <hannes.tschofenig@gmx.net> wrote:

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Su= bject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "OAuth WG" <= oauth@ietf.org>
Date: Wednesday, March 2, 2011, 7:32 AM

This is a Last Call for comments on

http://= www.ietf.org/id/draft-ietf-oauth-v2-13.txt

Please have your comm= ents in no later than March 16.

Do remember to send a note in if you= have read the document and have no
other comments other than "its read= y to go" - we need those as much as we need "I found a problem".

Than= ks!
Hannes & Blaine

_________________________________________= ______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
--0-604205700-1299623391=:97093-- From jricher@mitre.org Tue Mar 8 15:49:02 2011 Return-Path: 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 02CF63A67D2 for ; Tue, 8 Mar 2011 15:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 U3iSlZAGYgMo for ; Tue, 8 Mar 2011 15:49:01 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id DFE913A67D1 for ; Tue, 8 Mar 2011 15:49:00 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A57F121B0BAB; Tue, 8 Mar 2011 18:50:15 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9CE2C21B071D; Tue, 8 Mar 2011 18:50:15 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 8 Mar 2011 18:50:15 -0500 From: "Richer, Justin P." To: Eran Hammer-Lahav , "William J. Mills" Date: Tue, 8 Mar 2011 18:48:30 -0500 Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: AcvduwDXv+NbJ5HCQHWeM0W1EqQ/HAAMFNXm Message-ID: References: <836580.97993.qm@web121404.mail.ne1.yahoo.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:49:02 -0000 Except that we're also infringing on service provider namespaces for our ot= her endpoints as well. Not every service provider can or will create a pris= tine endpoint for tokens or authorizations, but this working group has had = no problems putting all kinds of parameters into that space. Unless we want= to say that we can't use query or form parameters in specifications ever a= gain, this argument doesn't really hold up. -- Justin ________________________________________ From: Eran Hammer-Lahav [eran@hueniverse.com] Sent: Tuesday, March 08, 2011 1:02 PM To: William J. Mills; Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I hope this will be the last time we define a query parameter for deliverin= g what should be sent via a request header field. Infringing on a service's= namespace is always a bad idea, no matter what prefix we put next to it. EHL From: "William J. Mills" = > Reply-To: "William J. Mills" > Date: Tue, 8 Mar 2011 10:11:46 -0700 To: Justin Richer > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft So is a different namespace for each new mechanism right, or should a param= eter be added to parallel the authorization scheme name? Seems like it wou= ld be clean to define oauth_scheme and use the same value as defined for th= e auth scheme name. ________________________________ From: Justin Richer > To: William J. Mills > Cc: Brian Eaton >; OAuth WG > Sent: Tuesday, March 8, 2011 8:41 AM Subject: Re: [OAUTH-WG] OAuth Bearer Token draft I don't understand this comment. If you're using query/form parameters, there are no schemes involved in the process. -- Justin On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: > A major difference is now there is a scheme name that is > differentiating. You no longer have to parse the entire variable set > to figure out what is going on. Now the scheme name determines > things. Now that we have schemes I don't see re-using parameter names > as a problem. > > > > > ______________________________________________________________________ > From: Justin Richer > > To: Brian Eaton > > Cc: OAuth WG > > Sent: Tuesday, March 8, 2011 7:11 AM > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > Very strongly agree, repeat my suggestion to name the parameter > "oauth2_token". > > -- Justin > > On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: > > My two cents: > > > > We've already taken three user visible outages because the OAuth2 > spec > > reused the "oauth_token" parameter in a way that was not compatible > > with the OAuth1 spec. > > > > Luckily they were all caught before they caused serious damage. > > > > Generic parameter names are not useful. They lead to confused > > developers and confused code. If code needs to treat the values > > differently, the names should be different as well. > > > > Cheers, > > Brian > > > > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt > > wrote: > > > There was some discussion on the type for the authorization header > being > > > OAUTH / MAC / BEARER etc. Did we have a resolution? > > > As for section 2.2 and 2.3, should we not have a more neutral > solution as > > > well and use "authorization_token" instead of oauth_token. The > idea is that > > > the parameter corresponds to the authorization header and NOT the > value of > > > it. The value of such a parameter an be an encoded value that > corresponds to > > > the authorization header. For example: > > > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: > > > server.example.com > > > instead of > > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: > server.example.com > > > The concern is that if for some reason you switch to "MAC" tokens, > then you > > > have to change parameter names. Why not keep them consistent? > > > Apologies if this was already resolved. > > > Phil > > > phil.hunt@oracle.com > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > From eran@hueniverse.com Tue Mar 8 16:07:06 2011 Return-Path: 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 236F43A67E6 for ; Tue, 8 Mar 2011 16:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 PkuAOvAtT538 for ; Tue, 8 Mar 2011 16:07:05 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 029C43A67E3 for ; Tue, 8 Mar 2011 16:07:04 -0800 (PST) Received: (qmail 12890 invoked from network); 9 Mar 2011 00:08:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Mar 2011 00:08:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 8 Mar 2011 17:08:11 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." , "William J. Mills" Date: Tue, 8 Mar 2011 17:08:10 -0700 Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: Acvd7hQyUdd8tgiGQuS8mlyfqymhRw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 00:07:06 -0000 No. There is a huge difference between adding parameters to protected resources and defining parameter for OAuth specific endpoints (which may create conflicts with existing frameworks). One is an invasion of the provider's namespace where OAuth has no business messing around. The other is a potential deployment issue. EHL On 3/8/11 3:48 PM, "Richer, Justin P." wrote: >Except that we're also infringing on service provider namespaces for our >other endpoints as well. Not every service provider can or will create a >pristine endpoint for tokens or authorizations, but this working group >has had no problems putting all kinds of parameters into that space. >Unless we want to say that we can't use query or form parameters in >specifications ever again, this argument doesn't really hold up. > > -- Justin >________________________________________ >From: Eran Hammer-Lahav [eran@hueniverse.com] >Sent: Tuesday, March 08, 2011 1:02 PM >To: William J. Mills; Richer, Justin P. >Cc: OAuth WG >Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > >I hope this will be the last time we define a query parameter for >delivering what should be sent via a request header field. Infringing on >a service's namespace is always a bad idea, no matter what prefix we put >next to it. > >EHL > >From: "William J. Mills" >> >Reply-To: "William J. Mills" >> >Date: Tue, 8 Mar 2011 10:11:46 -0700 >To: Justin Richer > >Cc: OAuth WG > >Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > >So is a different namespace for each new mechanism right, or should a >parameter be added to parallel the authorization scheme name? Seems like >it would be clean to define oauth_scheme and use the same value as >defined for the auth scheme name. > >________________________________ >From: Justin Richer > >To: William J. Mills > >Cc: Brian Eaton >; OAuth WG >> >Sent: Tuesday, March 8, 2011 8:41 AM >Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > >I don't understand this comment. If you're using query/form parameters, >there are no schemes involved in the process. > >-- Justin > > >On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: >> A major difference is now there is a scheme name that is >> differentiating. You no longer have to parse the entire variable set >> to figure out what is going on. Now the scheme name determines >> things. Now that we have schemes I don't see re-using parameter names >> as a problem. >> >> >> >> >> ______________________________________________________________________ >> From: Justin Richer > >> To: Brian Eaton > >> Cc: OAuth WG > >> Sent: Tuesday, March 8, 2011 7:11 AM >> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >> >> Very strongly agree, repeat my suggestion to name the parameter >> "oauth2_token". >> >> -- Justin >> >> On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: >> > My two cents: >> > >> > We've already taken three user visible outages because the OAuth2 >> spec >> > reused the "oauth_token" parameter in a way that was not compatible >> > with the OAuth1 spec. >> > >> > Luckily they were all caught before they caused serious damage. >> > >> > Generic parameter names are not useful. They lead to confused >> > developers and confused code. If code needs to treat the values >> > differently, the names should be different as well. >> > >> > Cheers, >> > Brian >> > >> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt >>> >> wrote: >> > > There was some discussion on the type for the authorization header >> being >> > > OAUTH / MAC / BEARER etc. Did we have a resolution? >> > > As for section 2.2 and 2.3, should we not have a more neutral >> solution as >> > > well and use "authorization_token" instead of oauth_token. The >> idea is that >> > > the parameter corresponds to the authorization header and NOT the >> value of >> > > it. The value of such a parameter an be an encoded value that >> corresponds to >> > > the authorization header. For example: >> > > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: >> > > server.example.com >> > > instead of >> > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: >> server.example.com >> > > The concern is that if for some reason you switch to "MAC" tokens, >> then you >> > > have to change parameter names. Why not keep them consistent? >> > > Apologies if this was already resolved. >> > > Phil >> > > phil.hunt@oracle.com >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > > > > > From jricher@mitre.org Tue Mar 8 16:16:05 2011 Return-Path: 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 68EEF3A67E6 for ; Tue, 8 Mar 2011 16:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aoTwVlRvnnFR for ; Tue, 8 Mar 2011 16:16:04 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 49B7F3A67D4 for ; Tue, 8 Mar 2011 16:16:04 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A95F621B06CC; Tue, 8 Mar 2011 19:17:19 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A1CDD21B1328; Tue, 8 Mar 2011 19:17:19 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 8 Mar 2011 19:17:19 -0500 From: "Richer, Justin P." To: Eran Hammer-Lahav , "William J. Mills" Date: Tue, 8 Mar 2011 19:16:59 -0500 Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: Acvd7hQyUdd8tgiGQuS8mlyfqymhRwAATpmO Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 00:16:05 -0000 I simply don't agree that there's much difference in practice for many peop= le. -- justin ________________________________________ From: Eran Hammer-Lahav [eran@hueniverse.com] Sent: Tuesday, March 08, 2011 7:08 PM To: Richer, Justin P.; William J. Mills Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft No. There is a huge difference between adding parameters to protected resources and defining parameter for OAuth specific endpoints (which may create conflicts with existing frameworks). One is an invasion of the provider's namespace where OAuth has no business messing around. The other is a potential deployment issue. EHL On 3/8/11 3:48 PM, "Richer, Justin P." wrote: >Except that we're also infringing on service provider namespaces for our >other endpoints as well. Not every service provider can or will create a >pristine endpoint for tokens or authorizations, but this working group >has had no problems putting all kinds of parameters into that space. >Unless we want to say that we can't use query or form parameters in >specifications ever again, this argument doesn't really hold up. > > -- Justin >________________________________________ >From: Eran Hammer-Lahav [eran@hueniverse.com] >Sent: Tuesday, March 08, 2011 1:02 PM >To: William J. Mills; Richer, Justin P. >Cc: OAuth WG >Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > >I hope this will be the last time we define a query parameter for >delivering what should be sent via a request header field. Infringing on >a service's namespace is always a bad idea, no matter what prefix we put >next to it. > >EHL > >From: "William J. Mills" >> >Reply-To: "William J. Mills" >> >Date: Tue, 8 Mar 2011 10:11:46 -0700 >To: Justin Richer > >Cc: OAuth WG > >Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > >So is a different namespace for each new mechanism right, or should a >parameter be added to parallel the authorization scheme name? Seems like >it would be clean to define oauth_scheme and use the same value as >defined for the auth scheme name. > >________________________________ >From: Justin Richer > >To: William J. Mills > >Cc: Brian Eaton >; OAuth WG >> >Sent: Tuesday, March 8, 2011 8:41 AM >Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > >I don't understand this comment. If you're using query/form parameters, >there are no schemes involved in the process. > >-- Justin > > >On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: >> A major difference is now there is a scheme name that is >> differentiating. You no longer have to parse the entire variable set >> to figure out what is going on. Now the scheme name determines >> things. Now that we have schemes I don't see re-using parameter names >> as a problem. >> >> >> >> >> ______________________________________________________________________ >> From: Justin Richer > >> To: Brian Eaton > >> Cc: OAuth WG > >> Sent: Tuesday, March 8, 2011 7:11 AM >> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >> >> Very strongly agree, repeat my suggestion to name the parameter >> "oauth2_token". >> >> -- Justin >> >> On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: >> > My two cents: >> > >> > We've already taken three user visible outages because the OAuth2 >> spec >> > reused the "oauth_token" parameter in a way that was not compatible >> > with the OAuth1 spec. >> > >> > Luckily they were all caught before they caused serious damage. >> > >> > Generic parameter names are not useful. They lead to confused >> > developers and confused code. If code needs to treat the values >> > differently, the names should be different as well. >> > >> > Cheers, >> > Brian >> > >> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt >>> >> wrote: >> > > There was some discussion on the type for the authorization header >> being >> > > OAUTH / MAC / BEARER etc. Did we have a resolution? >> > > As for section 2.2 and 2.3, should we not have a more neutral >> solution as >> > > well and use "authorization_token" instead of oauth_token. The >> idea is that >> > > the parameter corresponds to the authorization header and NOT the >> value of >> > > it. The value of such a parameter an be an encoded value that >> corresponds to >> > > the authorization header. For example: >> > > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: >> > > server.example.com >> > > instead of >> > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: >> server.example.com >> > > The concern is that if for some reason you switch to "MAC" tokens, >> then you >> > > have to change parameter names. Why not keep them consistent? >> > > Apologies if this was already resolved. >> > > Phil >> > > phil.hunt@oracle.com >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > > > > > From beaton@google.com Tue Mar 8 18:24:14 2011 Return-Path: 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 114B73A6802 for ; Tue, 8 Mar 2011 18:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.477 X-Spam-Level: X-Spam-Status: No, score=-105.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 e4dd1wiNNAQv for ; Tue, 8 Mar 2011 18:24:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 885183A6800 for ; Tue, 8 Mar 2011 18:24:12 -0800 (PST) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p292PRBH004399 for ; Tue, 8 Mar 2011 18:25:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299637527; bh=gMTL/QGsAiH9x8F/MU3AB9uzM/Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=vYn/uj0B4XpArHxHFrdHThMovg04upH9GQQo3Q2kkrPs63N88Q++KpgPiNGpkgAsK 53RBfkDVhUyKQghZg4siQ== Received: from yxp4 (yxp4.prod.google.com [10.190.4.196]) by hpaq13.eem.corp.google.com with ESMTP id p292P5kD026640 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 18:25:25 -0800 Received: by yxp4 with SMTP id 4so40584yxp.10 for ; Tue, 08 Mar 2011 18:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1zs8iaJNRaNbugyGrkRHt6XLTDrSPFLC+mnD6M4136w=; b=ogqMEewMGfjOV9EamUrVRfFCFg6adK8hJwt89JbseaATV8j5p2XfPolGKmuJb0y1Lw BrsFhIwNIL8OHcutvCzQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=K+9BFJZw13fmix4pydMZkP8eoHAdLzdLhXMUnNVJ0SGhXva8kAuMsvxRd9s5CWZQj4 73ftLLT6C0uoK8OFB5rg== MIME-Version: 1.0 Received: by 10.90.134.20 with SMTP id h20mr7851060agd.24.1299637524335; Tue, 08 Mar 2011 18:25:24 -0800 (PST) Received: by 10.90.71.19 with HTTP; Tue, 8 Mar 2011 18:25:24 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Mar 2011 18:25:24 -0800 Message-ID: From: Brian Eaton To: "Richer, Justin P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 02:24:14 -0000 This has been proven true in our deployment as well. On Tue, Mar 8, 2011 at 4:16 PM, Richer, Justin P. wrote= : > I simply don't agree that there's much difference in practice for many pe= ople. > > =A0-- justin > ________________________________________ > From: Eran Hammer-Lahav [eran@hueniverse.com] > Sent: Tuesday, March 08, 2011 7:08 PM > To: Richer, Justin P.; William J. Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > No. > > There is a huge difference between adding parameters to protected > resources and defining parameter for OAuth specific endpoints (which may > create conflicts with existing frameworks). > > One is an invasion of the provider's namespace where OAuth has no busines= s > messing around. The other is a potential deployment issue. > > EHL > > > On 3/8/11 3:48 PM, "Richer, Justin P." wrote: > >>Except that we're also infringing on service provider namespaces for our >>other endpoints as well. Not every service provider can or will create a >>pristine endpoint for tokens or authorizations, but this working group >>has had no problems putting all kinds of parameters into that space. >>Unless we want to say that we can't use query or form parameters in >>specifications ever again, this argument doesn't really hold up. >> >> -- Justin >>________________________________________ >>From: Eran Hammer-Lahav [eran@hueniverse.com] >>Sent: Tuesday, March 08, 2011 1:02 PM >>To: William J. Mills; Richer, Justin P. >>Cc: OAuth WG >>Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >> >>I hope this will be the last time we define a query parameter for >>delivering what should be sent via a request header field. Infringing on >>a service's namespace is always a bad idea, no matter what prefix we put >>next to it. >> >>EHL >> >>From: "William J. Mills" >>> >>Reply-To: "William J. Mills" >>> >>Date: Tue, 8 Mar 2011 10:11:46 -0700 >>To: Justin Richer > >>Cc: OAuth WG > >>Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >> >>So is a different namespace for each new mechanism right, or should a >>parameter be added to parallel the authorization scheme name? =A0Seems li= ke >>it would be clean to define oauth_scheme and use the same value as >>defined for the auth scheme name. >> >>________________________________ >>From: Justin Richer > >>To: William J. Mills > >>Cc: Brian Eaton >; OAuth WG >>> >>Sent: Tuesday, March 8, 2011 8:41 AM >>Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >> >>I don't understand this comment. If you're using query/form parameters, >>there are no schemes involved in the process. >> >>-- Justin >> >> >>On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: >>> A major difference is now there is a scheme name that is >>> differentiating. =A0You no longer have to parse the entire variable set >>> to figure out what is going on. =A0Now the scheme name determines >>> things. =A0Now that we have schemes I don't see re-using parameter name= s >>> as a problem. >>> >>> >>> >>> >>> ______________________________________________________________________ >>> From: Justin Richer > >>> To: Brian Eaton > >>> Cc: OAuth WG > >>> Sent: Tuesday, March 8, 2011 7:11 AM >>> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >>> >>> Very strongly agree, repeat my suggestion to name the parameter >>> "oauth2_token". >>> >>> -- Justin >>> >>> On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: >>> > My two cents: >>> > >>> > We've already taken three user visible outages because the OAuth2 >>> spec >>> > reused the "oauth_token" parameter in a way that was not compatible >>> > with the OAuth1 spec. >>> > >>> > Luckily they were all caught before they caused serious damage. >>> > >>> > Generic parameter names are not useful. =A0They lead to confused >>> > developers and confused code. =A0If code needs to treat the values >>> > differently, the names should be different as well. >>> > >>> > Cheers, >>> > Brian >>> > >>> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt >>>> >>> wrote: >>> > > There was some discussion on the type for the authorization header >>> being >>> > > OAUTH / MAC / BEARER etc. Did we have a resolution? >>> > > As for section 2.2 and 2.3, should we not have a more neutral >>> solution as >>> > > well and use "authorization_token" instead of oauth_token. The >>> idea is that >>> > > the parameter corresponds to the authorization header and NOT the >>> value of >>> > > it. The value of such a parameter an be an encoded value that >>> corresponds to >>> > > the authorization header. =A0For example: >>> > > GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host= : >>> > > server.example.com >>> > > instead of >>> > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: >>> server.example.com >>> > > The concern is that if for some reason you switch to "MAC" tokens, >>> then you >>> > > have to change parameter names. Why not keep them consistent? >>> > > Apologies if this was already resolved. >>> > > Phil >>> > > phil.hunt@oracle.com >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > 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 >>> >>> >>> _______________________________________________ >>> 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 > From eran@hueniverse.com Tue Mar 8 20:17:08 2011 Return-Path: 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 8B9B73A6812 for ; Tue, 8 Mar 2011 20:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] 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 2PBzE4EJiDaF for ; Tue, 8 Mar 2011 20:17:07 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2FCDE3A6817 for ; Tue, 8 Mar 2011 20:17:07 -0800 (PST) Received: (qmail 22543 invoked from network); 9 Mar 2011 04:18:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Mar 2011 04:18:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 8 Mar 2011 21:18:16 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 8 Mar 2011 21:17:47 -0700 Thread-Topic: [OAUTH-WG] OAuth Bearer Token draft Thread-Index: AcveEQMd3gRefu4FRrCJjO/V78skUw== Message-ID: <92C2DBF7-B45E-4C2C-8D28-F110372DFAC6@hueniverse.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:17:08 -0000 What exactly? On Mar 8, 2011, at 18:25, "Brian Eaton" wrote: > This has been proven true in our deployment as well. >=20 > On Tue, Mar 8, 2011 at 4:16 PM, Richer, Justin P. wro= te: >> I simply don't agree that there's much difference in practice for many p= eople. >>=20 >> -- justin >> ________________________________________ >> From: Eran Hammer-Lahav [eran@hueniverse.com] >> Sent: Tuesday, March 08, 2011 7:08 PM >> To: Richer, Justin P.; William J. Mills >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >>=20 >> No. >>=20 >> There is a huge difference between adding parameters to protected >> resources and defining parameter for OAuth specific endpoints (which may >> create conflicts with existing frameworks). >>=20 >> One is an invasion of the provider's namespace where OAuth has no busine= ss >> messing around. The other is a potential deployment issue. >>=20 >> EHL >>=20 >>=20 >> On 3/8/11 3:48 PM, "Richer, Justin P." wrote: >>=20 >>> Except that we're also infringing on service provider namespaces for ou= r >>> other endpoints as well. Not every service provider can or will create = a >>> pristine endpoint for tokens or authorizations, but this working group >>> has had no problems putting all kinds of parameters into that space. >>> Unless we want to say that we can't use query or form parameters in >>> specifications ever again, this argument doesn't really hold up. >>>=20 >>> -- Justin >>> ________________________________________ >>> From: Eran Hammer-Lahav [eran@hueniverse.com] >>> Sent: Tuesday, March 08, 2011 1:02 PM >>> To: William J. Mills; Richer, Justin P. >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >>>=20 >>> I hope this will be the last time we define a query parameter for >>> delivering what should be sent via a request header field. Infringing o= n >>> a service's namespace is always a bad idea, no matter what prefix we pu= t >>> next to it. >>>=20 >>> EHL >>>=20 >>> From: "William J. Mills" >>> > >>> Reply-To: "William J. Mills" >>> > >>> Date: Tue, 8 Mar 2011 10:11:46 -0700 >>> To: Justin Richer > >>> Cc: OAuth WG > >>> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >>>=20 >>> So is a different namespace for each new mechanism right, or should a >>> parameter be added to parallel the authorization scheme name? Seems li= ke >>> it would be clean to define oauth_scheme and use the same value as >>> defined for the auth scheme name. >>>=20 >>> ________________________________ >>> From: Justin Richer > >>> To: William J. Mills = > >>> Cc: Brian Eaton >; OAuth WG >>> > >>> Sent: Tuesday, March 8, 2011 8:41 AM >>> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >>>=20 >>> I don't understand this comment. If you're using query/form parameters, >>> there are no schemes involved in the process. >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote: >>>> A major difference is now there is a scheme name that is >>>> differentiating. You no longer have to parse the entire variable set >>>> to figure out what is going on. Now the scheme name determines >>>> things. Now that we have schemes I don't see re-using parameter names >>>> as a problem. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ______________________________________________________________________ >>>> From: Justin Richer > >>>> To: Brian Eaton > >>>> Cc: OAuth WG > >>>> Sent: Tuesday, March 8, 2011 7:11 AM >>>> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft >>>>=20 >>>> Very strongly agree, repeat my suggestion to name the parameter >>>> "oauth2_token". >>>>=20 >>>> -- Justin >>>>=20 >>>> On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote: >>>>> My two cents: >>>>>=20 >>>>> We've already taken three user visible outages because the OAuth2 >>>> spec >>>>> reused the "oauth_token" parameter in a way that was not compatible >>>>> with the OAuth1 spec. >>>>>=20 >>>>> Luckily they were all caught before they caused serious damage. >>>>>=20 >>>>> Generic parameter names are not useful. They lead to confused >>>>> developers and confused code. If code needs to treat the values >>>>> differently, the names should be different as well. >>>>>=20 >>>>> Cheers, >>>>> Brian >>>>>=20 >>>>> On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt >>>> > >>>> wrote: >>>>>> There was some discussion on the type for the authorization header >>>> being >>>>>> OAUTH / MAC / BEARER etc. Did we have a resolution? >>>>>> As for section 2.2 and 2.3, should we not have a more neutral >>>> solution as >>>>>> well and use "authorization_token" instead of oauth_token. The >>>> idea is that >>>>>> the parameter corresponds to the authorization header and NOT the >>>> value of >>>>>> it. The value of such a parameter an be an encoded value that >>>> corresponds to >>>>>> the authorization header. For example: >>>>>> GET /resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host: >>>>>> server.example.com >>>>>> instead of >>>>>> GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host: >>>> server.example.com >>>>>> The concern is that if for some reason you switch to "MAC" tokens, >>>> then you >>>>>> have to change parameter names. Why not keep them consistent? >>>>>> Apologies if this was already resolved. >>>>>> Phil >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 From wmills@yahoo-inc.com Tue Mar 8 20:48:54 2011 Return-Path: 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 E82613A6807 for ; Tue, 8 Mar 2011 20:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 1qjozUJ4dPiO for ; Tue, 8 Mar 2011 20:48:52 -0800 (PST) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id AEAB73A67E1 for ; Tue, 8 Mar 2011 20:48:52 -0800 (PST) Received: (qmail 36949 invoked by uid 60001); 9 Mar 2011 04:50:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1299646200; bh=vSrN2lRHhRiTIVpmcmOSMdbzgG7qaHv3icw9xE+aBKg=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=SVocvcDVw6EQULF8vkz6yf9gnDKtS6S/eh35rw7zMTW57neXFo26ZhuPhJxyjYqT2hxxt82CgF9KHttY87bz+x+4p6e9AIpWOy6E88gebX7LdjtzCUjOzKUm5mtPY8NffH6aXhke3XpXaIcpiZJucXg3USOJtJR84U5ax+/MIFU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=M72HkkllOnveqAh8O+tbu5tKlygh6fiMgYQrPXwxcsDla2xSbKAvHggSL/5tD5sIjHYgMJBPgYGueDUIn+WfRDKmlJnMf3y4AFd9Oxdim8jAqXko2JHYBkOJz05knolmIByjW7JnwjiUcYQ4+VxT0cUe9CC9tcOLnP6hCXSXm8I=; Message-ID: <42514.55268.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: tsrxxQMVM1l4MVSLlHF5WiG3HpoRZ4fcF_4ShGRVak7y_lX wBC_ESY_.Myz5xILI1NbVXEZKunAmuU5hm.WDPhNedcDanI9aDY9HD6s0Xlm bmv8rPt4EXUHzObzjqDc1b_nUKzT8bJUo.gvZpxvTY_tdGB.7rOHQTydgqSC cmzGU7gqBSSMF6Y4dJWtASmiuNWyycrgLkc0e9UvEFMOM5YmPUTQj3XCob_q BfnA938evvnkW1xdoV947_MO0Mrm0w.YzAZt2jt9vfK8KvyKeLEgljCooHTo BsfggLXXJLEIPKdOAxndg5QwnUdI- Received: from [99.31.212.42] by web32303.mail.mud.yahoo.com via HTTP; Tue, 08 Mar 2011 20:49:59 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.296531 Date: Tue, 8 Mar 2011 20:49:59 -0800 (PST) From: "William J. Mills" To: Brian Eaton , "Richer, Justin P." MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1602634214-1299646199=:55268" Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 04:48:55 -0000 --0-1602634214-1299646199=:55268 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Is there really a need going forward for anything beyond using the Authoriz= ation header?=A0=A0 Do we have clients out there that just can't set that h= eader?=A0 Putting bearer tokens in query arguments is a very bad idea for m= any reasons, and in form variables has it's own set of badness (although no= t to the same level).=0A=0A-bill=0A=0A=0A=0A_______________________________= _=0AFrom: Brian Eaton =0ATo: "Richer, Justin P." =0ACc: Eran Hammer-Lahav ; William J. Mill= s ; OAuth WG =0ASent: Tuesday, March = 8, 2011 6:25 PM=0ASubject: Re: [OAUTH-WG] OAuth Bearer Token draft=0A=0AThi= s has been proven true in our deployment as well.=0A=0AOn Tue, Mar 8, 2011 = at 4:16 PM, Richer, Justin P. wrote:=0A> I simply don't= agree that there's much difference in practice for many people.=0A>=0A> = =A0-- justin=0A> ________________________________________=0A> From: Eran Ha= mmer-Lahav [eran@hueniverse.com]=0A> Sent: Tuesday, March 08, 2011 7:08 PM= =0A> To: Richer, Justin P.; William J. Mills=0A> Cc: OAuth WG=0A> Subject: = Re: [OAUTH-WG] OAuth Bearer Token draft=0A>=0A> No.=0A>=0A> There is a huge= difference between adding parameters to protected=0A> resources and defini= ng parameter for OAuth specific endpoints (which may=0A> create conflicts w= ith existing frameworks).=0A>=0A> One is an invasion of the provider's name= space where OAuth has no business=0A> messing around. The other is a potent= ial deployment issue.=0A>=0A> EHL=0A>=0A>=0A> On 3/8/11 3:48 PM, "Richer, J= ustin P." wrote:=0A>=0A>>Except that we're also infring= ing on service provider namespaces for our=0A>>other endpoints as well. Not= every service provider can or will create a=0A>>pristine endpoint for toke= ns or authorizations, but this working group=0A>>has had no problems puttin= g all kinds of parameters into that space.=0A>>Unless we want to say that w= e can't use query or form parameters in=0A>>specifications ever again, this= argument doesn't really hold up.=0A>>=0A>> -- Justin=0A>>_________________= _______________________=0A>>From: Eran Hammer-Lahav [eran@hueniverse.com]= =0A>>Sent: Tuesday, March 08, 2011 1:02 PM=0A>>To: William J. Mills; Richer= , Justin P.=0A>>Cc: OAuth WG=0A>>Subject: Re: [OAUTH-WG] OAuth Bearer Token= draft=0A>>=0A>>I hope this will be the last time we define a query paramet= er for=0A>>delivering what should be sent via a request header field. Infri= nging on=0A>>a service's namespace is always a bad idea, no matter what pre= fix we put=0A>>next to it.=0A>>=0A>>EHL=0A>>=0A>>From: "William J. Mills"= =0A>>>=0A>>Reply-To: "Wil= liam J. Mills"=0A>>>=0A>>= Date: Tue, 8 Mar 2011 10:11:46 -0700=0A>>To: Justin Richer >=0A>>Cc: OAuth WG >=0A>>Subject: Re: [OAUTH-WG] OAuth Bearer Token draft=0A>>=0A>>S= o is a different namespace for each new mechanism right, or should a=0A>>pa= rameter be added to parallel the authorization scheme name? =A0Seems like= =0A>>it would be clean to define oauth_scheme and use the same value as=0A>= >defined for the auth scheme name.=0A>>=0A>>_______________________________= _=0A>>From: Justin Richer >=0A>= >To: William J. Mills >= =0A>>Cc: Brian Eaton >; OAuth W= G=0A>>>=0A>>Sent: Tuesday, March 8, 2= 011 8:41 AM=0A>>Subject: Re: [OAUTH-WG] OAuth Bearer Token draft=0A>>=0A>>I= don't understand this comment. If you're using query/form parameters,=0A>>= there are no schemes involved in the process.=0A>>=0A>>-- Justin=0A>>=0A>>= =0A>>On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote:=0A>>> A maj= or difference is now there is a scheme name that is=0A>>> differentiating. = =A0You no longer have to parse the entire variable set=0A>>> to figure out = what is going on. =A0Now the scheme name determines=0A>>> things. =A0Now th= at we have schemes I don't see re-using parameter names=0A>>> as a problem.= =0A>>>=0A>>>=0A>>>=0A>>>=0A>>> ____________________________________________= __________________________=0A>>> From: Justin Richer >=0A>>> To: Brian Eaton >=0A>>> Cc: OAuth WG >= =0A>>> Sent: Tuesday, March 8, 2011 7:11 AM=0A>>> Subject: Re: [OAUTH-WG] O= Auth Bearer Token draft=0A>>>=0A>>> Very strongly agree, repeat my suggesti= on to name the parameter=0A>>> "oauth2_token".=0A>>>=0A>>> -- Justin=0A>>>= =0A>>> On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote:=0A>>> > My two= cents:=0A>>> >=0A>>> > We've already taken three user visible outages beca= use the OAuth2=0A>>> spec=0A>>> > reused the "oauth_token" parameter in a w= ay that was not compatible=0A>>> > with the OAuth1 spec.=0A>>> >=0A>>> > Lu= ckily they were all caught before they caused serious damage.=0A>>> >=0A>>>= > Generic parameter names are not useful. =A0They lead to confused=0A>>> >= developers and confused code. =A0If code needs to treat the values=0A>>> >= differently, the names should be different as well.=0A>>> >=0A>>> > Cheers= ,=0A>>> > Brian=0A>>> >=0A>>> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt= =0A>>>>=0A>>> wrote:=0A>>= > > > There was some discussion on the type for the authorization header=0A= >>> being=0A>>> > > OAUTH / MAC / BEARER etc. Did we have a resolution?=0A>= >> > > As for section 2.2 and 2.3, should we not have a more neutral=0A>>> = solution as=0A>>> > > well and use "authorization_token" instead of oauth_t= oken. The=0A>>> idea is that=0A>>> > > the parameter corresponds to the aut= horization header and NOT the=0A>>> value of=0A>>> > > it. The value of suc= h a parameter an be an encoded value that=0A>>> corresponds to=0A>>> > > th= e authorization header. =A0For example:=0A>>> > > GET /resource?authorizati= on_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host:=0A>>> > > server.example.com=0A= >>> > > instead of=0A>>> > > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.= 1 Host:=0A>>> server.example.com=0A>>> > > The concern is that if for some = reason you switch to "MAC" tokens,=0A>>> then you=0A>>> > > have to change = parameter names. Why not keep them consistent?=0A>>> > > Apologies if this = was already resolved.=0A>>> > > Phil=0A>>> > > phil.hunt@oracle.com=0A>>> > >=0A>>> > >=0A>>> > >=0A>>> > >=0A>>> > > ___= ____________________________________________=0A>>> > > OAuth mailing list= =0A>>> > > OAuth@ietf.org=0A>>> > > https://www.ietf= .org/mailman/listinfo/oauth=0A>>> > >=0A>>> > >=0A>>> > ___________________= ____________________________=0A>>> > OAuth mailing list=0A>>> > OAuth@ietf.= org=0A>>> > https://www.ietf.org/mailman/listinfo/oa= uth=0A>>>=0A>>>=0A>>> _______________________________________________=0A>>>= OAuth mailing list=0A>>> OAuth@ietf.org=0A>>> https= ://www.ietf.org/mailman/listinfo/oauth=0A>>>=0A>>>=0A>>>=0A>>>=0A>>=0A>>=0A= >>=0A>>=0A>>=0A>=0A> _______________________________________________=0A> OA= uth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listin= fo/oauth=0A>=0A=0A=0A --0-1602634214-1299646199=:55268 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Is there r= eally a need going forward for anything beyond using the Authorization head= er?   Do we have clients out there that just can't set that heade= r?  Putting bearer tokens in query arguments is a very bad idea for ma= ny reasons, and in form variables has it's own set of badness (although not= to the same level).

-bi= ll

From: B= rian Eaton <beaton@google.com>
To: "Richer, Justin P." <jricher@mitre.org>
Cc: Eran Hammer-Lahav <eran@hue= niverse.com>; William J. Mills <wmills@yahoo-inc.com>; OAuth WG &l= t;oauth@ietf.org>
Sent:<= /b> Tuesday, March 8, 2011 6:25 PM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

= =0AThis has been proven true in our deployment as well.

On Tue, Mar= 8, 2011 at 4:16 PM, Richer, Justin P. <jricher@mitre.org> wrote:<= br>> I simply don't agree that there's much difference in practice for m= any people.
>
>  -- justin
> _______________________= _________________
> From: Eran Hammer-Lahav [eran@hueniverse.com]
> Sent: Tuesday, March 08, 2011 7:08 PM
> To: Richer, Justi= n P.; William J. Mills
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG]= OAuth Bearer Token draft
>
> No.
>
> There is a hu= ge difference between adding parameters to protected
> resources and = defining parameter for OAuth specific endpoints (which may
> create c= onflicts with existing frameworks).
>
> One is an invasion of t= he provider's namespace where OAuth has no business
> messing around. T= he other is a potential deployment issue.
>
> EHL
>
&g= t;
> On 3/8/11 3:48 PM, "Richer, Justin P." <jricher@mitre.org&= gt; wrote:
>
>>Except that we're also infringing on service = provider namespaces for our
>>other endpoints as well. Not every s= ervice provider can or will create a
>>pristine endpoint for token= s or authorizations, but this working group
>>has had no problems = putting all kinds of parameters into that space.
>>Unless we want = to say that we can't use query or form parameters in
>>specificati= ons ever again, this argument doesn't really hold up.
>>
>&g= t; -- Justin
>>________________________________________
>>= ;From: Eran Hammer-Lahav [eran@hueniverse.com]
>>Se= nt: Tuesday, March 08, 2011 1:02 PM
>>To: William J. Mills; Richer= , Justin P.
>>Cc: OAuth WG
>>Subject: Re: [OAUTH-WG] OAut= h Bearer Token draft
>>
>>I hope this will be the last ti= me we define a query parameter for
>>delivering what should be sen= t via a request header field. Infringing on
>>a service's namespac= e is always a bad idea, no matter what prefix we put
>>next to it.=
>>
>>EHL
>>
>>From: "William J. Mills"=
>><wmills@yahoo-inc.com<mailto:wmills@yahoo-i= nc.com>>
>>Reply-To: "William J. Mills"
>><<= a ymailto=3D"mailto:wmills@yahoo-inc.com" href=3D"mailto:wmills@yahoo-inc.com">wmills@yahoo-inc.com<mailto:wmills@yahoo-inc.com>>
>>Date: Tue, 8 Mar 2011 10:11:= 46 -0700
>>To: Justin Richer <jricher@mitre.org<mailto:jri= cher@mitre.org>>
>>Cc: OAuth WG <oauth@ietf.org<mailt= o:oauth= @ietf.org>>
>>Subject: Re: [OAUTH-WG] OAuth Bearer Token= draft
>>
>>So is a different namespace for each new mech= anism right, or should a
>>parameter be added to parallel the auth= orization scheme name?  Seems like
>>it would be clean to def= ine oauth_scheme and use the same value as
>>defined for the auth sch= eme name.
>>
>>________________________________
>&g= t;From: Justin Richer <jricher@mitre.org<mailto:jricher@mitre.org>>
>>To: William J. Mills <wmills@yahoo-inc.com<mailto:wmills@yahoo-inc.com>>
>>Cc: Brian Eato= n <beaton@google.com<mailto:beaton@google.com>>; OAuth WG=
>><oauth@ietf.org<mailto:oauth@ietf.org>= ;>
>>Sent: Tuesday, March 8, 2011 8:41 AM
>>Subject: R= e: [OAUTH-WG] OAuth Bearer Token draft
>>
>>I don't under= stand this comment. If you're using query/form parameters,
>>there= are no schemes involved in the process.
>>
>>-- Justin>>
>>
>>On Tue, 2011-03-08 at 11:27 -0500, Willia= m J. Mills wrote:
>>> A major difference is now there is a sche= me name that is
>>> differentiating.  You no longer have t= o parse the entire variable set
>>> to figure out what is going= on.  Now the scheme name determines
>>> things.  Now= that we have schemes I don't see re-using parameter names
>>> = as a problem.
>>>
>>>
>>>
>>>>>> ____________________________________________________________= __________
>>> From: Justin Richer <jricher@mitre.org<= mailto:jricher@mitre.org>>
>>> To: Brian Eaton <beat= on@google.com<mailto:beaton@google.com>>
>>> Cc= : OAuth WG <oauth@ietf.org<mailto:oauth@ietf.org>>
>>> Se= nt: Tuesday, March 8, 2011 7:11 AM
>>> Subject: Re: [OAUTH-WG] = OAuth Bearer Token draft
>>>
>>> Very strongly agree, repeat my= suggestion to name the parameter
>>> "oauth2_token".
>&g= t;>
>>> -- Justin
>>>
>>> On Fri, 20= 11-02-25 at 14:49 -0500, Brian Eaton wrote:
>>> > My two cen= ts:
>>> >
>>> > We've already taken three use= r visible outages because the OAuth2
>>> spec
>>> &= gt; reused the "oauth_token" parameter in a way that was not compatible
= >>> > with the OAuth1 spec.
>>> >
>>>= ; > Luckily they were all caught before they caused serious damage.
&= gt;>> >
>>> > Generic parameter names are not usefu= l.  They lead to confused
>>> > developers and confused= code.  If code needs to treat the values
>>> > differe= ntly, the names should be different as well.
>>> >
>>> > Cheers,
>>> > Brian
>>&g= t; >
>>> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt>>><phil.hunt@oracle.com<mailto:phil.hunt@ora= cle.com>>
>>> wrote:
>>> > > There = was some discussion on the type for the authorization header
>>>= ; being
>>> > > OAUTH / MAC / BEARER etc. Did we have a r= esolution?
>>> > > As for section 2.2 and 2.3, should we = not have a more neutral
>>> solution as
>>> > &g= t; well and use "authorization_token" instead of oauth_token. The
>&g= t;> idea is that
>>> > > the parameter corresponds to = the authorization header and NOT the
>>> value of
>>> > > it. The value of such a parameter an be an en= coded value that
>>> corresponds to
>>> > > t= he authorization header.  For example:
>>> > > GET /= resource?authorization_token=3DBEARER+vF9dft4qmT HTTP/1.1 Host:
>>= > > > serv= er.example.com
>>> > > instead of
>>> >= ; > GET /resource?oauth_token=3DvF9dft4qmT HTTP/1.1 Host:
>>>= ; server.example.com
>>> > > The concern is that if for s= ome reason you switch to "MAC" tokens,
>>> then you
>>= > > > have to change parameter names. Why not keep them consistent= ?
>>> > > Apologies if this was already resolved.
>= >> > > Phil
>>> > > phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>
>>> > >
>>> &= gt; >
>>> > >
>>> > >
>>>= ; > > _______________________________________________
>>>= > > OAuth mailing list
>>> > > OAuth@ietf.org<mail= to:OAut= h@ietf.org>
>>> > > https://www.ietf.org/mailman/li= stinfo/oauth
>>> > >
>>> > >
>= ;>> > _______________________________________________
>>&= gt; > OAuth mailing list
>>> > OAuth@ietf.org<mailto:OAuth@ietf.org>= ;
>>> > https://www.ietf.org/mailman/listinfo/oauth
&g= t;>>
>>>
>>> ________________________________= _______________
>>> OAuth mailing list
>>> OAuth@ietf.org<= /a><mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/l= istinfo/oauth
>>>
>>>
>>>
>&g= t;>
>>
>>
>>
>>
>>
><= br>> _______________________________________________
> OAuth maili= ng list
> OAuth@= ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=


=0A=0A --0-1602634214-1299646199=:55268-- From torsten@lodderstedt.net Wed Mar 9 12:44:27 2011 Return-Path: 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 774C83A6AC3 for ; Wed, 9 Mar 2011 12:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 mp7jAvm6Kaow for ; Wed, 9 Mar 2011 12:44:26 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id A1AEF3A6ABE for ; Wed, 9 Mar 2011 12:44:25 -0800 (PST) Received: from [79.253.32.99] (helo=[192.168.71.26]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PxQGK-0000vh-EJ; Wed, 09 Mar 2011 21:45:40 +0100 Message-ID: <4D77E6F5.2060003@lodderstedt.net> Date: Wed, 09 Mar 2011 21:45:41 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phil Hunt References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> In-Reply-To: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:44:27 -0000 Hi Phil, that's great help for anyone looking for advice how to use OAuth. One remark: In my opinion, the decision process for authorization code vs. implicit grant involves more parameters. refresh token required? --> authz code client in question is a web application? --> authz code client in question is a JavaScript app? --> implicit grant client authentication required --> authz code else --> implicit grant regards, Torsten. Am 22.02.2011 01:45, schrieb Phil Hunt: > FYI. I published a blog post with a flow-chart explaining the legs of OAuth. > http://independentidentity.blogspot.com/2011/02/does-oauth-have-legs.html > > Please let me know if any corrections should be made, or for that matter, any improvements! > > Phil > phil.hunt@oracle.com > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Wed Mar 9 13:01:01 2011 Return-Path: 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 DD9F13A6AD2 for ; Wed, 9 Mar 2011 13:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 NyPXm+3sDm2U for ; Wed, 9 Mar 2011 13:01:01 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3A8BB3A6943 for ; Wed, 9 Mar 2011 13:01:00 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p29L2FiG010038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2011 21:02:16 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p29EJHWO019534; Wed, 9 Mar 2011 21:02:14 GMT Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 1073085251299704529; Wed, 09 Mar 2011 13:02:09 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Mar 2011 13:02:08 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4D77E6F5.2060003@lodderstedt.net> Date: Wed, 9 Mar 2011 13:02:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <36FA5946-EF9B-4212-ADB5-BF762EA6827A@oracle.com> References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <4D77E6F5.2060003@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1082) X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0209.4D77EAD7.000C,ss=1,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:01:01 -0000 Torsten, Thanks! Yes...I kind of omitted some of the flow decisions to keep the = diagram simpler. I also note that there has been quite a lot of discussion on the = pre-ambles to Implicit grant, etc. That said, I'm not sure I like binding application type (web app, = javascript app) to a particular flow. Some have said that the spec = shouldn't deal in best-practices (what flow should be used by specific = client types) as much as just focusing on the normative requirements for = each flow type.=20 It seems conceivable to me that people will come up with new scenarios = that don't fit the current definitions and the spec will 'break'.=20 With that in mind, the only real difference I saw between 4.1 and 4.2 = was one had client auth and an extra step, and while implicit did 2 = steps at once with only user authentication as a requirement. Though this has been discussed on another thread and I'll probably = update once a decision is made (draft 14?). Phil phil.hunt@oracle.com On 2011-03-09, at 12:45 PM, Torsten Lodderstedt wrote: > Hi Phil, >=20 > that's great help for anyone looking for advice how to use OAuth. >=20 > One remark: In my opinion, the decision process for authorization code = vs. implicit grant involves more parameters. >=20 > refresh token required? --> authz code > client in question is a web application? --> authz code > client in question is a JavaScript app? --> implicit grant > client authentication required --> authz code > else --> implicit grant >=20 > regards, > Torsten. >=20 > Am 22.02.2011 01:45, schrieb Phil Hunt: >> FYI. I published a blog post with a flow-chart explaining the legs of = OAuth. >> = http://independentidentity.blogspot.com/2011/02/does-oauth-have-legs.html >>=20 >> Please let me know if any corrections should be made, or for that = matter, any improvements! >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Wed Mar 9 22:21:55 2011 Return-Path: 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 D49C83A68BF for ; Wed, 9 Mar 2011 22:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 3fO89n4GkN2i for ; Wed, 9 Mar 2011 22:21:53 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6FC373A682D for ; Wed, 9 Mar 2011 22:21:53 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2A6N84A019023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2011 06:23:09 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2A4xRYK029205 for ; Thu, 10 Mar 2011 06:23:07 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 1125036631299738135; Wed, 09 Mar 2011 22:22:15 -0800 Received: from [25.65.223.104] (/74.198.150.232) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Mar 2011 22:22:15 -0800 From: Phillip Hunt Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (8C148a) Message-Id: Date: Wed, 9 Mar 2011 22:22:08 -0800 To: OAuth WG Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 8C148a) X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4D786E4B.02CC,ss=1,fgs=0 Subject: [OAUTH-WG] Lightweight web services X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 06:21:56 -0000 Thoughts on what makes up "lightweight web services" of which OAuth2 plays a= key role.=20 http://independentidentity.blogspot.com/2011/03/lightweight-web-services.htm= l Comments welcomed.=20 Phil Sent from my phone.=20= From lr@lukasrosenstock.net Thu Mar 10 08:48:31 2011 Return-Path: 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 F36F03A68C1 for ; Thu, 10 Mar 2011 08:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wIz8gIELiPkL for ; Thu, 10 Mar 2011 08:48:30 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 1432C3A6915 for ; Thu, 10 Mar 2011 08:48:29 -0800 (PST) Received: by yxk30 with SMTP id 30so978195yxk.31 for ; Thu, 10 Mar 2011 08:49:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.180.69 with SMTP id i45mr941303yhm.32.1299775787401; Thu, 10 Mar 2011 08:49:47 -0800 (PST) Received: by 10.146.168.16 with HTTP; Thu, 10 Mar 2011 08:49:47 -0800 (PST) X-Originating-IP: [134.176.178.92] In-Reply-To: <42514.55268.qm@web32303.mail.mud.yahoo.com> References: <42514.55268.qm@web32303.mail.mud.yahoo.com> Date: Thu, 10 Mar 2011 17:49:47 +0100 Message-ID: From: Lukas Rosenstock To: "William J. Mills" Content-Type: multipart/alternative; boundary=20cf305641fd1882de049e23a294 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 16:48:31 -0000 --20cf305641fd1882de049e23a294 Content-Type: text/plain; charset=ISO-8859-1 JSON-P (callback) works with