From James.H.Manger@team.telstra.com Sun Oct 2 05:47:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C3021F8B43 for ; Sun, 2 Oct 2011 05:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-1.386, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCLlo+rBW9ZR for ; Sun, 2 Oct 2011 05:47:53 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7355C21F8B42 for ; Sun, 2 Oct 2011 05:47:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,476,1312120800"; d="scan'208,217";a="47255883" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 02 Oct 2011 23:50:35 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6486"; a="38541662" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcavi.tcif.telstra.com.au with ESMTP; 02 Oct 2011 23:50:35 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Sun, 2 Oct 2011 23:50:35 +1100 From: "Manger, James H" To: Mike Jones , "oauth@ietf.org" Date: Sun, 2 Oct 2011 23:50:33 +1100 Thread-Topic: Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gCGXHeA Message-ID: <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.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_255B9BB34FB7D647A506DC292726F6E1129015546CWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 12:47:56 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1129015546CWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The best solution is to drop the "scope" field from the "WWW-Authenticate: = Bearer ..." response header. "scope" is relevant to an OAuth2-core flow, no= t to presenting a bearer token. "scope" could make sense in a "WWW-Authenti= cate: OAuth2 ..." response header as long as other necessary details such a= s an authorization URI were also provided. Dropping "scope" and "error_desc= ription" (as the error should be described in the response body) would elim= inate these encoding problems. If the group really wants to keep "scope", I don't think RFC 5987 is a good= solution. RFC 5987 might have been ok for adding internationalization supp= ort to long-standing ASCII-only fields in a world of multiple character set= s - but none of that applies here. Having to change the field name from "sc= ope" to "scope*" when you have a non-ASCII value is the biggest flaw. The simplest solution is to explicitly restrict scope values to some subset= of printable ASCII in OAuth2 Core. Not being able to support Unicode in a = new protocol is slightly disappointing, but I can live with it. My preferred escaping solution would be a JSON string, UTF-8 encoded: json.= org, RFC 4627; value in double-quotes; slash is the escape char; supports U= nicode; eg scope=3D"coll\u00E8gues". This is backward-compatible with HTTP'= s quoted-string syntax. It is forward-compatible with UTF-8 HTTP headers (i= f that occurs). JSON is well-supported (and required for other OAuth2 excha= nges). [I might suggest json-string to the httpbis group as a global replac= ement for quoted-string (or at least as a recommendation for new fields).] -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, 30 September 2011 4:53 AM To: oauth@ietf.org Subject: [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII= characters in scope strings than had previously been in evidence. If we d= ecide to define a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hy= pertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the c= lear choice. I'd be interested in knowing how many working group members a= re in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying = UTF-8 encoding of the error_description value, requesting the use of RFC 59= 87 encoding instead. I'd also be interested in knowing how many working gr= oup members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description paramete= r. (As editor, I would make the observation that if we choose RFC 5987 encodin= g for either of these parameters, it would be logical to do so for the othe= r one as well.) In the interest of finishing the specification in a way that meets everyone= 's needs, -- Mike --_000_255B9BB34FB7D647A506DC292726F6E1129015546CWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The best solution is to drop the “scope” field fr= om the “WWW-Authenticate: Bearer ...” response header. “s= cope” is relevant to an OAuth2-core flow, not to presenting a bearer = token. “scope” could make sense in a “WWW-Authenticate: O= Auth2 ...” response header as long as other necessary details such as= an authorization URI were also provided. Dropping “scope” and = “error_description” (as the error should be described in the re= sponse body) would eliminate these encoding problems.

=

 =

 

If the group rea= lly wants to keep “scope”, I don’t think RFC 5987 is a go= od solution. RFC 5987 might have been ok for adding internationalization su= pport to long-standing ASCII-only fields in a world of multiple character s= ets – but none of that applies here. Having to change the field name = from “scope” to “scope*” when you have a non-ASCII = value is the biggest flaw.

 

The simplest solution is to explicitly restrict= scope values to some subset of printable ASCII in OAuth2 Core. Not being a= ble to support Unicode in a new protocol is slightly disappointing, but I c= an live with it.

 

My preferred escaping solution would be a JSON string, U= TF-8 encoded: json.org, RFC 4627; value in double-quotes; slash is the esca= pe char; supports Unicode; eg scope=3D"coll\u00E8gues". This is b= ackward-compatible with HTTP’s quoted-string syntax. It is forward-co= mpatible with UTF-8 HTTP headers (if that occurs). JSON is well-supported (= and required for other OAuth2 exchanges). [I might suggest json-string to t= he httpbis group as a global replacement for quoted-string (or at least as = a recommendation for new fields).]

 

--

James Manger

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of <= /b>Mike Jones
Sent: Friday, 30 September 2011 4:53 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Possible alternative resolu= tion to issue 26

 

There seems to now= be more working group interest in representing non-ASCII characters in sco= pe strings than had previously been in evidence.  If we decide to defi= ne a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for = Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the= clear choice.  I’d be interested in knowing how many working gr= oup members are in favor of either:

 

1.  Using RFC 5987 encoding for the scope parameter.

2.  Continu= ing to specify no non-ASCII encoding for scope parameter values.=

 =

As a related issue, some workin= g group members have objected to specifying UTF-8 encoding of the error_des= cription value, requesting the use of RFC 5987 encoding instead.  I= 217;d also be interested in knowing how many working group members are in f= avor of either:

 

A.&nb= sp; Using RFC 5987 encoding for the error_description parameter.=

B.  Continuing to s= pecify UTF-8 encoding for the error_description parameter.

 

(As editor, I would make the observat= ion that if we choose RFC 5987 encoding for either of these parameters, it = would be logical to do so for the other one as well.)

=

 

In the interest of finishing the specifica= tion in a way that meets everyone’s needs,

      &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   -- Mike

 

= --_000_255B9BB34FB7D647A506DC292726F6E1129015546CWSMSG3153Vsrv_-- From eran@hueniverse.com Sun Oct 2 08:53:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7703F21F8560 for ; Sun, 2 Oct 2011 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ijKyfZXSnhy for ; Sun, 2 Oct 2011 08:53:16 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id E49C921F8546 for ; Sun, 2 Oct 2011 08:53:15 -0700 (PDT) Received: (qmail 19142 invoked from network); 2 Oct 2011 15:56:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Oct 2011 15:56:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 2 Oct 2011 08:56:14 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , Mike Jones , "oauth@ietf.org" Date: Sun, 2 Oct 2011 08:56:13 -0700 Thread-Topic: Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gCGXHeAAApYSLA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452602A4D30@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.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_90C41DD21FB7C64BB94121FBBC2E723452602A4D30P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 15:53:18 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723452602A4D30P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with this analysis and its conclusions. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Sunday, October 02, 2011 5:51 AM To: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 The best solution is to drop the "scope" field from the "WWW-Authenticate: = Bearer ..." response header. "scope" is relevant to an OAuth2-core flow, no= t to presenting a bearer token. "scope" could make sense in a "WWW-Authenti= cate: OAuth2 ..." response header as long as other necessary details such a= s an authorization URI were also provided. Dropping "scope" and "error_desc= ription" (as the error should be described in the response body) would elim= inate these encoding problems. If the group really wants to keep "scope", I don't think RFC 5987 is a good= solution. RFC 5987 might have been ok for adding internationalization supp= ort to long-standing ASCII-only fields in a world of multiple character set= s - but none of that applies here. Having to change the field name from "sc= ope" to "scope*" when you have a non-ASCII value is the biggest flaw. The simplest solution is to explicitly restrict scope values to some subset= of printable ASCII in OAuth2 Core. Not being able to support Unicode in a = new protocol is slightly disappointing, but I can live with it. My preferred escaping solution would be a JSON string, UTF-8 encoded: json.= org, RFC 4627; value in double-quotes; slash is the escape char; supports U= nicode; eg scope=3D"coll\u00E8gues". This is backward-compatible with HTTP'= s quoted-string syntax. It is forward-compatible with UTF-8 HTTP headers (i= f that occurs). JSON is well-supported (and required for other OAuth2 excha= nges). [I might suggest json-string to the httpbis group as a global replac= ement for quoted-string (or at least as a recommendation for new fields).] -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Friday, 30 September 2011 4:53 AM To: oauth@ietf.org Subject: [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII= characters in scope strings than had previously been in evidence. If we d= ecide to define a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hy= pertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the c= lear choice. I'd be interested in knowing how many working group members a= re in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying = UTF-8 encoding of the error_description value, requesting the use of RFC 59= 87 encoding instead. I'd also be interested in knowing how many working gr= oup members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description paramete= r. (As editor, I would make the observation that if we choose RFC 5987 encodin= g for either of these parameters, it would be logical to do so for the othe= r one as well.) In the interest of finishing the specification in a way that meets everyone= 's needs, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E723452602A4D30P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with this analysis and its conclusions.

 

EHL

 =

From: oauth-boun= ces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, Ja= mes H
Sent: Sunday, October 02, 2011 5:51 AM
To: Mike J= ones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Possible alternative= resolution to issue 26

 

The best solution is to drop the “scope” field fro= m the “WWW-Authenticate: Bearer ...” response header. “sc= ope” is relevant to an OAuth2-core flow, not to presenting a bearer t= oken. “scope” could make sense in a “WWW-Authenticate: OA= uth2 ...” response header as long as other necessary details such as = an authorization URI were also provided. Dropping “scope” and &= #8220;error_description” (as the error should be described in the res= ponse body) would eliminate these encoding problems.

<= p class=3DMsoNormal> <= /o:p>

 

If the group really wants to keep “scope”= , I don’t think RFC 5987 is a good solution. RFC 5987 might have been= ok for adding internationalization support to long-standing ASCII-only fie= lds in a world of multiple character sets – but none of that applies = here. Having to change the field name from “scope” to “sc= ope*” when you have a non-ASCII value is the biggest flaw.=

=  

The simplest solution is to explicitly restrict scope va= lues to some subset of printable ASCII in OAuth2 Core. Not being able to su= pport Unicode in a new protocol is slightly disappointing, but I can live w= ith it.

 

My preferred escaping solution would be= a JSON string, UTF-8 encoded: json.org, RFC 4627; value in double-quotes; = slash is the escape char; supports Unicode; eg scope=3D"coll\u00E8gues= ". This is backward-compatible with HTTP’s quoted-string syntax.= It is forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is= well-supported (and required for other OAuth2 exchanges). [I might suggest= json-string to the httpbis group as a global replacement for quoted-string= (or at least as a recommendation for new fields).]

 

--

James Manger

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike J= ones
Sent: Friday, 30 September 2011 4:53 AM
To: oauth@ietf.org
Subject: [OAUTH-WG= ] Possible alternative resolution to issue 26

 

There seems to now be more working group interest in repr= esenting non-ASCII characters in scope strings than had previously been in = evidence.  If we decide to define a standard representation for doing = so, using RFC 5987 (Char= acter Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Head= er Field Parameters) seems to be the clear choice.  I’d be inter= ested in knowing how many working group members are in favor of either:

 

1= .  Using RFC 5987 encoding for the scope parameter.

2.  Continuing to specify no non-ASCII encoding for s= cope parameter values.

 =

As a related issue, some working group members hav= e objected to specifying UTF-8 encoding of the error_description value, req= uesting the use of RFC 5987 encoding instead.  I’d also be inter= ested in knowing how many working group members are in favor of either:

 

A= .  Using RFC 5987 encoding for the error_description parameter.

B.  Continuing to specify UTF-8 encoding = for the error_description parameter.

 

(As editor, I would make the observa= tion that if we choose RFC 5987 encoding for either of these parameters, it= would be logical to do so for the other one as well.)

 

In the interest of= finishing the specification in a way that meets everyone’s needs,

       =             &nb= sp;            =             &nb= sp;            =    -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723452602A4D30P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Sun Oct 2 22:58:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A390321F8669 for ; Sun, 2 Oct 2011 22:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.366 X-Spam-Level: X-Spam-Status: No, score=-17.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsmIWQ+Ju4JW for ; Sun, 2 Oct 2011 22:58:06 -0700 (PDT) Received: from nm27-vm0.bullet.mail.sp2.yahoo.com (nm27-vm0.bullet.mail.sp2.yahoo.com [98.139.91.232]) by ietfa.amsl.com (Postfix) with SMTP id 931F021F84D6 for ; Sun, 2 Oct 2011 22:58:06 -0700 (PDT) Received: from [98.139.91.66] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 03 Oct 2011 06:01:04 -0000 Received: from [98.139.91.53] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 03 Oct 2011 06:01:04 -0000 Received: from [127.0.0.1] by omp1053.mail.sp2.yahoo.com with NNFMP; 03 Oct 2011 06:01:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 273729.32236.bm@omp1053.mail.sp2.yahoo.com Received: (qmail 93803 invoked by uid 60001); 3 Oct 2011 06:01:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1317621663; bh=ZV+0HQflwhcPuaD0YoES/0J0dLPUyoZLMYA4Hjx2omE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Xf0A1vx7w1DqFDG9DnqdEN3IebKCR2BKbZN59FBA3MWKsTtwTRUvmDkTCVIOmmA3WAG5hW+Eif4wwdI8LPGkLXiUtbA4/BDD8ZiO+8NIWg28NA7Bgru6pbYHpNJZ9LLErYbP2caG10JBUwz4rYsoRfv1Jl1bsch0CLGZtIXq8w8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=SF04d5LcrSIp+qjCtNypZezSsa0O44Qe1cqKpLIE+GI1MdXSI8AlfntqeH43vL4c8eK0Kyw7Vrnnob25gJky0uM6VU1wWuigpInNr0kKbjWGyJHBKmwC1Bvfo4DvlzfqgeaxApXO6WRe4jwaBuc5RrjPN7dAoK0kumpTNWhyiDw=; X-YMail-OSG: edAEQqYVM1niHFyzp_AVCc56ytcfX1l3TTaBZXD6oxZL4FY jcY.T9Tx6CPBFERZp0.4q2SF93rO49GVly16w1QgDgs3PoIZ2RRYH9AvgUFX gHyy_rsUZGMkLs8WgAzk9RttHHEwGToiBsBlLzmxZRPeo0lTWOa71y78OsXX R.N4nSMQqZZJszl7.aQ0CnTtNgQf6AtMxhUB.mLVt8E1n_yZAnLBqBOHwsQl HO8OGIA2d6F0HsZ_hCQR6u8MAQCYvxfXMCFBiUT9fPNj7wVzcqw6j6qb0x20 62vgvhL2NTX4OtPERVvCCJXuXmVCry3WBFNBHrXjgvZUgjj9d4gHItciupW0 wQKnjEw7zK0yrL5KeMKXzlKd.5nt258FbMZtXlnE.LegrCmXmnmI3vHdngu3 C0rkN2g_pLyKOT9UNn9AMYrY7UNKxUhl.w1qOkg-- Received: from [99.31.212.42] by web31813.mail.mud.yahoo.com via HTTP; Sun, 02 Oct 2011 23:01:03 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> Message-ID: <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Sun, 2 Oct 2011 23:01:03 -0700 (PDT) From: William Mills To: "Manger, James H" , Mike Jones , "oauth@ietf.org" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-328642290-1317621663=:4810" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 05:58:07 -0000 --0-328642290-1317621663=:4810 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't like dropping scope from the WWW-Authenticate responses, because my= current discovery usage requires scope to be returned so that it can be pa= ssed to the auth server if the user is forced to re-authenticate.=0A=0A+1 f= or "explicitly restrict scope values to some subset of printable ASCII in O= Auth2 Core. Not being able to support Unicode in a new protocol is slightly= =0Adisappointing, but I can live with it."=0A=0A=0A=0A=0A_________________= _______________=0AFrom: "Manger, James H" = =0ATo: Mike Jones ; "oauth@ietf.org" =0ASent: Sunday, October 2, 2011 5:50 AM=0ASubject: Re: [OAUTH-WG] P= ossible alternative resolution to issue 26=0A=0A=0AThe best solution is to = drop the =E2=80=9Cscope=E2=80=9D field from the =E2=80=9CWWW-Authenticate: = Bearer ...=E2=80=9D response header. =E2=80=9Cscope=E2=80=9D is relevant to= an OAuth2-core flow, not to presenting a bearer token. =E2=80=9Cscope=E2= =80=9D could make sense in a =E2=80=9CWWW-Authenticate: OAuth2 ...=E2=80=9D= response header as long as other necessary details such as an authorizatio= n URI were also provided. Dropping =E2=80=9Cscope=E2=80=9D and =E2=80=9Cerr= or_description=E2=80=9D (as the error should be described in the response b= ody) would eliminate these encoding problems.=0A=C2=A0=0A=C2=A0=0AIf the gr= oup really wants to keep =E2=80=9Cscope=E2=80=9D, I don=E2=80=99t think RFC= 5987 is a good solution. RFC 5987 might have been ok for adding internatio= nalization support to long-standing ASCII-only fields in a world of multipl= e character sets =E2=80=93 but none of that applies here. Having to change = the field name from =E2=80=9Cscope=E2=80=9D to =E2=80=9Cscope*=E2=80=9D whe= n you have a non-ASCII value is the biggest flaw.=0A=C2=A0=0AThe simplest s= olution is to explicitly restrict scope values to some subset of printable = ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol i= s slightly disappointing, but I can live with it.=0A=C2=A0=0AMy preferred e= scaping solution would be a JSON string, UTF-8 encoded: json.org, RFC 4627;= value in double-quotes; slash is the escape char; supports Unicode; eg sco= pe=3D"coll\u00E8gues". This is backward-compatible with HTTP=E2=80=99s quot= ed-string syntax. It is forward-compatible with UTF-8 HTTP headers (if that= occurs). JSON is well-supported (and required for other OAuth2 exchanges).= [I might suggest json-string to the httpbis group as a global replacement = for quoted-string (or at least as a recommendation for new fields).]=0A=C2= =A0=0A--=0AJames Manger=0A=C2=A0=0AFrom:oauth-bounces@ietf.org [mailto:oaut= h-bounces@ietf.org] On Behalf Of Mike Jones=0ASent: Friday, 30 September 20= 11 4:53 AM=0ATo: oauth@ietf.org=0ASubject: [OAUTH-WG] Possible alternative = resolution to issue 26=0A=C2=A0=0AThere seems to now be more working group = interest in representing non-ASCII characters in scope strings than had pre= viously been in evidence.=C2=A0 If we decide to define a standard represent= ation for doing so, using RFC 5987 (Character Set and Language Encoding for= Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be th= e clear choice.=C2=A0 I=E2=80=99d be interested in knowing how many working= group members are in favor of either:=0A=C2=A0=0A1.=C2=A0 Using RFC 5987 e= ncoding for the scope parameter.=0A2.=C2=A0 Continuing to specify no non-AS= CII encoding for scope parameter values.=0A=C2=A0=0AAs a related issue, som= e working group members have objected to specifying UTF-8 encoding of the e= rror_description value, requesting the use of RFC 5987 encoding instead.=C2= =A0 I=E2=80=99d also be interested in knowing how many working group member= s are in favor of either:=0A=C2=A0=0AA.=C2=A0 Using RFC 5987 encoding for t= he error_description parameter.=0AB.=C2=A0 Continuing to specify UTF-8 enco= ding for the error_description parameter.=0A=C2=A0=0A(As editor, I would ma= ke the observation that if we choose RFC 5987 encoding for either of these = parameters, it would be logical to do so for the other one as well.)=0A=C2= =A0=0AIn the interest of finishing the specification in a way that meets ev= eryone=E2=80=99s needs,=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike=0A=C2=A0=0A_______________________________________________= =0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/oauth --0-328642290-1317621663=:4810 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't like dropping scope from the WWW-Authenticate responses, because = my current discovery usage requires scope to be returned so that it can be = passed to the auth server if the user is forced to re-authenticate.

+1 for "explicitly= =0A restrict scope values to some subset of printable ASCII in OAuth2 Core.= =0A Not being able to support Unicode in a new protocol is slightly =0Adisa= ppointing, but I can live with it."


From: "Manger, James H" <James.H.Mange= r@team.telstra.com>
To:<= /b> Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.org" <oa= uth@ietf.org>
Sent: = Sunday, October 2, 2011 5:50 AM
Su= bject: Re: [OAUTH-WG] Possible alternative resolution to issue 2= 6

=0A
The best solution is to drop the =E2=80=9Cscope=E2=80=9D field from= the =E2=80=9CWWW-Authenticate: Bearer ...=E2=80=9D response header. =E2=80= =9Cscope=E2=80=9D is relevant to an OAuth2-core flow, not to presenting a b= earer token. =E2=80=9Cscope=E2=80=9D could make sense in a =E2=80=9CWWW-Aut= henticate: OAuth2 ...=E2=80=9D response header as long as other necessary d= etails such as an authorization URI were also provided. Dropping =E2=80=9Cs= cope=E2=80=9D and =E2=80=9Cerror_description=E2=80=9D (as the error should = be described in the response body) would eliminate these encoding problems.=
 
 
If the group really wants to keep =E2=80= =9Cscope=E2=80=9D, I don=E2=80=99t think RFC 5987 is a good solution. RFC 5987 might have been ok for adding internationalization support to long-st= anding ASCII-only fields in a world of multiple character sets =E2=80=93 bu= t none of that applies here. Having to change the field name from =E2=80=9C= scope=E2=80=9D to =E2=80=9Cscope*=E2=80=9D when you have a non-ASCII value = is the biggest flaw.
 
The simplest solution is to explicit= ly restrict scope values to some subset of printable ASCII in OAuth2 Core. = Not being able to support Unicode in a new protocol is slightly disappointi= ng, but I can live with it.
 
My preferred escaping solutio= n would be a JSON string, UTF-8 encoded: json.org, RFC 4627; value in double-quotes; slash is the escape char; supports Unicode; eg scope=3D"= coll\u00E8gues". This is backward-compatible with HTTP=E2=80=99s quoted-str= ing syntax. It is forward-compatible with UTF-8 HTTP headers (if that occur= s). JSON is well-supported (and required for other OAuth2 exchanges). [I mi= ght suggest json-string to the httpbis group as a global replacement for qu= oted-string (or at least as a recommendation for new fields).]
=
 =
--
James Manger
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@= ietf.org] On Behalf Of Mike Jones
Sent: Friday, 30 Septemb= er 2011 4:53 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] = Possible alternative resolution to issue 26
 
There seems to now be more working group interest= in representing non-ASCII characters in scope strings than had previously = been in evidence.  If we decide to define a standard representation fo= r doing so, using RFC 5987 (Character Set and Language Encoding = for Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be= the clear choice.  I=E2=80=99d be interested in knowing how many working group = members are in favor of either:
 
1.  Using RFC 5987 encoding for the scop= e parameter.
2.  Continuing to specify no non-ASCII encoding for scope para= meter values.
 
As a related issue, some working group members have objected = to specifying UTF-8 encoding of the error_description value, requesting the= use of RFC 5987 encoding instead.  I=E2=80=99d also be interested in = knowing how many working group members are in favor of either:
=
 
A.  Using RFC 59= 87 encoding for the error_description parameter.
B.  Continuing to specify = UTF-8 encoding for the error_description parameter.
 
(As editor, I would make= the observation that if we choose RFC 5987 encoding for either of these pa= rameters, it would be logical to do so for the other one as well.)
 
In the int= erest of finishing the specification in a way that meets everyone=E2=80=99s= needs,
          = ;            &n= bsp;            = ;            &n= bsp;            -- M= ike
=  

__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth


--0-328642290-1317621663=:4810-- From chet.ensign@oasis-open.org Sun Oct 2 20:42:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F27521F84B6; Sun, 2 Oct 2011 20:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.288 X-Spam-Level: X-Spam-Status: No, score=-4.288 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P0awav8EqSi; Sun, 2 Oct 2011 20:42:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 013FF21F84B3; Sun, 2 Oct 2011 20:42:35 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5220032bka.31 for ; Sun, 02 Oct 2011 20:45:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.138.218 with SMTP id b26mr6035419bku.28.1317613533735; Sun, 02 Oct 2011 20:45:33 -0700 (PDT) Received: by 10.205.82.193 with HTTP; Sun, 2 Oct 2011 20:45:33 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 Oct 2011 23:45:33 -0400 Message-ID: From: Chet Ensign To: http-state@ietf.org, oauth@ietf.org, public-xmlsec-discuss@w3.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 03 Oct 2011 06:30:22 -0700 Cc: Hal Lockhart Subject: [OAUTH-WG] 15-day Public Review for SAML 2.0 Session Token Profile Version 1.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 03:42:37 -0000 The OASIS Security Services TC [1] members have produced an updated Committee Specification Draft (CSD) and submitted this specification for 15-day public review: SAML 2.0 Session Token Profile Version 1.0 Committee Specification Draft 03 / Public Review Draft 03 11 August 2011 Specification Overview: Web Servers and Application Servers generally maintain security state information for currently active users, particularly once some type of authentication has occurred. This specification defines a format for communicating such security session state based on the OASIS SAML Assertion. It also specifies two different mechanisms for communicating this information between servers via a standard Web browser. Public Review Period: The public review starts Monday, 3 October 2011 and ends 18 October 2011. The specification was previously submitted for a 15-day public review on 11 July 2011 [2]. This 15-day review is limited in scope to changes made from the previous review. Changes are highlighted in the diff-marked PDF file included in the package. This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. URIs: The complete package of the prose specification document and related files are available in the ZIP distribution file at: http://www.oasis-open.org/committees/download.php/43741/saml-session-token-v1.0-csprd03.zip Additional information about the specification and the OASIS Security Services TC may be found at the TC's public home page located at: http://www.oasis-open.org/committees/security/ Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be accessed via the button labeled "Send A Comment" at the top of the TC public home page, or directly at: http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=security Feedback submitted by TC non-members for this work and for other work of this TC is publicly archived and can be viewed at: http://lists.oasis-open.org/archives/security-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of SAML 2.0 Session Token Profile Version 1.0, we call your attention to the OASIS IPR Policy [3] applicable especially [4] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. ========== Additional references: [1] OASIS Security Services TC http://www.oasis-open.org/committees/security/ [2] Previous public review (11 July 2011 through 26 July 2011): http://lists.oasis-open.org/archives/security-services/201107/msg00008.html [3] http://www.oasis-open.org/who/intellectualproperty.php [4] http://www.oasis-open.org/committees/security/ipr.php http://www.oasis-open.org/policies-guidelines/ipr#types_obligations RF on RAND Mode Best Regards, /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 From Michael.Jones@microsoft.com Mon Oct 3 18:52:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8B521F8DEB for ; Mon, 3 Oct 2011 18:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDV3GAhHMg1d for ; Mon, 3 Oct 2011 18:52:55 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 42D6321F8DC1 for ; Mon, 3 Oct 2011 18:52:55 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 3 Oct 2011 18:55:19 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0339.002; Mon, 3 Oct 2011 18:55:18 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gCGXHeAADaHZIAAGpwHEA== Date: Tue, 4 Oct 2011 01:55:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C226298TK5EX14MBXC284r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 01:52:56 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C226298TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgZWRpdG9yLCBiYXNlZCB1cG9uIEphbWVz4oCZIGlucHV0LCBJ4oCZZCBsaWtlIHRvIGV4cGFu ZCB0aGUgc2V0IG9mIGNob2ljZXMgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGNvbnNpZGVyIGJ5 IGFkZGluZyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgSlNPTiBzdHJpbmcgZW5jb2RpbmdzIGZv ciBzY29wZSBhbmQgZXJyb3JfZGVzY3JpcHRpb24gd2hlcmUgdGhlIGNoYXJhY3RlcnMgdXNlZCBm b3IgdGhlIGVuY29kaW5nIGFyZSByZXN0cmljdGVkIHRvIHRoZSBzZXQgb2YgNy1iaXQgQVNDSUkg Y2hhcmFjdGVycyBjb21wYXRpYmxlIHdpdGggdGhlIEhUVFBiaXMgYW5kIFJGQyAyNjE3IHBhcmFt ZXRlciBzeW50YXhlcy4NCg0KMS4gIFVzaW5nIFJGQyA1OTg3IGVuY29kaW5nIGZvciB0aGUgc2Nv cGUgcGFyYW1ldGVyLg0KMi4gIENvbnRpbnVpbmcgdG8gc3BlY2lmeSBubyBub24tQVNDSUkgZW5j b2RpbmcgZm9yIHNjb3BlIHBhcmFtZXRlciB2YWx1ZXMuDQozLiAgVXNpbmcgSlNPTiBzdHJpbmcg ZW5jb2RpbmcgZm9yIHRoZSBzY29wZSBwYXJhbWV0ZXIuDQoNCkEuICBVc2luZyBSRkMgNTk4NyBl bmNvZGluZyBmb3IgdGhlIGVycm9yX2Rlc2NyaXB0aW9uIHBhcmFtZXRlci4NCkIuICBDb250aW51 aW5nIHRvIHNwZWNpZnkgVVRGLTggZW5jb2RpbmcgZm9yIHRoZSBlcnJvcl9kZXNjcmlwdGlvbiBw YXJhbWV0ZXIuDQpDLiAgVXNpbmcgSlNPTiBzdHJpbmcgZW5jb2RpbmcgZm9yIHRoZSBlcnJvcl9k ZXNjcmlwdGlvbiBwYXJhbWV0ZXIuDQoNCkFzIGFuIGluZGl2aWR1YWwsIEnigJltIHN5bXBhdGhl dGljIHRvIHRoZSBhcmd1bWVudCB0aGF0IFJGQyA1OTg3ICh3aXRoIOKAnHNjb3BlKuKAnSBhbmQg bGFuZ3VhZ2UgdGFncyBldGMuKSBpcyBvdmVya2lsbCBmb3IgT0F1dGggaW1wbGVtZW50YXRpb25z LCB3aGVyZSBuZWl0aGVyIG9mIHRoZSBzZXRzIG9mIHN0cmluZ3MgaXMgaW50ZW5kZWQgdG8gYmUg cHJlc2VudGVkIHRvIGVuZC11c2Vycy4gIEhlbmNlLCB0aGUgcG9zc2libGUgYXR0cmFjdGl2ZW5l c3Mgb2Ygb3B0aW9ucyAzIGFuZCBDLg0KDQpUaG91Z2h0cyBmcm9tIG90aGVycz8NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tIE1pa2UNCg0KRnJvbTogV2lsbGlhbSBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMu Y29tXQ0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDAyLCAyMDExIDExOjAxIFBNDQpUbzogTWFuZ2Vy LCBKYW1lcyBIOyBNaWtlIEpvbmVzOyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gUG9zc2libGUgYWx0ZXJuYXRpdmUgcmVzb2x1dGlvbiB0byBpc3N1ZSAyNg0KDQpJIGRv bid0IGxpa2UgZHJvcHBpbmcgc2NvcGUgZnJvbSB0aGUgV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25z ZXMsIGJlY2F1c2UgbXkgY3VycmVudCBkaXNjb3ZlcnkgdXNhZ2UgcmVxdWlyZXMgc2NvcGUgdG8g YmUgcmV0dXJuZWQgc28gdGhhdCBpdCBjYW4gYmUgcGFzc2VkIHRvIHRoZSBhdXRoIHNlcnZlciBp ZiB0aGUgdXNlciBpcyBmb3JjZWQgdG8gcmUtYXV0aGVudGljYXRlLg0KDQorMSBmb3IgImV4cGxp Y2l0bHkgcmVzdHJpY3Qgc2NvcGUgdmFsdWVzIHRvIHNvbWUgc3Vic2V0IG9mIHByaW50YWJsZSBB U0NJSSBpbiBPQXV0aDIgQ29yZS4gTm90IGJlaW5nIGFibGUgdG8gc3VwcG9ydCBVbmljb2RlIGlu IGEgbmV3IHByb3RvY29sIGlzIHNsaWdodGx5IGRpc2FwcG9pbnRpbmcsIGJ1dCBJIGNhbiBsaXZl IHdpdGggaXQuIg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogIk1h bmdlciwgSmFtZXMgSCIgPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkph bWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+Pg0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47 ICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFN1bmRheSwgT2N0b2JlciAyLCAyMDExIDU6 NTAgQU0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFBvc3NpYmxlIGFsdGVybmF0aXZlIHJlc29s dXRpb24gdG8gaXNzdWUgMjYNClRoZSBiZXN0IHNvbHV0aW9uIGlzIHRvIGRyb3AgdGhlIOKAnHNj b3Bl4oCdIGZpZWxkIGZyb20gdGhlIOKAnFdXVy1BdXRoZW50aWNhdGU6IEJlYXJlciAuLi7igJ0g cmVzcG9uc2UgaGVhZGVyLiDigJxzY29wZeKAnSBpcyByZWxldmFudCB0byBhbiBPQXV0aDItY29y ZSBmbG93LCBub3QgdG8gcHJlc2VudGluZyBhIGJlYXJlciB0b2tlbi4g4oCcc2NvcGXigJ0gY291 bGQgbWFrZSBzZW5zZSBpbiBhIOKAnFdXVy1BdXRoZW50aWNhdGU6IE9BdXRoMiAuLi7igJ0gcmVz cG9uc2UgaGVhZGVyIGFzIGxvbmcgYXMgb3RoZXIgbmVjZXNzYXJ5IGRldGFpbHMgc3VjaCBhcyBh biBhdXRob3JpemF0aW9uIFVSSSB3ZXJlIGFsc28gcHJvdmlkZWQuIERyb3BwaW5nIOKAnHNjb3Bl 4oCdIGFuZCDigJxlcnJvcl9kZXNjcmlwdGlvbuKAnSAoYXMgdGhlIGVycm9yIHNob3VsZCBiZSBk ZXNjcmliZWQgaW4gdGhlIHJlc3BvbnNlIGJvZHkpIHdvdWxkIGVsaW1pbmF0ZSB0aGVzZSBlbmNv ZGluZyBwcm9ibGVtcy4NCg0KDQpJZiB0aGUgZ3JvdXAgcmVhbGx5IHdhbnRzIHRvIGtlZXAg4oCc c2NvcGXigJ0sIEkgZG9u4oCZdCB0aGluayBSRkMgNTk4NyBpcyBhIGdvb2Qgc29sdXRpb24uIFJG QyA1OTg3IG1pZ2h0IGhhdmUgYmVlbiBvayBmb3IgYWRkaW5nIGludGVybmF0aW9uYWxpemF0aW9u IHN1cHBvcnQgdG8gbG9uZy1zdGFuZGluZyBBU0NJSS1vbmx5IGZpZWxkcyBpbiBhIHdvcmxkIG9m IG11bHRpcGxlIGNoYXJhY3RlciBzZXRzIOKAkyBidXQgbm9uZSBvZiB0aGF0IGFwcGxpZXMgaGVy ZS4gSGF2aW5nIHRvIGNoYW5nZSB0aGUgZmllbGQgbmFtZSBmcm9tIOKAnHNjb3Bl4oCdIHRvIOKA nHNjb3BlKuKAnSB3aGVuIHlvdSBoYXZlIGEgbm9uLUFTQ0lJIHZhbHVlIGlzIHRoZSBiaWdnZXN0 IGZsYXcuDQoNClRoZSBzaW1wbGVzdCBzb2x1dGlvbiBpcyB0byBleHBsaWNpdGx5IHJlc3RyaWN0 IHNjb3BlIHZhbHVlcyB0byBzb21lIHN1YnNldCBvZiBwcmludGFibGUgQVNDSUkgaW4gT0F1dGgy IENvcmUuIE5vdCBiZWluZyBhYmxlIHRvIHN1cHBvcnQgVW5pY29kZSBpbiBhIG5ldyBwcm90b2Nv bCBpcyBzbGlnaHRseSBkaXNhcHBvaW50aW5nLCBidXQgSSBjYW4gbGl2ZSB3aXRoIGl0Lg0KDQpN eSBwcmVmZXJyZWQgZXNjYXBpbmcgc29sdXRpb24gd291bGQgYmUgYSBKU09OIHN0cmluZywgVVRG LTggZW5jb2RlZDoganNvbi5vcmc8aHR0cDovL2pzb24ub3JnPiwgUkZDIDQ2Mjc7IHZhbHVlIGlu IGRvdWJsZS1xdW90ZXM7IHNsYXNoIGlzIHRoZSBlc2NhcGUgY2hhcjsgc3VwcG9ydHMgVW5pY29k ZTsgZWcgc2NvcGU9ImNvbGxcdTAwRThndWVzIi4gVGhpcyBpcyBiYWNrd2FyZC1jb21wYXRpYmxl IHdpdGggSFRUUOKAmXMgcXVvdGVkLXN0cmluZyBzeW50YXguIEl0IGlzIGZvcndhcmQtY29tcGF0 aWJsZSB3aXRoIFVURi04IEhUVFAgaGVhZGVycyAoaWYgdGhhdCBvY2N1cnMpLiBKU09OIGlzIHdl bGwtc3VwcG9ydGVkIChhbmQgcmVxdWlyZWQgZm9yIG90aGVyIE9BdXRoMiBleGNoYW5nZXMpLiBb SSBtaWdodCBzdWdnZXN0IGpzb24tc3RyaW5nIHRvIHRoZSBodHRwYmlzIGdyb3VwIGFzIGEgZ2xv YmFsIHJlcGxhY2VtZW50IGZvciBxdW90ZWQtc3RyaW5nIChvciBhdCBsZWFzdCBhcyBhIHJlY29t bWVuZGF0aW9uIGZvciBuZXcgZmllbGRzKS5dDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTog b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnXT4gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6IEZyaWRheSwgMzAgU2Vw dGVtYmVyIDIwMTEgNDo1MyBBTQ0KVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4NClN1YmplY3Q6IFtPQVVUSC1XR10gUG9zc2libGUgYWx0ZXJuYXRpdmUgcmVzb2x1dGlv biB0byBpc3N1ZSAyNg0KDQpUaGVyZSBzZWVtcyB0byBub3cgYmUgbW9yZSB3b3JraW5nIGdyb3Vw IGludGVyZXN0IGluIHJlcHJlc2VudGluZyBub24tQVNDSUkgY2hhcmFjdGVycyBpbiBzY29wZSBz dHJpbmdzIHRoYW4gaGFkIHByZXZpb3VzbHkgYmVlbiBpbiBldmlkZW5jZS4gIElmIHdlIGRlY2lk ZSB0byBkZWZpbmUgYSBzdGFuZGFyZCByZXByZXNlbnRhdGlvbiBmb3IgZG9pbmcgc28sIHVzaW5n IFJGQyA1OTg3PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU5ODc+IChDaGFyYWN0ZXIg U2V0IGFuZCBMYW5ndWFnZSBFbmNvZGluZyBmb3IgSHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29s IChIVFRQKSBIZWFkZXIgRmllbGQgUGFyYW1ldGVycykgc2VlbXMgdG8gYmUgdGhlIGNsZWFyIGNo b2ljZS4gIEnigJlkIGJlIGludGVyZXN0ZWQgaW4ga25vd2luZyBob3cgbWFueSB3b3JraW5nIGdy b3VwIG1lbWJlcnMgYXJlIGluIGZhdm9yIG9mIGVpdGhlcjoNCg0KMS4gIFVzaW5nIFJGQyA1OTg3 IGVuY29kaW5nIGZvciB0aGUgc2NvcGUgcGFyYW1ldGVyLg0KMi4gIENvbnRpbnVpbmcgdG8gc3Bl Y2lmeSBubyBub24tQVNDSUkgZW5jb2RpbmcgZm9yIHNjb3BlIHBhcmFtZXRlciB2YWx1ZXMuDQoN CkFzIGEgcmVsYXRlZCBpc3N1ZSwgc29tZSB3b3JraW5nIGdyb3VwIG1lbWJlcnMgaGF2ZSBvYmpl Y3RlZCB0byBzcGVjaWZ5aW5nIFVURi04IGVuY29kaW5nIG9mIHRoZSBlcnJvcl9kZXNjcmlwdGlv biB2YWx1ZSwgcmVxdWVzdGluZyB0aGUgdXNlIG9mIFJGQyA1OTg3IGVuY29kaW5nIGluc3RlYWQu ICBJ4oCZZCBhbHNvIGJlIGludGVyZXN0ZWQgaW4ga25vd2luZyBob3cgbWFueSB3b3JraW5nIGdy b3VwIG1lbWJlcnMgYXJlIGluIGZhdm9yIG9mIGVpdGhlcjoNCg0KQS4gIFVzaW5nIFJGQyA1OTg3 IGVuY29kaW5nIGZvciB0aGUgZXJyb3JfZGVzY3JpcHRpb24gcGFyYW1ldGVyLg0KQi4gIENvbnRp bnVpbmcgdG8gc3BlY2lmeSBVVEYtOCBlbmNvZGluZyBmb3IgdGhlIGVycm9yX2Rlc2NyaXB0aW9u IHBhcmFtZXRlci4NCg0KKEFzIGVkaXRvciwgSSB3b3VsZCBtYWtlIHRoZSBvYnNlcnZhdGlvbiB0 aGF0IGlmIHdlIGNob29zZSBSRkMgNTk4NyBlbmNvZGluZyBmb3IgZWl0aGVyIG9mIHRoZXNlIHBh cmFtZXRlcnMsIGl0IHdvdWxkIGJlIGxvZ2ljYWwgdG8gZG8gc28gZm9yIHRoZSBvdGhlciBvbmUg YXMgd2VsbC4pDQoNCkluIHRoZSBpbnRlcmVzdCBvZiBmaW5pc2hpbmcgdGhlIHNwZWNpZmljYXRp b24gaW4gYSB3YXkgdGhhdCBtZWV0cyBldmVyeW9uZeKAmXMgbmVlZHMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739435C226298TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLnlpdjEzNzk0MDI1NW1zb25vcm1hbCwgbGkueWl2 MTM3OTQwMjU1bXNvbm9ybWFsLCBkaXYueWl2MTM3OTQwMjU1bXNvbm9ybWFsDQoJe21zby1zdHls ZS1uYW1lOnlpdjEzNzk0MDI1NW1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KcC55aXYxMzc5NDAyNTVtc29jaHBkZWZhdWx0LCBsaS55aXYxMzc5 NDAyNTVtc29jaHBkZWZhdWx0LCBkaXYueWl2MTM3OTQwMjU1bXNvY2hwZGVmYXVsdA0KCXttc28t c3R5bGUtbmFtZTp5aXYxMzc5NDAyNTVtc29jaHBkZWZhdWx0Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjEzNzk0MDI1NW1zb2h5cGVybGluaw0K CXttc28tc3R5bGUtbmFtZTp5aXYxMzc5NDAyNTVtc29oeXBlcmxpbms7fQ0Kc3Bhbi55aXYxMzc5 NDAyNTVtc29oeXBlcmxpbmtmb2xsb3dlZA0KCXttc28tc3R5bGUtbmFtZTp5aXYxMzc5NDAyNTVt c29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjEzNzk0MDI1NWVtYWlsc3R5bGUxNw0KCXtt c28tc3R5bGUtbmFtZTp5aXYxMzc5NDAyNTVlbWFpbHN0eWxlMTc7fQ0Kc3Bhbi55aXYxMzc5NDAy NTVlbWFpbHN0eWxlMTgNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTM3OTQwMjU1ZW1haWxzdHlsZTE4 O30NCnAueWl2MTM3OTQwMjU1bXNvbm9ybWFsMSwgbGkueWl2MTM3OTQwMjU1bXNvbm9ybWFsMSwg ZGl2LnlpdjEzNzk0MDI1NW1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTM3OTQwMjU1 bXNvbm9ybWFsMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnNwYW4u eWl2MTM3OTQwMjU1bXNvaHlwZXJsaW5rMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMzc5NDAyNTVt c29oeXBlcmxpbmsxOw0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLnlpdjEzNzk0MDI1NW1zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXttc28tc3R5bGUtbmFt ZTp5aXYxMzc5NDAyNTVtc29oeXBlcmxpbmtmb2xsb3dlZDE7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYxMzc5NDAyNTVlbWFpbHN0eWxlMTcx DQoJe21zby1zdHlsZS1uYW1lOnlpdjEzNzk0MDI1NWVtYWlsc3R5bGUxNzE7DQoJZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLnlpdjEz Nzk0MDI1NWVtYWlsc3R5bGUxODENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTM3OTQwMjU1ZW1haWxz dHlsZTE4MTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnAueWl2MTM3OTQwMjU1bXNvY2hwZGVmYXVsdDEsIGxpLnlpdjEzNzk0MDI1NW1zb2No cGRlZmF1bHQxLCBkaXYueWl2MTM3OTQwMjU1bXNvY2hwZGVmYXVsdDENCgl7bXNvLXN0eWxlLW5h bWU6eWl2MTM3OTQwMjU1bXNvY2hwZGVmYXVsdDE7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzAwMjA2MDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj5BcyBl ZGl0b3IsIGJhc2VkIHVwb24gSmFtZXPigJkgaW5wdXQsIEnigJlkIGxpa2UgdG8gZXhwYW5kIHRo ZSBzZXQgb2YgY2hvaWNlcyBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gY29uc2lkZXIgYnkgYWRk aW5nIHRoZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBKU09OIHN0cmluZyBlbmNvZGluZ3MNCiBmb3Ig c2NvcGUgYW5kIGVycm9yX2Rlc2NyaXB0aW9uIHdoZXJlIHRoZSBjaGFyYWN0ZXJzIHVzZWQgZm9y IHRoZSBlbmNvZGluZyBhcmUgcmVzdHJpY3RlZCB0byB0aGUgc2V0IG9mIDctYml0IEFTQ0lJIGNo YXJhY3RlcnMgY29tcGF0aWJsZSB3aXRoIHRoZSBIVFRQYmlzIGFuZCBSRkMgMjYxNyBwYXJhbWV0 ZXIgc3ludGF4ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEuJm5ic3A7IFVzaW5nIFJGQyA1OTg3IGVu Y29kaW5nIGZvciB0aGUgc2NvcGUgcGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjIuJm5ic3A7IENvbnRpbnVpbmcgdG8gc3BlY2lmeSBubyBub24tQVNDSUkg ZW5jb2RpbmcgZm9yIHNjb3BlIHBhcmFtZXRlciB2YWx1ZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+My4mbmJzcDsgVXNpbmcgSlNPTiBzdHJpbmcgZW5jb2RpbmcgZm9y IHRoZSBzY29wZSBwYXJhbWV0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QS4mbmJzcDsg VXNpbmcgUkZDIDU5ODcgZW5jb2RpbmcgZm9yIHRoZSBlcnJvcl9kZXNjcmlwdGlvbiBwYXJhbWV0 ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Qi4mbmJzcDsgQ29udGlu dWluZyB0byBzcGVjaWZ5IFVURi04IGVuY29kaW5nIGZvciB0aGUgZXJyb3JfZGVzY3JpcHRpb24g cGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkMuJm5ic3A7 IFVzaW5nIEpTT04gc3RyaW5nIGVuY29kaW5nIGZvciB0aGUgZXJyb3JfZGVzY3JpcHRpb24gcGFy YW1ldGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwMjA2MCI+QXMgYW4gaW5kaXZpZHVhbCwgSeKAmW0gc3ltcGF0aGV0aWMgdG8g dGhlIGFyZ3VtZW50IHRoYXQgUkZDIDU5ODcgKHdpdGgg4oCcc2NvcGUq4oCdIGFuZCBsYW5ndWFn ZSB0YWdzIGV0Yy4pIGlzIG92ZXJraWxsIGZvciBPQXV0aCBpbXBsZW1lbnRhdGlvbnMsIHdoZXJl IG5laXRoZXINCiBvZiB0aGUgc2V0cyBvZiBzdHJpbmdzIGlzIGludGVuZGVkIHRvIGJlIHByZXNl bnRlZCB0byBlbmQtdXNlcnMuJm5ic3A7IEhlbmNlLCB0aGUgcG9zc2libGUgYXR0cmFjdGl2ZW5l c3Mgb2Ygb3B0aW9ucyAzIGFuZCBDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGhvdWdodHMgZnJvbSBvdGhlcnM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFdpbGxpYW0gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28taW5jLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIgMDIsIDIwMTEgMTE6MDEgUE08 YnI+DQo8Yj5Ubzo8L2I+IE1hbmdlciwgSmFtZXMgSDsgTWlrZSBKb25lczsgb2F1dGhAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUG9zc2libGUgYWx0ZXJuYXRp dmUgcmVzb2x1dGlvbiB0byBpc3N1ZSAyNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+SSBkb24ndCBsaWtlIGRyb3BwaW5nIHNjb3BlIGZyb20gdGhlIFdXVy1BdXRoZW50aWNhdGUg cmVzcG9uc2VzLCBiZWNhdXNlIG15IGN1cnJlbnQgZGlzY292ZXJ5IHVzYWdlIHJlcXVpcmVzIHNj b3BlIHRvIGJlIHJldHVybmVkIHNvIHRoYXQgaXQgY2FuIGJlIHBhc3NlZCB0byB0aGUNCiBhdXRo IHNlcnZlciBpZiB0aGUgdXNlciBpcyBmb3JjZWQgdG8gcmUtYXV0aGVudGljYXRlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+JiM0MzsxIGZvciAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmV4cGxp Y2l0bHkgcmVzdHJpY3Qgc2NvcGUgdmFsdWVzIHRvIHNvbWUgc3Vic2V0IG9mIHByaW50YWJsZSBB U0NJSSBpbg0KIE9BdXRoMiBDb3JlLiBOb3QgYmVpbmcgYWJsZSB0byBzdXBwb3J0IFVuaWNvZGUg aW4gYSBuZXcgcHJvdG9jb2wgaXMgc2xpZ2h0bHkgZGlzYXBwb2ludGluZywgYnV0IEkgY2FuIGxp dmUgd2l0aCBpdC4mcXVvdDs8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUi IGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gJnF1b3Q7TWFuZ2VyLCBKYW1lcyBIJnF1b3Q7DQog Jmx0OzxhIGhyZWY9Im1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIj5KYW1l cy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPiZndDs8YnI+DQo8Yj5Ubzo8L2I+IE1pa2Ug Sm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyAmcXVvdDs8YSBocmVmPSJtYWlsdG86 b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8 L2I+IFN1bmRheSwgT2N0b2JlciAyLCAyMDExIDU6NTAgQU08YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gUG9zc2libGUgYWx0ZXJuYXRpdmUgcmVzb2x1dGlvbiB0byBpc3N1ZSAy Njwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgaWQ9InlpdjEzNzk0MDI1NSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlRoZSBiZXN0IHNvbHV0aW9uIGlzIHRvIGRyb3AgdGhlIOKAnHNjb3Bl4oCdIGZpZWxk IGZyb20gdGhlIOKAnFdXVy1BdXRoZW50aWNhdGU6IEJlYXJlciAuLi7igJ0gcmVzcG9uc2UgaGVh ZGVyLiDigJxzY29wZeKAnSBpcyByZWxldmFudCB0byBhbiBPQXV0aDItY29yZSBmbG93LCBub3Qg dG8gcHJlc2VudGluZyBhIGJlYXJlciB0b2tlbi4g4oCcc2NvcGXigJ0NCiBjb3VsZCBtYWtlIHNl bnNlIGluIGEg4oCcV1dXLUF1dGhlbnRpY2F0ZTogT0F1dGgyIC4uLuKAnSByZXNwb25zZSBoZWFk ZXIgYXMgbG9uZyBhcyBvdGhlciBuZWNlc3NhcnkgZGV0YWlscyBzdWNoIGFzIGFuIGF1dGhvcml6 YXRpb24gVVJJIHdlcmUgYWxzbyBwcm92aWRlZC4gRHJvcHBpbmcg4oCcc2NvcGXigJ0gYW5kIOKA nGVycm9yX2Rlc2NyaXB0aW9u4oCdIChhcyB0aGUgZXJyb3Igc2hvdWxkIGJlIGRlc2NyaWJlZCBp biB0aGUgcmVzcG9uc2UgYm9keSkgd291bGQNCiBlbGltaW5hdGUgdGhlc2UgZW5jb2RpbmcgcHJv YmxlbXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SWYgdGhlIGdyb3VwIHJlYWxseSB3YW50cyB0byBrZWVwIOKAnHNjb3Bl4oCdLCBJIGRvbuKAmXQg dGhpbmsgUkZDIDU5ODcgaXMgYSBnb29kIHNvbHV0aW9uLiBSRkMgNTk4NyBtaWdodCBoYXZlIGJl ZW4gb2sgZm9yIGFkZGluZyBpbnRlcm5hdGlvbmFsaXphdGlvbiBzdXBwb3J0IHRvIGxvbmctc3Rh bmRpbmcgQVNDSUktb25seSBmaWVsZHMNCiBpbiBhIHdvcmxkIG9mIG11bHRpcGxlIGNoYXJhY3Rl ciBzZXRzIOKAkyBidXQgbm9uZSBvZiB0aGF0IGFwcGxpZXMgaGVyZS4gSGF2aW5nIHRvIGNoYW5n ZSB0aGUgZmllbGQgbmFtZSBmcm9tIOKAnHNjb3Bl4oCdIHRvIOKAnHNjb3BlKuKAnSB3aGVuIHlv dSBoYXZlIGEgbm9uLUFTQ0lJIHZhbHVlIGlzIHRoZSBiaWdnZXN0IGZsYXcuPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlRoZSBzaW1wbGVzdCBzb2x1dGlvbiBpcyB0byBleHBsaWNpdGx5IHJlc3RyaWN0IHNjb3BlIHZh bHVlcyB0byBzb21lIHN1YnNldCBvZiBwcmludGFibGUgQVNDSUkgaW4gT0F1dGgyIENvcmUuIE5v dCBiZWluZyBhYmxlIHRvIHN1cHBvcnQgVW5pY29kZSBpbiBhIG5ldyBwcm90b2NvbCBpcyBzbGln aHRseSBkaXNhcHBvaW50aW5nLA0KIGJ1dCBJIGNhbiBsaXZlIHdpdGggaXQuPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi Pk15IHByZWZlcnJlZCBlc2NhcGluZyBzb2x1dGlvbiB3b3VsZCBiZSBhIEpTT04gc3RyaW5nLCBV VEYtOCBlbmNvZGVkOg0KPGEgaHJlZj0iaHR0cDovL2pzb24ub3JnIiB0YXJnZXQ9Il9ibGFuayI+ anNvbi5vcmc8L2E+LCBSRkMgNDYyNzsgdmFsdWUgaW4gZG91YmxlLXF1b3Rlczsgc2xhc2ggaXMg dGhlIGVzY2FwZSBjaGFyOyBzdXBwb3J0cyBVbmljb2RlOyBlZyBzY29wZT0mcXVvdDtjb2xsXHUw MEU4Z3VlcyZxdW90Oy4gVGhpcyBpcyBiYWNrd2FyZC1jb21wYXRpYmxlIHdpdGggSFRUUOKAmXMg cXVvdGVkLXN0cmluZyBzeW50YXguIEl0IGlzIGZvcndhcmQtY29tcGF0aWJsZSB3aXRoIFVURi04 DQogSFRUUCBoZWFkZXJzIChpZiB0aGF0IG9jY3VycykuIEpTT04gaXMgd2VsbC1zdXBwb3J0ZWQg KGFuZCByZXF1aXJlZCBmb3Igb3RoZXIgT0F1dGgyIGV4Y2hhbmdlcykuIFtJIG1pZ2h0IHN1Z2dl c3QganNvbi1zdHJpbmcgdG8gdGhlIGh0dHBiaXMgZ3JvdXAgYXMgYSBnbG9iYWwgcmVwbGFjZW1l bnQgZm9yIHF1b3RlZC1zdHJpbmcgKG9yIGF0IGxlYXN0IGFzIGEgcmVjb21tZW5kYXRpb24gZm9y IG5ldyBmaWVsZHMpLl08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5KYW1lcyBNYW5nZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8YSBocmVmPSJtYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFp bHRvOlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10iPg0KW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtlIEpvbmVzPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgMzAgU2VwdGVtYmVyIDIwMTEgNDo1MyBBTTxicj4NCjxiPlRvOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBQb3NzaWJsZSBhbHRlcm5hdGl2ZSByZXNvbHV0 aW9uIHRvIGlzc3VlIDI2PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlRoZXJlIHNlZW1zIHRvIG5vdyBiZSBtb3JlIHdvcmtpbmcgZ3JvdXAgaW50ZXJlc3Qg aW4gcmVwcmVzZW50aW5nIG5vbi1BU0NJSSBjaGFyYWN0ZXJzIGluIHNjb3BlIHN0cmluZ3MgdGhh biBoYWQgcHJldmlvdXNseSBiZWVuIGluIGV2aWRlbmNlLiZuYnNwOyBJZiB3ZSBkZWNpZGUgdG8g ZGVmaW5lIGEgc3RhbmRhcmQgcmVwcmVzZW50YXRpb24NCiBmb3IgZG9pbmcgc28sIHVzaW5nIDxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU5ODciIHRhcmdldD0iX2JsYW5r Ij4NClJGQyA1OTg3PC9hPiAoQ2hhcmFjdGVyIFNldCBhbmQgTGFuZ3VhZ2UgRW5jb2RpbmcgZm9y IEh5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAoSFRUUCkgSGVhZGVyIEZpZWxkIFBhcmFtZXRl cnMpIHNlZW1zIHRvIGJlIHRoZSBjbGVhciBjaG9pY2UuJm5ic3A7IEnigJlkIGJlIGludGVyZXN0 ZWQgaW4ga25vd2luZyBob3cgbWFueSB3b3JraW5nIGdyb3VwIG1lbWJlcnMgYXJlIGluIGZhdm9y IG9mIGVpdGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4xLiZuYnNwOyBVc2luZyBSRkMgNTk4NyBlbmNvZGluZyBmb3IgdGhlIHNjb3Bl IHBhcmFtZXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4yLiZuYnNwOyBDb250aW51aW5nIHRvIHNwZWNpZnkgbm8gbm9uLUFTQ0lJIGVuY29k aW5nIGZvciBzY29wZSBwYXJhbWV0ZXIgdmFsdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFzIGEgcmVsYXRlZCBpc3N1ZSwgc29tZSB3 b3JraW5nIGdyb3VwIG1lbWJlcnMgaGF2ZSBvYmplY3RlZCB0byBzcGVjaWZ5aW5nIFVURi04IGVu Y29kaW5nIG9mIHRoZSBlcnJvcl9kZXNjcmlwdGlvbiB2YWx1ZSwgcmVxdWVzdGluZyB0aGUgdXNl IG9mIFJGQyA1OTg3IGVuY29kaW5nIGluc3RlYWQuJm5ic3A7IEnigJlkIGFsc28gYmUgaW50ZXJl c3RlZA0KIGluIGtub3dpbmcgaG93IG1hbnkgd29ya2luZyBncm91cCBtZW1iZXJzIGFyZSBpbiBm YXZvciBvZiBlaXRoZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+QS4mbmJzcDsgVXNpbmcgUkZDIDU5ODcgZW5jb2RpbmcgZm9yIHRoZSBl cnJvcl9kZXNjcmlwdGlvbiBwYXJhbWV0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Qi4mbmJzcDsgQ29udGludWluZyB0byBzcGVjaWZ5IFVU Ri04IGVuY29kaW5nIGZvciB0aGUgZXJyb3JfZGVzY3JpcHRpb24gcGFyYW1ldGVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPihBcyBlZGl0 b3IsIEkgd291bGQgbWFrZSB0aGUgb2JzZXJ2YXRpb24gdGhhdCBpZiB3ZSBjaG9vc2UgUkZDIDU5 ODcgZW5jb2RpbmcgZm9yIGVpdGhlciBvZiB0aGVzZSBwYXJhbWV0ZXJzLCBpdCB3b3VsZCBiZSBs b2dpY2FsIHRvIGRvIHNvIGZvciB0aGUgb3RoZXIgb25lIGFzIHdlbGwuKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkluIHRoZSBpbnRlcmVz dCBvZiBmaW5pc2hpbmcgdGhlIHNwZWNpZmljYXRpb24gaW4gYSB3YXkgdGhhdCBtZWV0cyBldmVy eW9uZeKAmXMgbmVlZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739435C226298TK5EX14MBXC284r_-- From dick.hardt@gmail.com Mon Oct 3 19:18:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D4F21F8E50 for ; Mon, 3 Oct 2011 19:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1C7j9ij43Cv for ; Mon, 3 Oct 2011 19:18:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF1F721F8E44 for ; Mon, 3 Oct 2011 19:18:39 -0700 (PDT) Received: by iaby26 with SMTP id y26so30196iab.31 for ; Mon, 03 Oct 2011 19:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=dW5H+XPSneGp9yhpg6Ap8eeBrPW4DdffLwRO0QXBI6w=; b=C/64a8UxyKdf6SRUasZ8pCZfSblpGj6cQINPRJNFs7RrW5MH2Cl8KWKDPwA/BecZxr BFr4p/FbJifVQuBYhks0gE8Cc5pfXX3ai5sZXOX2qdkgrJTFs2InJh7nSyrdE08yGjxQ 1s0UWBJF5jjGMhespmCUbAEdR+djVDsYrIvuo= Received: by 10.231.4.131 with SMTP id 3mr1113849ibr.30.1317694903273; Mon, 03 Oct 2011 19:21:43 -0700 (PDT) References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (iPad Mail 8J3) Date: Mon, 3 Oct 2011 19:21:37 -0700 Message-ID: <-6801936430419067387@unknownmsgid> To: Mike Jones Content-Type: multipart/alternative; boundary=000e0cd139baa1cb5104ae6fc0fa Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 02:18:41 -0000 --000e0cd139baa1cb5104ae6fc0fa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable slight preference for 3 and E -- Dick On 2011-10-03, at 6:56 PM, Mike Jones wrote: As editor, based upon James=92 input, I=92d like to expand the set of choi= ces for the working group to consider by adding the possibility of using JSON string encodings for scope and error_description where the characters used for the encoding are restricted to the set of 7-bit ASCII characters compatible with the HTTPbis and RFC 2617 parameter syntaxes. 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. 3. Using JSON string encoding for the scope parameter. A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description parameter. C. Using JSON string encoding for the error_description parameter. As an individual, I=92m sympathetic to the argument that RFC 5987 (with =93scope*=94 and language tags etc.) is overkill for OAuth implementations, where neither of the sets of strings is intended to be presented to end-users. Hence, the possible attractiveness of options 3 and C. Thoughts from others? -- Mike *From:* William Mills [mailto:wmills@yahoo-inc.com] *Sent:* Sunday, October 02, 2011 11:01 PM *To:* Manger, James H; Mike Jones; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 I don't like dropping scope from the WWW-Authenticate responses, because my current discovery usage requires scope to be returned so that it can be passed to the auth server if the user is forced to re-authenticate. +1 for "explicitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disappointing, but I can live with it." ------------------------------ *From:* "Manger, James H" *To:* Mike Jones ; "oauth@ietf.org" < oauth@ietf.org> *Sent:* Sunday, October 2, 2011 5:50 AM *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 The best solution is to drop the =93scope=94 field from the =93WWW-Authenti= cate: Bearer ...=94 response header. =93scope=94 is relevant to an OAuth2-core fl= ow, not to presenting a bearer token. =93scope=94 could make sense in a =93WWW-Authenticate: OAuth2 ...=94 response header as long as other necessa= ry details such as an authorization URI were also provided. Dropping =93scope= =94 and =93error_description=94 (as the error should be described in the respon= se body) would eliminate these encoding problems. If the group really wants to keep =93scope=94, I don=92t think RFC 5987 is = a good solution. RFC 5987 might have been ok for adding internationalization support to long-standing ASCII-only fields in a world of multiple character sets =96 but none of that applies here. Having to change the field name fro= m =93scope=94 to =93scope*=94 when you have a non-ASCII value is the biggest = flaw. The simplest solution is to explicitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disappointing, but I can live with it. My preferred escaping solution would be a JSON string, UTF-8 encoded: json.org, RFC 4627; value in double-quotes; slash is the escape char; supports Unicode; eg scope=3D"coll\u00E8gues". This is backward-compatible with HTTP=92s quoted-string syntax. It is forward-compatible with UTF-8 HTT= P headers (if that occurs). JSON is well-supported (and required for other OAuth2 exchanges). [I might suggest json-string to the httpbis group as a global replacement for quoted-string (or at least as a recommendation for new fields).] -- James Manger *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf O= f *Mike Jones *Sent:* Friday, 30 September 2011 4:53 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII characters in scope strings than had previously been in evidence. If we decide to define a standard representation for doing so, using RFC 5987(Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the clear choice. I=92d be interested= in knowing how many working group members are in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying UTF-8 encoding of the error_description value, requesting the use of RFC 5987 encoding instead. I=92d also be interested in knowing how many workin= g group members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description parameter. (As editor, I would make the observation that if we choose RFC 5987 encodin= g for either of these parameters, it would be logical to do so for the other one as well.) In the interest of finishing the specification in a way that meets everyone=92s needs, -- Mike _______________________________________________ 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 --000e0cd139baa1cb5104ae6fc0fa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
slight preference for 3 and E

-= - Dick

On 2011-10-03, at 6:56 PM, Mike Jones <Michael.Jones@microsoft.com> wrot= e:

As editor, based upon Jam= es=92 input, I=92d like to expand the set of choices for the working group = to consider by adding the possibility of using JSON string encodings for scope and error_description where the characters used for the encoding= are restricted to the set of 7-bit ASCII characters compatible with the HT= TPbis and RFC 2617 parameter syntaxes.

=A0

1.=A0 Using RFC 5987 encoding for the scope parameter.

2.=A0 Continuing to specify no non-ASCII encoding for scope parameter va= lues.

3.=A0 Using JSON string encoding for the scope parameter.

=A0

A.=A0 Using RFC 5987 encoding for the error_description parameter.

B.=A0 Continuing to specify UTF-8 encoding for the error_description par= ameter.

C.=A0 Using JSON string encoding for the error_description parameter.

=A0

As an individual, I=92m s= ympathetic to the argument that RFC 5987 (with =93scope*=94 and language ta= gs etc.) is overkill for OAuth implementations, where neither of the sets of strings is intended to be presented to end-users.=A0 Hence,= the possible attractiveness of options 3 and C.

=A0

Thoughts from others?

=A0

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0

From: William = Mills [mailto:wmills@yahoo-inc.com<= /a>]
Sent: Sunday, October 02, 2011 11:01 PM
To: Manger, James H; Mike Jones; <= a href=3D"mailto:oauth@ietf.org">oauth@ietf.org
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= /span>

=A0

I don't like dropping scope from= the WWW-Authenticate responses, because my current discovery usage require= s scope to be returned so that it can be passed to the auth server if the user is forced to re-authenticate.

=A0

+1 for "expl= icitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slight= ly disappointing, but I can live with it."

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: "Manger,= James H" <James.H.Manger@team.telstra.com>=
To: Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Sunday, October 2, 2011 5:50 AM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= /span>

The best solution is to drop the =93scope=94 field from the =93WWW-Aut= henticate: Bearer ...=94 response header. =93scope=94 is relevant to an OAu= th2-core flow, not to presenting a bearer token. =93scope=94 could make sense in a =93WWW-Authenticate: OAuth2 ...=94 response header a= s long as other necessary details such as an authorization URI were also pr= ovided. Dropping =93scope=94 and =93error_description=94 (as the error shou= ld be described in the response body) would eliminate these encoding problems.

=A0

=A0

If the group really wants to keep =93scope=94, I don=92t think RFC 598= 7 is a good solution. RFC 5987 might have been ok for adding internationali= zation support to long-standing ASCII-only fields in a world of multiple character sets =96 but none of that applies here. H= aving to change the field name from =93scope=94 to =93scope*=94 when you ha= ve a non-ASCII value is the biggest flaw.

=A0

The simplest solution is to explicitly restrict scope values to some s= ubset of printable ASCII in OAuth2 Core. Not being able to support Unicode = in a new protocol is slightly disappointing, but I can live with it.

=A0

My preferred escaping solution would be a JSON string, UTF-8 encoded: j= son.org, RFC 4627; value in double-quotes; slash is the escape char= ; supports Unicode; eg scope=3D"coll\u00E8gues". This is backward= -compatible with HTTP=92s quoted-string syntax. It is forward-compatible wi= th UTF-8 HTTP headers (if that occurs). JSON is well-supported (and required for ot= her OAuth2 exchanges). [I might suggest json-string to the httpbis group as= a global replacement for quoted-string (or at least as a recommendation fo= r new fields).]

=A0

--

James Manger

=A0

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, 30 September 2011 4:53 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Possible alternative resolution to issue 26

=A0

There seems to now be more working group interest in representing non-AS= CII characters in scope strings than had previously been in evidence.=A0 If= we decide to define a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hypertext Transfer Pr= otocol (HTTP) Header Field Parameters) seems to be the clear choice.=A0 I= =92d be interested in knowing how many working group members are in favor o= f either:

=A0

1.=A0 Using RFC 5987 encoding for the scope parameter.

2.=A0 Continuing to specify no non-ASCII encoding for scope parameter va= lues.

=A0

As a related issue, some working group members have objected to specifyi= ng UTF-8 encoding of the error_description value, requesting the use of RFC= 5987 encoding instead.=A0 I=92d also be interested in knowing how many working group members are in favor of either:

=A0

A.=A0 Using RFC 5987 encoding for the error_description parameter.

B.=A0 Continuing to specify UTF-8 encoding for the error_description par= ameter.

=A0

(As editor, I would make the observation that if we choose RFC 5987 enco= ding for either of these parameters, it would be logical to do so for the o= ther one as well.)

=A0

In the interest of finishing the specification in a way that meets every= one=92s needs,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0


_______________________________________________
OAuth mailing list
OAuth@i= etf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth

___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth
--000e0cd139baa1cb5104ae6fc0fa-- From dick.hardt@gmail.com Mon Oct 3 19:19:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482B021F8E47 for ; Mon, 3 Oct 2011 19:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GJpRCjqJTxh for ; Mon, 3 Oct 2011 19:19:35 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11B4321F8E41 for ; Mon, 3 Oct 2011 19:19:35 -0700 (PDT) Received: by iaby26 with SMTP id y26so31450iab.31 for ; Mon, 03 Oct 2011 19:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=vujHOOD7jPCgc1ZyWJk3BJf43zl3NylftuwxT6kRyI8=; b=szXeqTwqaD/jtmPaOkyBB1O7qe3Ec7CCIweOVfz8V0EPyQ9KNeAOwYH4Q//SsjdO1P uO7Kph9wOrx8mYZX9NsSpUW++YaD6ICHrF03z5bksvUgrVK3sYtL8UA72GOUqxceb/9E AXM2eVLCsdhh1FUyCahMqyDUdDEVbHGwtfsbI= Received: by 10.231.47.65 with SMTP id m1mr1058698ibf.82.1317694958729; Mon, 03 Oct 2011 19:22:38 -0700 (PDT) References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (iPad Mail 8J3) Date: Mon, 3 Oct 2011 19:22:32 -0700 Message-ID: <-2137736500762618607@unknownmsgid> To: Mike Jones Content-Type: multipart/alternative; boundary=00151773e422eff94e04ae6fc3fc Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 02:19:36 -0000 --00151773e422eff94e04ae6fc3fc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I meant 3 and C -- Dick On 2011-10-03, at 6:56 PM, Mike Jones wrote: As editor, based upon James=92 input, I=92d like to expand the set of choi= ces for the working group to consider by adding the possibility of using JSON string encodings for scope and error_description where the characters used for the encoding are restricted to the set of 7-bit ASCII characters compatible with the HTTPbis and RFC 2617 parameter syntaxes. 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. 3. Using JSON string encoding for the scope parameter. A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description parameter. C. Using JSON string encoding for the error_description parameter. As an individual, I=92m sympathetic to the argument that RFC 5987 (with =93scope*=94 and language tags etc.) is overkill for OAuth implementations, where neither of the sets of strings is intended to be presented to end-users. Hence, the possible attractiveness of options 3 and C. Thoughts from others? -- Mike *From:* William Mills [mailto:wmills@yahoo-inc.com] *Sent:* Sunday, October 02, 2011 11:01 PM *To:* Manger, James H; Mike Jones; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 I don't like dropping scope from the WWW-Authenticate responses, because my current discovery usage requires scope to be returned so that it can be passed to the auth server if the user is forced to re-authenticate. +1 for "explicitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disappointing, but I can live with it." ------------------------------ *From:* "Manger, James H" *To:* Mike Jones ; "oauth@ietf.org" < oauth@ietf.org> *Sent:* Sunday, October 2, 2011 5:50 AM *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 The best solution is to drop the =93scope=94 field from the =93WWW-Authenti= cate: Bearer ...=94 response header. =93scope=94 is relevant to an OAuth2-core fl= ow, not to presenting a bearer token. =93scope=94 could make sense in a =93WWW-Authenticate: OAuth2 ...=94 response header as long as other necessa= ry details such as an authorization URI were also provided. Dropping =93scope= =94 and =93error_description=94 (as the error should be described in the respon= se body) would eliminate these encoding problems. If the group really wants to keep =93scope=94, I don=92t think RFC 5987 is = a good solution. RFC 5987 might have been ok for adding internationalization support to long-standing ASCII-only fields in a world of multiple character sets =96 but none of that applies here. Having to change the field name fro= m =93scope=94 to =93scope*=94 when you have a non-ASCII value is the biggest = flaw. The simplest solution is to explicitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disappointing, but I can live with it. My preferred escaping solution would be a JSON string, UTF-8 encoded: json.org, RFC 4627; value in double-quotes; slash is the escape char; supports Unicode; eg scope=3D"coll\u00E8gues". This is backward-compatible with HTTP=92s quoted-string syntax. It is forward-compatible with UTF-8 HTT= P headers (if that occurs). JSON is well-supported (and required for other OAuth2 exchanges). [I might suggest json-string to the httpbis group as a global replacement for quoted-string (or at least as a recommendation for new fields).] -- James Manger *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf O= f *Mike Jones *Sent:* Friday, 30 September 2011 4:53 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII characters in scope strings than had previously been in evidence. If we decide to define a standard representation for doing so, using RFC 5987(Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the clear choice. I=92d be interested= in knowing how many working group members are in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying UTF-8 encoding of the error_description value, requesting the use of RFC 5987 encoding instead. I=92d also be interested in knowing how many workin= g group members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description parameter. (As editor, I would make the observation that if we choose RFC 5987 encodin= g for either of these parameters, it would be logical to do so for the other one as well.) In the interest of finishing the specification in a way that meets everyone=92s needs, -- Mike _______________________________________________ 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 --00151773e422eff94e04ae6fc3fc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I meant 3 and C

-- Dick

On 2011-10-03, at 6:56 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

As editor, based upon Jam= es=92 input, I=92d like to expand the set of choices for the working group = to consider by adding the possibility of using JSON string encodings for scope and error_description where the characters used for the encoding= are restricted to the set of 7-bit ASCII characters compatible with the HT= TPbis and RFC 2617 parameter syntaxes.

=A0

1.=A0 Using RFC 5987 encoding for the scope parameter.

2.=A0 Continuing to specify no non-ASCII encoding for scope parameter va= lues.

3.=A0 Using JSON string encoding for the scope parameter.

=A0

A.=A0 Using RFC 5987 encoding for the error_description parameter.

B.=A0 Continuing to specify UTF-8 encoding for the error_description par= ameter.

C.=A0 Using JSON string encoding for the error_description parameter.

=A0

As an individual, I=92m s= ympathetic to the argument that RFC 5987 (with =93scope*=94 and language ta= gs etc.) is overkill for OAuth implementations, where neither of the sets of strings is intended to be presented to end-users.=A0 Hence,= the possible attractiveness of options 3 and C.

=A0

Thoughts from others?

=A0

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0

From: William = Mills [mailto:wmills@yahoo-inc.com<= /a>]
Sent: Sunday, October 02, 2011 11:01 PM
To: Manger, James H; Mike Jones; <= a href=3D"mailto:oauth@ietf.org">oauth@ietf.org
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= /span>

=A0

I don't like dropping scope from= the WWW-Authenticate responses, because my current discovery usage require= s scope to be returned so that it can be passed to the auth server if the user is forced to re-authenticate.

=A0

+1 for "expl= icitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slight= ly disappointing, but I can live with it."

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: "Manger,= James H" <James.H.Manger@team.telstra.com>=
To: Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Sunday, October 2, 2011 5:50 AM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= /span>

The best solution is to drop the =93scope=94 field from the =93WWW-Aut= henticate: Bearer ...=94 response header. =93scope=94 is relevant to an OAu= th2-core flow, not to presenting a bearer token. =93scope=94 could make sense in a =93WWW-Authenticate: OAuth2 ...=94 response header a= s long as other necessary details such as an authorization URI were also pr= ovided. Dropping =93scope=94 and =93error_description=94 (as the error shou= ld be described in the response body) would eliminate these encoding problems.

=A0

=A0

If the group really wants to keep =93scope=94, I don=92t think RFC 598= 7 is a good solution. RFC 5987 might have been ok for adding internationali= zation support to long-standing ASCII-only fields in a world of multiple character sets =96 but none of that applies here. H= aving to change the field name from =93scope=94 to =93scope*=94 when you ha= ve a non-ASCII value is the biggest flaw.

=A0

The simplest solution is to explicitly restrict scope values to some s= ubset of printable ASCII in OAuth2 Core. Not being able to support Unicode = in a new protocol is slightly disappointing, but I can live with it.

=A0

My preferred escaping solution would be a JSON string, UTF-8 encoded: j= son.org, RFC 4627; value in double-quotes; slash is the escape char= ; supports Unicode; eg scope=3D"coll\u00E8gues". This is backward= -compatible with HTTP=92s quoted-string syntax. It is forward-compatible wi= th UTF-8 HTTP headers (if that occurs). JSON is well-supported (and required for ot= her OAuth2 exchanges). [I might suggest json-string to the httpbis group as= a global replacement for quoted-string (or at least as a recommendation fo= r new fields).]

=A0

--

James Manger

=A0

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, 30 September 2011 4:53 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Possible alternative resolution to issue 26

=A0

There seems to now be more working group interest in representing non-AS= CII characters in scope strings than had previously been in evidence.=A0 If= we decide to define a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hypertext Transfer Pr= otocol (HTTP) Header Field Parameters) seems to be the clear choice.=A0 I= =92d be interested in knowing how many working group members are in favor o= f either:

=A0

1.=A0 Using RFC 5987 encoding for the scope parameter.

2.=A0 Continuing to specify no non-ASCII encoding for scope parameter va= lues.

=A0

As a related issue, some working group members have objected to specifyi= ng UTF-8 encoding of the error_description value, requesting the use of RFC= 5987 encoding instead.=A0 I=92d also be interested in knowing how many working group members are in favor of either:

=A0

A.=A0 Using RFC 5987 encoding for the error_description parameter.

B.=A0 Continuing to specify UTF-8 encoding for the error_description par= ameter.

=A0

(As editor, I would make the observation that if we choose RFC 5987 enco= ding for either of these parameters, it would be logical to do so for the o= ther one as well.)

=A0

In the interest of finishing the specification in a way that meets every= one=92s needs,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0


_______________________________________________
OAuth mailing list
OAuth@i= etf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth

___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth
--00151773e422eff94e04ae6fc3fc-- From wmills@yahoo-inc.com Mon Oct 3 21:55:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B821F8EC2 for ; Mon, 3 Oct 2011 21:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.383 X-Spam-Level: X-Spam-Status: No, score=-17.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWLR1LxHWeds for ; Mon, 3 Oct 2011 21:55:35 -0700 (PDT) Received: from nm10-vm0.bullet.mail.ac4.yahoo.com (nm10-vm0.bullet.mail.ac4.yahoo.com [98.139.53.194]) by ietfa.amsl.com (Postfix) with SMTP id EF58421F8E50 for ; Mon, 3 Oct 2011 21:55:34 -0700 (PDT) Received: from [98.139.52.192] by nm10.bullet.mail.ac4.yahoo.com with NNFMP; 04 Oct 2011 04:58:36 -0000 Received: from [98.139.52.131] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 04 Oct 2011 04:58:36 -0000 Received: from [127.0.0.1] by omp1014.mail.ac4.yahoo.com with NNFMP; 04 Oct 2011 04:58:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 353003.15269.bm@omp1014.mail.ac4.yahoo.com Received: (qmail 5454 invoked by uid 60001); 4 Oct 2011 04:58:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1317704315; bh=g+MzH2L6+X5oG/PlTXh7/dlTF47loTpA6EK8v/vvVK8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bJqmBszbr3aoUEgZoqkWVHtdWy6vws1M0MSMhPQSzIXXscVPOql/ul87OnE0uEN6XtQQRHgeKW2rHhP+f9n1cv8ETqSvU05AG+QxDRS8nZjd8dA1N2DwmNHZYNJyawb3FkmIIW0GWQv+Mzh2ukpzlP88/fBlft4UGiLHgTrHj58= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Dr7ogzIFbcLlhIiSqpTKz3gGnccGuExVWBfQz/J2ioPYFDc+i4BnHCsONcLOZ1wr5ZBbvkRTQ6DMQXmKD86WsWlU/r/IEJSmx9rx/pCi94ZxMRBNvCgeAUEDhXFyqvuWhfkoSsFGQe2hxcGudIZP9dFewHa3GYQUii9eOY2uCvs=; X-YMail-OSG: Zo1FP54VM1k_GGrs5fJc5Bv_YE9AR8jU4k5x1IpHJc8RQQU OojxBaoRTqhr5KrtWH1T1oX2.3OD8BrzgOf8F2nf1GhAXvQf3RVvkoXqrGUr kGjJ4mFKQhnw9ieAHA5ilwBZKP9OLoWJ6KvEQbKrsSXXHbAG3zn6jsdJDzEG _DBJndkNKK4o30_sj8trpHbSuNi9on4tS.nDIx_hfLxznpekeLB1ABFNWo6F LB.dJ5PT1ZhcY4RJMORCyThg_Ipf8jLfZABbo.AANffUKiiFo6TetpU9iv0F mda1OYFHxBDusTo.2BZkHr2i2f8zp79_Pza9TsVT0pFxdeXFOnrNliFlMddm K9H_5C_BM3NWZJEu4HYqtB.d68c2e4zbLn15UfSuA7J1Pix3ArDAySx7ISLA p3cGx3ngemcYKfQTqV0UYSGOEJDg79hELUUzvhcM7fDzDPw1IdUdeTmI2z8d pMyqXSA-- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Mon, 03 Oct 2011 21:58:35 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Mon, 3 Oct 2011 21:58:35 -0700 (PDT) From: William Mills To: Mike Jones , "oauth@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-510387924-1317704315=:93442" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 04:55:36 -0000 --0-510387924-1317704315=:93442 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You forgot:=0A=0A4.=C2=A0 Restrict the character set for scope to the point= where these issues all go away.=0A=0A=0A=0A_______________________________= _=0AFrom: Mike Jones =0ATo: "oauth@ietf.org" <= oauth@ietf.org>=0ACc: "Manger, James H" ; = William Mills =0ASent: Monday, October 3, 2011 6:55 P= M=0ASubject: RE: [OAUTH-WG] Possible alternative resolution to issue 26=0A= =0A=0A =0AAs editor, based upon James=E2=80=99 input, I=E2=80=99d like to e= xpand the set of choices for the working group to consider by adding the po= ssibility of using JSON string encodings for scope and error_description wh= ere the characters used for the encoding are restricted to the set of 7-bit= ASCII characters compatible with the HTTPbis and RFC 2617 parameter syntax= es.=0A=C2=A0=0A1.=C2=A0 Using RFC 5987 encoding for the scope parameter.=0A= 2.=C2=A0 Continuing to specify no non-ASCII encoding for scope parameter va= lues.=0A3.=C2=A0 Using JSON string encoding for the scope parameter.=0A=C2= =A0=0AA.=C2=A0 Using RFC 5987 encoding for the error_description parameter.= =0AB.=C2=A0 Continuing to specify UTF-8 encoding for the error_description = parameter.=0AC.=C2=A0 Using JSON string encoding for the error_description = parameter.=0A=C2=A0=0AAs an individual, I=E2=80=99m sympathetic to the argu= ment that RFC 5987 (with =E2=80=9Cscope*=E2=80=9D and language tags etc.) i= s overkill for OAuth implementations, where neither of the sets of strings = is intended to be presented to end-users.=C2=A0 Hence, the possible attract= iveness of options 3 and C.=0A=C2=A0=0AThoughts from others?=0A=C2=A0=0A=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike=0A=C2=A0=0AFrom:William Mills [mailto:wmills@yahoo-inc.com] =0ASen= t: Sunday, October 02, 2011 11:01 PM=0ATo: Manger, James H; Mike Jones; oau= th@ietf.org=0ASubject: Re: [OAUTH-WG] Possible alternative resolution to is= sue 26=0A=C2=A0=0AI don't like dropping scope from the WWW-Authenticate res= ponses, because my current discovery usage requires scope to be returned so= that it can be passed to the auth server if the user is forced to re-authe= nticate.=0A=C2=A0=0A+1 for "explicitly restrict scope values to some subset= of printable ASCII in OAuth2 Core. Not being able to support Unicode in a = new protocol is slightly disappointing, but I can live with it."=0A=0A=0A= =0A________________________________=0A =0AFrom:"Manger, James H" =0ATo: Mike Jones ; "oa= uth@ietf.org" =0ASent: Sunday, October 2, 2011 5:50 AM=0ASu= bject: Re: [OAUTH-WG] Possible alternative resolution to issue 26=0AThe bes= t solution is to drop the =E2=80=9Cscope=E2=80=9D field from the =E2=80=9CW= WW-Authenticate: Bearer ...=E2=80=9D response header. =E2=80=9Cscope=E2=80= =9D is relevant to an OAuth2-core flow, not to presenting a bearer token. = =E2=80=9Cscope=E2=80=9D could make sense in a =E2=80=9CWWW-Authenticate: OA= uth2 ...=E2=80=9D response header as long as other necessary details such a= s an authorization URI were also provided. Dropping =E2=80=9Cscope=E2=80=9D= and =E2=80=9Cerror_description=E2=80=9D (as the error should be described = in the response body) would eliminate these encoding problems.=0A=C2=A0=0A= =C2=A0=0AIf the group really wants to keep =E2=80=9Cscope=E2=80=9D, I don= =E2=80=99t think RFC 5987 is a good solution. RFC 5987 might have been ok f= or adding internationalization support to long-standing ASCII-only fields i= n a world of multiple character sets =E2=80=93 but none of that applies her= e. Having to change the field name from =E2=80=9Cscope=E2=80=9D to =E2=80= =9Cscope*=E2=80=9D when you have a non-ASCII value is the biggest flaw.=0A= =C2=A0=0AThe simplest solution is to explicitly restrict scope values to so= me subset of printable ASCII in OAuth2 Core. Not being able to support Unic= ode in a new protocol is slightly disappointing, but I can live with it.=0A= =C2=A0=0AMy preferred escaping solution would be a JSON string, UTF-8 encod= ed: json.org, RFC 4627; value in double-quotes; slash is the escape char; s= upports Unicode; eg scope=3D"coll\u00E8gues". This is backward-compatible w= ith HTTP=E2=80=99s quoted-string syntax. It is forward-compatible with UTF-= 8 HTTP headers (if that occurs). JSON is well-supported (and required for o= ther OAuth2 exchanges). [I might suggest json-string to the httpbis group a= s a global replacement for quoted-string (or at least as a recommendation f= or new fields).]=0A=C2=A0=0A--=0AJames Manger=0A=C2=A0=0AFrom:oauth-bounces= @ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones=0ASent: F= riday, 30 September 2011 4:53 AM=0ATo: oauth@ietf.org=0ASubject: [OAUTH-WG]= Possible alternative resolution to issue 26=0A=C2=A0=0AThere seems to now = be more working group interest in representing non-ASCII characters in scop= e strings than had previously been in evidence.=C2=A0 If we decide to defin= e a standard representation for doing so, using RFC 5987 (Character Set and= Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Para= meters) seems to be the clear choice.=C2=A0 I=E2=80=99d be interested in kn= owing how many working group members are in favor of either:=0A=C2=A0=0A1.= =C2=A0 Using RFC 5987 encoding for the scope parameter.=0A2.=C2=A0 Continui= ng to specify no non-ASCII encoding for scope parameter values.=0A=C2=A0=0A= As a related issue, some working group members have objected to specifying = UTF-8 encoding of the error_description value, requesting the use of RFC 59= 87 encoding instead.=C2=A0 I=E2=80=99d also be interested in knowing how ma= ny working group members are in favor of either:=0A=C2=A0=0AA.=C2=A0 Using = RFC 5987 encoding for the error_description parameter.=0AB.=C2=A0 Continuin= g to specify UTF-8 encoding for the error_description parameter.=0A=C2=A0= =0A(As editor, I would make the observation that if we choose RFC 5987 enco= ding for either of these parameters, it would be logical to do so for the o= ther one as well.)=0A=C2=A0=0AIn the interest of finishing the specificatio= n in a way that meets everyone=E2=80=99s needs,=0A=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A=C2=A0=0A=0A______________________= _________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://w= ww.ietf.org/mailman/listinfo/oauth --0-510387924-1317704315=:93442 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You forgot:

4.  R= estrict the character set for scope to the point where these issues all go = away.

From: Mike Jones <Michael.Jones@microsoft.com>
= To: "oauth@ietf.org" <oaut= h@ietf.org>
Cc: "Man= ger, James H" <James.H.Manger@team.telstra.com>; William Mills <wm= ills@yahoo-inc.com>
Sent: Monday, October 3, 2011 6:55 PM
Subject:<= /span> RE: [OAUTH-WG] Possible alternative resolution to issue 26

=0A
=0A=0A =0A =0A=0A=0A
=0A
= =0A
As editor, based upon James=E2=80=99 input, I=E2=80=99d like t= o expand the set of choices for the working group to consider by adding the= possibility of using JSON string encodings=0A for scope and error_descript= ion where the characters used for the encoding are restricted to the set of= 7-bit ASCII characters compatible with the HTTPbis and RFC 2617 parameter = syntaxes.
=0A
 
=0A
1.  Using RFC 5987 encoding for the scope parameter.
= =0A
2.  Continuing to specify no non-ASCII encoding= for scope parameter values.
=0A
3.  Us= ing JSON string encoding for the scope parameter.
=0A
 
=0A
A.  Using RFC 5987= encoding for the error_description parameter.
=0A
B.  Continuing to specify UTF-8 encoding for the error_descri= ption parameter.
=0A
C.  Using JSON str= ing encoding for the error_description parameter.
=0A
 
=0A
As an individual, I=E2=80=99m sympathe= tic to the argument that RFC 5987 (with =E2=80=9Cscope*=E2=80=9D and langua= ge tags etc.) is overkill for OAuth implementations, where neither=0A of th= e sets of strings is intended to be presented to end-users.  Hence, th= e possible attractiveness of options 3 and C.
=0A
&n= bsp;
=0A
Thoughts from others?
=0A
 
=0A
      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       -- Mike
=0A
 
=0A
=0A
=0A
From: William Mills [mailto:wmills@yahoo-inc.com]=0A
=0A<= b>Sent: Sunday, October 02, 2011 11:01 PM
=0ATo: Manger, Jame= s H; Mike Jones; oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] Possib= le alternative resolution to issue 26
=0A
=0A
=0A  
=0A
=0A
=0A
I don't like dropping scope from the WWW-Authenticate responses,= because my current discovery usage requires scope to be returned so that i= t can be passed to the=0A auth server if the user is forced to re-authentic= ate.
=0A
=0A
=0A
  =0A
=0A
+1 for "explicitly restrict scope values to some subset o= f printable ASCII in=0A OAuth2 Core. Not being able to support Unicode in a= new protocol is slightly disappointing, but I can live with it."
=0A=0A
=0A
=0A
=0A=0A=0A=
=0A
=0A
From: "Manger, James H"=0A <James.H.Manger@team.tels= tra.com>
=0ATo: Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.org" <oauth= @ietf.org>
=0ASent: Sunday, October 2, 2011 5:50 AM
=0A= Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= /span>
=0A
=0A
=0A
=0A
=0A
The best solution is to d= rop the =E2=80=9Cscope=E2=80=9D field from the =E2=80=9CWWW-Authenticate: B= earer ...=E2=80=9D response header. =E2=80=9Cscope=E2=80=9D is relevant to = an OAuth2-core flow, not to presenting a bearer token. =E2=80=9Cscope=E2=80= =9D=0A could make sense in a =E2=80=9CWWW-Authenticate: OAuth2 ...=E2=80=9D= response header as long as other necessary details such as an authorizatio= n URI were also provided. Dropping =E2=80=9Cscope=E2=80=9D and =E2=80=9Cerr= or_description=E2=80=9D (as the error should be described in the response b= ody) would=0A eliminate these encoding problems.
=0A
=0A
=0A
 
=0A
=0A
=0A
 
=0A=0A
=0A
If the group really wants to keep =E2=80= =9Cscope=E2=80=9D, I don=E2=80=99t think RFC 5987 is a good solution. RFC 5= 987 might have been ok for adding internationalization support to long-stan= ding ASCII-only fields=0A in a world of multiple character sets =E2=80=93 b= ut none of that applies here. Having to change the field name from =E2=80= =9Cscope=E2=80=9D to =E2=80=9Cscope*=E2=80=9D when you have a non-ASCII val= ue is the biggest flaw.
= =0A
=0A
=0A
 
=0A
=0A
=0A
The simplest= solution is to explicitly restrict scope values to some subset of printabl= e ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol= is slightly disappointing,=0A but I can live with it.
=0A
=0A
=0A
 = ;
=0A
=0A
=0AMy preferred escaping solution would be a JSON string, UTF= -8 encoded:=0Ajson.org, RFC 4627; value in double-quotes; slash is the escape char;= supports Unicode; eg scope=3D"coll\u00E8gues". This is backward-compatible= with HTTP=E2=80=99s quoted-string syntax. It is forward-compatible with UT= F-8=0A HTTP headers (if that occurs). JSON is well-supported (and required = for other OAuth2 exchanges). [I might suggest json-string to the httpbis gr= oup as a global replacement for quoted-string (or at least as a recommendat= ion for new fields).]
=0A<= /div>=0A
=0A
 
=0A
=0A
=0A
=0A
--
=0A
=0A
=0A
James Manger
= =0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0AFrom:=0Aoaut= h-bounces@ietf.org =0A[mailto:oauth-bounces@ietf.org] On Behalf Of Mike J= ones
=0ASent: Friday, 30 September 2011 4:53 AM
=0ATo: = oauth@ietf.org
=0ASubject: [OAUTH= -WG] Possible alternative resolution to issue 26
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
There seems= to now be more working group interest in representing non-ASCII characters= in scope strings than had previously been in evidence.  If we decide = to define a standard representation=0A for doing so, using =0ARFC 59= 87 (Character Set and Language Encoding for Hypertext Transfer Protocol= (HTTP) Header Field Parameters) seems to be the clear choice.  I=E2= =80=99d be interested in knowing how many working group members are in favo= r of either:
=0A
=0A
=0A
 
=0A
=0A
=0A
1.  Using RFC 5987 en= coding for the scope parameter.
=0A
=0A
=0A
2.  Continuing to specify no non-ASCII encoding for scope par= ameter values.
=0A
=0A
=0A
 
=0A
=0A
=0A
As a related issue, som= e working group members have objected to specifying UTF-8 encoding of the e= rror_description value, requesting the use of RFC 5987 encoding instead.&nb= sp; I=E2=80=99d also be interested=0A in knowing how many working group mem= bers are in favor of either:
=0A
=0A
=0A
 
=0A
=0A
=0A
A.  U= sing RFC 5987 encoding for the error_description parameter.
= =0A
=0A
=0A
B.  Continuing to specify UTF-8= encoding for the error_description parameter.
=0A
=0A=0A
 
=0A
=0A
=0A
(As editor, I would make the observation that if we choose RFC 598= 7 encoding for either of these parameters, it would be logical to do so for= the other one as well.)
=0A
=0A
=0A
 
=0A
=0A
=0A
In the interes= t of finishing the specification in a way that meets everyone=E2=80=99s nee= ds,
=0A
=0A
=0A
   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      -- Mike
=0A
=0A
= =0A
 
=0A
=0A
=0A
=0A=0A

=0A______________________= _________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mai= lman/listinfo/oauth
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A=0A


--0-510387924-1317704315=:93442-- From julian.reschke@gmx.de Tue Oct 4 00:25:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E58221F8C04 for ; Tue, 4 Oct 2011 00:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh2joIsADRJg for ; Tue, 4 Oct 2011 00:25:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E680121F8AD3 for ; Tue, 4 Oct 2011 00:25:43 -0700 (PDT) Received: (qmail invoked by alias); 04 Oct 2011 07:28:46 -0000 Received: from p5DCC8376.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.131.118] by mail.gmx.net (mp056) with SMTP; 04 Oct 2011 09:28:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX194nuBv5WN4wry9Z+exOKeywWEUouiimSTYav9dZq h9W8UY2Amm3M8C Message-ID: <4E8AB5AD.7030405@gmx.de> Date: Tue, 04 Oct 2011 09:28:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 07:25:45 -0000 On 2011-10-04 03:55, Mike Jones wrote: > As editor, based upon James’ input, I’d like to expand the set of > choices for the working group to consider by adding the possibility of > using JSON string encodings for scope and error_description where the > characters used for the encoding are restricted to the set of 7-bit > ASCII characters compatible with the HTTPbis and RFC 2617 parameter > syntaxes. > > 1. Using RFC 5987 encoding for the scope parameter. > > 2. Continuing to specify no non-ASCII encoding for scope parameter values. > > 3. Using JSON string encoding for the scope parameter. > > A. Using RFC 5987 encoding for the error_description parameter. > > B. Continuing to specify UTF-8 encoding for the error_description > parameter. > > C. Using JSON string encoding for the error_description parameter. > > As an individual, I’m sympathetic to the argument that RFC 5987 (with > “scope*” and language tags etc.) is overkill for OAuth implementations, > where neither of the sets of strings is intended to be presented to > end-users. Hence, the possible attractiveness of options 3 and C. > > Thoughts from others? > ... How is RFC 5987 encoding overkill, and JSON is not? Note that if you'd use the \u notation inside a quoted string, you need to escape the backslashes due to the quoted-string syntax; which is likely a new source of errors. Best regards, Julian From mike@mtcc.com Tue Oct 4 08:58:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FE321F8D08 for ; Tue, 4 Oct 2011 08:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtoZPvuz9kUt for ; Tue, 4 Oct 2011 08:58:34 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9DA21F8D05 for ; Tue, 4 Oct 2011 08:58:34 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p94G1bmr019567 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 4 Oct 2011 09:01:37 -0700 Message-ID: <4E8B2DE1.2090706@mtcc.com> Date: Tue, 04 Oct 2011 09:01:37 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: William Mills References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7504; t=1317744099; x=1318608099; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20Possible=20alternative=20r esolution=20to=20issue=2026 |Sender:=20 |To:=20William=20Mills=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=bKhwVRYuhl1lv8IRPBKjmNRC7yCQIWUyzgwyAab57/E=; b=tOVvR2A4tCkRYrXZfpWVgsvG/PRAl6RL45OrLZsx+QJ8lSXSTotEzZGYDO 3o0SYZrJXXsp02Y5fOEoGCkPOO734U71RYvQJdpnLEdloPJe3dnn0LfOMhqj 4Yq6JejTbR960N2yym7+udwCvMWErOIJJQYKBAcDYzw9dg+u8xV84=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:58:35 -0000 On 10/03/2011 09:58 PM, William Mills wrote: > You forgot: > > 4. Restrict the character set for scope to the point where these > issues all go away. Assuming that this is *completely* internal, and no end users will ever see either of these, this seems like the most prudent if interoperability is the primary goal. The principle of least surprise, and all. But completely internal is impossible to guarantee, so I guess the question is whether an incomprehensible katakana-encoded message/token is any worse than an incomprehensible ascii-7 english one to the poor end user who's trying to make sense of it. If it isn't then keeping things simple is probably safer. I assume the reason that 5987 exists is because as a whole, http shouldn't make any assumptions about whether users will see header field data. But these are individual cases here, not a protocol-wide mandate. Mike > > ------------------------------------------------------------------------ > *From:* Mike Jones > *To:* "oauth@ietf.org" > *Cc:* "Manger, James H" ; William > Mills > *Sent:* Monday, October 3, 2011 6:55 PM > *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue 26 > > As editor, based upon James’ input, I’d like to expand the set of > choices for the working group to consider by adding the possibility of > using JSON string encodings for scope and error_description where the > characters used for the encoding are restricted to the set of 7-bit > ASCII characters compatible with the HTTPbis and RFC 2617 parameter > syntaxes. > 1. Using RFC 5987 encoding for the scope parameter. > 2. Continuing to specify no non-ASCII encoding for scope parameter > values. > 3. Using JSON string encoding for the scope parameter. > A. Using RFC 5987 encoding for the error_description parameter. > B. Continuing to specify UTF-8 encoding for the error_description > parameter. > C. Using JSON string encoding for the error_description parameter. > As an individual, I’m sympathetic to the argument that RFC 5987 (with > “scope*†and language tags etc.) is overkill for OAuth > implementations, where neither of the sets of strings is intended to > be presented to end-users. Hence, the possible attractiveness of > options 3 and C. > Thoughts from others? > -- Mike > *From:* William Mills [mailto:wmills@yahoo-inc.com] > *Sent:* Sunday, October 02, 2011 11:01 PM > *To:* Manger, James H; Mike Jones; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 > I don't like dropping scope from the WWW-Authenticate responses, > because my current discovery usage requires scope to be returned so > that it can be passed to the auth server if the user is forced to > re-authenticate. > +1 for "explicitly restrict scope values to some subset of printable > ASCII in OAuth2 Core. Not being able to support Unicode in a new > protocol is slightly disappointing, but I can live with it." > > ------------------------------------------------------------------------ > *From:* "Manger, James H" > > *To:* Mike Jones >; "oauth@ietf.org > " > > *Sent:* Sunday, October 2, 2011 5:50 AM > *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 > The best solution is to drop the “scope†field from the > “WWW-Authenticate: Bearer ...†response header. “scope†is relevant to > an OAuth2-core flow, not to presenting a bearer token. “scope†could > make sense in a “WWW-Authenticate: OAuth2 ...†response header as long > as other necessary details such as an authorization URI were also > provided. Dropping “scope†and “error_description†(as the error > should be described in the response body) would eliminate these > encoding problems. > If the group really wants to keep “scopeâ€, I don’t think RFC 5987 is a > good solution. RFC 5987 might have been ok for adding > internationalization support to long-standing ASCII-only fields in a > world of multiple character sets – but none of that applies here. > Having to change the field name from “scope†to “scope*†when you have > a non-ASCII value is the biggest flaw. > The simplest solution is to explicitly restrict scope values to some > subset of printable ASCII in OAuth2 Core. Not being able to support > Unicode in a new protocol is slightly disappointing, but I can live > with it. > My preferred escaping solution would be a JSON string, UTF-8 encoded: > json.org , RFC 4627; value in double-quotes; slash is > the escape char; supports Unicode; eg scope="coll\u00E8gues". This is > backward-compatible with HTTP’s quoted-string syntax. It is > forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is > well-supported (and required for other OAuth2 exchanges). [I might > suggest json-string to the httpbis group as a global replacement for > quoted-string (or at least as a recommendation for new fields).] > -- > James Manger > *From:* oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Mike Jones > *Sent:* Friday, 30 September 2011 4:53 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 > There seems to now be more working group interest in representing > non-ASCII characters in scope strings than had previously been in > evidence. If we decide to define a standard representation for doing > so, using RFC 5987 (Character Set > and Language Encoding for Hypertext Transfer Protocol (HTTP) Header > Field Parameters) seems to be the clear choice. I’d be interested in > knowing how many working group members are in favor of either: > 1. Using RFC 5987 encoding for the scope parameter. > 2. Continuing to specify no non-ASCII encoding for scope parameter > values. > As a related issue, some working group members have objected to > specifying UTF-8 encoding of the error_description value, requesting > the use of RFC 5987 encoding instead. I’d also be interested in > knowing how many working group members are in favor of either: > A. Using RFC 5987 encoding for the error_description parameter. > B. Continuing to specify UTF-8 encoding for the error_description > parameter. > (As editor, I would make the observation that if we choose RFC 5987 > encoding for either of these parameters, it would be logical to do so > for the other one as well.) > In the interest of finishing the specification in a way that meets > everyone’s needs, > -- Mike > > _______________________________________________ > 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 phil.hunt@oracle.com Tue Oct 4 09:45:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B906621F8BEF for ; Tue, 4 Oct 2011 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.294 X-Spam-Level: X-Spam-Status: No, score=-5.294 tagged_above=-999 required=5 tests=[AWL=1.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EdlYwhH6JxY for ; Tue, 4 Oct 2011 09:45:03 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA0A21F8BD8 for ; Tue, 4 Oct 2011 09:45:03 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p94Gm5SO007293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Oct 2011 16:48:07 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p94Gm46K017826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Oct 2011 16:48:05 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p94GlxJu018038 for ; Tue, 4 Oct 2011 11:47:59 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Oct 2011 09:47:59 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Phil Hunt In-Reply-To: <4E8B2DE1.2090706@mtcc.com> Date: Tue, 4 Oct 2011 09:47:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> To: "oauth@ietf.org WG" X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E8B38C8.0019,ss=1,re=-2.300,fgs=0 Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 16:45:04 -0000 In most cases, scope has just been a set of simple "roles" as in = "readProfile", "updateStatus", etc. I tend to agree scope is an internal value that SHOULD never be seen by = end-users (this should be made clear). The meaning of a scope must be = conveyed in authorization dialog, the how of which is out of scope. = Since the resource server defines how it scopes information, it should = be able to explain the meaning of a scope request in localized language. I'm not against encoding the value if necessary to handle non-printable = characters. The issue I think comes back to complexity for the clients. = Would such encoding be problematic for the clients envisioned? Some examples I can think of: * A URL to a specific resource * An XML or JSON structure representing a more complex "grant" or policy = statement Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-10-04, at 9:01 AM, Michael Thomas wrote: > On 10/03/2011 09:58 PM, William Mills wrote: >> You forgot: >>=20 >> 4. Restrict the character set for scope to the point where these = issues all go away. >=20 > Assuming that this is *completely* internal, and no end users will = ever > see either of these, this seems like the most prudent if = interoperability > is the primary goal. The principle of least surprise, and all. >=20 > But completely internal is impossible to guarantee, so I guess the = question > is whether an incomprehensible katakana-encoded message/token is any > worse than an incomprehensible ascii-7 english one to the poor end = user > who's trying to make sense of it. If it isn't then keeping things = simple is > probably safer. I assume the reason that 5987 exists is because as a > whole, http shouldn't make any assumptions about whether users will > see header field data. But these are individual cases here, not a = protocol-wide > mandate. >=20 > Mike >=20 >>=20 >> = ------------------------------------------------------------------------ >> *From:* Mike Jones >> *To:* "oauth@ietf.org" >> *Cc:* "Manger, James H" ; William = Mills >> *Sent:* Monday, October 3, 2011 6:55 PM >> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue 26 >>=20 >> As editor, based upon James=92 input, I=92d like to expand the set of = choices for the working group to consider by adding the possibility of = using JSON string encodings for scope and error_description where the = characters used for the encoding are restricted to the set of 7-bit = ASCII characters compatible with the HTTPbis and RFC 2617 parameter = syntaxes. >> 1. Using RFC 5987 encoding for the scope parameter. >> 2. Continuing to specify no non-ASCII encoding for scope parameter = values. >> 3. Using JSON string encoding for the scope parameter. >> A. Using RFC 5987 encoding for the error_description parameter. >> B. Continuing to specify UTF-8 encoding for the error_description = parameter. >> C. Using JSON string encoding for the error_description parameter. >> As an individual, I=92m sympathetic to the argument that RFC 5987 = (with =93scope*=94 and language tags etc.) is overkill for OAuth = implementations, where neither of the sets of strings is intended to be = presented to end-users. Hence, the possible attractiveness of options 3 = and C. >> Thoughts from others? >> -- = Mike >> *From:* William Mills [mailto:wmills@yahoo-inc.com] >> *Sent:* Sunday, October 02, 2011 11:01 PM >> *To:* Manger, James H; Mike Jones; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 >> I don't like dropping scope from the WWW-Authenticate responses, = because my current discovery usage requires scope to be returned so that = it can be passed to the auth server if the user is forced to = re-authenticate. >> +1 for "explicitly restrict scope values to some subset of printable = ASCII in OAuth2 Core. Not being able to support Unicode in a new = protocol is slightly disappointing, but I can live with it." >>=20 >> = ------------------------------------------------------------------------ >> *From:* "Manger, James H" > >> *To:* Mike Jones >; "oauth@ietf.org = " > >> *Sent:* Sunday, October 2, 2011 5:50 AM >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 >> The best solution is to drop the =93scope=94 field from the = =93WWW-Authenticate: Bearer ...=94 response header. =93scope=94 is = relevant to an OAuth2-core flow, not to presenting a bearer token. = =93scope=94 could make sense in a =93WWW-Authenticate: OAuth2 ...=94 = response header as long as other necessary details such as an = authorization URI were also provided. Dropping =93scope=94 and = =93error_description=94 (as the error should be described in the = response body) would eliminate these encoding problems. >> If the group really wants to keep =93scope=94, I don=92t think RFC = 5987 is a good solution. RFC 5987 might have been ok for adding = internationalization support to long-standing ASCII-only fields in a = world of multiple character sets =96 but none of that applies here. = Having to change the field name from =93scope=94 to =93scope*=94 when = you have a non-ASCII value is the biggest flaw. >> The simplest solution is to explicitly restrict scope values to some = subset of printable ASCII in OAuth2 Core. Not being able to support = Unicode in a new protocol is slightly disappointing, but I can live with = it. >> My preferred escaping solution would be a JSON string, UTF-8 encoded: = json.org , RFC 4627; value in double-quotes; slash is = the escape char; supports Unicode; eg scope=3D"coll\u00E8gues". This is = backward-compatible with HTTP=92s quoted-string syntax. It is = forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is = well-supported (and required for other OAuth2 exchanges). [I might = suggest json-string to the httpbis group as a global replacement for = quoted-string (or at least as a recommendation for new fields).] >> -- >> James Manger >> *From:* oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] = *On Behalf Of *Mike Jones >> *Sent:* Friday, 30 September 2011 4:53 AM >> *To:* oauth@ietf.org >> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 >> There seems to now be more working group interest in representing = non-ASCII characters in scope strings than had previously been in = evidence. If we decide to define a standard representation for doing = so, using RFC 5987 (Character Set = and Language Encoding for Hypertext Transfer Protocol (HTTP) Header = Field Parameters) seems to be the clear choice. I=92d be interested in = knowing how many working group members are in favor of either: >> 1. Using RFC 5987 encoding for the scope parameter. >> 2. Continuing to specify no non-ASCII encoding for scope parameter = values. >> As a related issue, some working group members have objected to = specifying UTF-8 encoding of the error_description value, requesting the = use of RFC 5987 encoding instead. I=92d also be interested in knowing = how many working group members are in favor of either: >> A. Using RFC 5987 encoding for the error_description parameter. >> B. Continuing to specify UTF-8 encoding for the error_description = parameter. >> (As editor, I would make the observation that if we choose RFC 5987 = encoding for either of these parameters, it would be logical to do so = for the other one as well.) >> In the interest of finishing the specification in a way that meets = everyone=92s needs, >> -- Mike >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=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 From wmills@yahoo-inc.com Tue Oct 4 09:55:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8CB21F8CB2 for ; Tue, 4 Oct 2011 09:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.405 X-Spam-Level: X-Spam-Status: No, score=-17.405 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7FWqIF1l4fz for ; Tue, 4 Oct 2011 09:55:09 -0700 (PDT) Received: from nm16.bullet.mail.ne1.yahoo.com (nm16.bullet.mail.ne1.yahoo.com [98.138.90.79]) by ietfa.amsl.com (Postfix) with SMTP id D40A521F8CA9 for ; Tue, 4 Oct 2011 09:55:08 -0700 (PDT) Received: from [98.138.90.55] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 04 Oct 2011 16:58:08 -0000 Received: from [98.138.88.239] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 04 Oct 2011 16:58:08 -0000 Received: from [127.0.0.1] by omp1039.mail.ne1.yahoo.com with NNFMP; 04 Oct 2011 16:58:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 630021.7241.bm@omp1039.mail.ne1.yahoo.com Received: (qmail 41165 invoked by uid 60001); 4 Oct 2011 16:58:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1317747487; bh=cKUrkWSYFCbH5rUiYrvKPfG6ndLSiVFCssQ4fcO1G2I=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hApk1zcUOp43LjbTbzbutCmPrmqevtMSOmcwJe7O7lB/2OLjE3HEm4qQZsdpJs9fL15T/QbqUU4mkNE1RV1wbOkgQd8xIA2STFmJrmU5qKu2uYLHBie0yIfJFoKRIYqqDsXnwMOkzBtuWRjgA9SseU7Lm3uikzNV7hzOkJvdSBE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qpzB30W3UiDttBvYKl7LpuGRWNKsYhW9tDpprQQO7dyD89KNOAspmttXykte7OfKDqSK8Uo9MpgroLzBZWX++YE+nArSHG0gAMVkYer8ieOykGXA5rvEE5g0gEGmmubA+6Wuz0xRXrkgYrvcQLr54gq7+d8G4KRazwpBKkWVidI=; X-YMail-OSG: fJpMvDgVM1lrnkq6aUwKXDuXa0Wsf6MrEUmeNuXBYYe8uAG MYYpTHw2CxhHifhl54Wr9IuwWbACjecMwd6MPAMRYzWCjOukBAkPAdDrk4wM 9uZ7pK2VtDvCWJTSib4_QovDuFjPAtFYqJJvB2EiZYweR0aFJL7LJhO3tRnP F3tsuqmarTKPUBP85Mzz2NEW4mzUJmsXievU4wuCGcNf5wM1r.Kd2pgxaff7 27vYbCbUW4A.ScI3iX_dn_z4u3G_lQNJ7PDNEKFhrhNFg1VKn0WKnOSpg0xC 6JPOdahPMxCXW32QdlrH3uk6Z38gvPt2k_iDXNnqnj66mh3xOoXIOyN6cLkB mFtym6_COOrw1Ja3BTSYcPuRKw2xMOB3HrX8atUgJTygHfLvBokfLM7DzOjc FxtlOXNnyx4XwBR6AzFnZ_zKpRwBSM95yT9HmyXY9mCqSQJ3JU3uHd6vO1iu B3FJ.vozSqSk_c9HxT277zS5Msa3O7zpDhOVDV_3l0Rz_rhzqlGkfR2ZgKJ5 k40yBnPDPz_IlxiZ1TV_F3aSGiLKwgQ-- Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Tue, 04 Oct 2011 09:58:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> Message-ID: <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 4 Oct 2011 09:58:07 -0700 (PDT) From: William Mills To: Phil Hunt , "oauth@ietf.org WG" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1378800985-1317747487=:89926" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 16:55:11 -0000 --0-1378800985-1317747487=:89926 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't believe that scope is the right place to carry a more complex grant= , those would live in the token.=C2=A0 That would more logically go in the = token.=C2=A0 XML gets weird when you get to the part about space separation= oand order doesn't matter.=C2=A0 Scope's current definition makes it incomp= atible in sublte ways with using it for XML.=0A=0A=0A=0A___________________= _____________=0AFrom: Phil Hunt =0ATo: "oauth@ietf.or= g WG" =0ASent: Tuesday, October 4, 2011 9:47 AM=0ASubject: = Re: [OAUTH-WG] Possible alternative resolution to issue 26=0A=0AIn most cas= es, scope has just been a set of simple "roles" as in "readProfile", "updat= eStatus", etc.=0A=0AI tend to agree scope is an internal value that SHOULD = never be seen by end-users (this should be made clear). The meaning of a sc= ope must be conveyed in authorization dialog, the how of which is out of sc= ope.=C2=A0 Since the resource server defines how it scopes information, it = should be able to explain the meaning of a scope request in localized langu= age.=0A=0AI'm not against encoding the value if necessary to handle non-pri= ntable characters. The issue I think comes back to complexity for the clien= ts. Would such encoding be problematic for the clients envisioned?=0A=0ASom= e examples I can think of:=0A* A URL to a specific resource=0A* An XML or J= SON structure representing a more complex "grant" or policy statement=0A=0A= Phil=0A=0A@independentid=0Awww.independentid.com=0Aphil.hunt@oracle.com=0A= =0A=0A=0A=0A=0AOn 2011-10-04, at 9:01 AM, Michael Thomas wrote:=0A=0A> On 1= 0/03/2011 09:58 PM, William Mills wrote:=0A>> You forgot:=0A>> =0A>> 4.=C2= =A0 Restrict the character set for scope to the point where these issues al= l go away.=0A> =0A> Assuming that this is *completely* internal, and no end= users will ever=0A> see either of these,=C2=A0 this seems like the most pr= udent if interoperability=0A> is the primary goal. The principle of least s= urprise, and all.=0A> =0A> But completely internal is impossible to guarant= ee, so I guess the question=0A> is whether an incomprehensible katakana-enc= oded message/token is any=0A> worse than=C2=A0 an incomprehensible ascii-7 = english one to the poor end user=0A> who's trying to make sense of it. If i= t isn't then keeping things simple is=0A> probably safer. I assume the reas= on that 5987 exists is because as a=0A> whole, http shouldn't make any assu= mptions about whether users will=0A> see header field data. But these are i= ndividual cases here, not a protocol-wide=0A> mandate.=0A> =0A> Mike=0A> = =0A>> =0A>> ---------------------------------------------------------------= ---------=0A>> *From:* Mike Jones =0A>> *To:* = "oauth@ietf.org" =0A>> *Cc:* "Manger, James H" ; William Mills =0A>> *Sent:* Mo= nday, October 3, 2011 6:55 PM=0A>> *Subject:* RE: [OAUTH-WG] Possible alter= native resolution to issue 26=0A>> =0A>> As editor, based upon James=E2=80= =99 input, I=E2=80=99d like to expand the set of choices for the working gr= oup to consider by adding the possibility of using JSON string encodings fo= r scope and error_description where the characters used for the encoding ar= e restricted to the set of 7-bit ASCII characters compatible with the HTTPb= is and RFC 2617 parameter syntaxes.=0A>> 1.=C2=A0 Using RFC 5987 encoding f= or the scope parameter.=0A>> 2.=C2=A0 Continuing to specify no non-ASCII en= coding for scope parameter values.=0A>> 3.=C2=A0 Using JSON string encoding= for the scope parameter.=0A>> A.=C2=A0 Using RFC 5987 encoding for the err= or_description parameter.=0A>> B.=C2=A0 Continuing to specify UTF-8 encodin= g for the error_description parameter.=0A>> C.=C2=A0 Using JSON string enco= ding for the error_description parameter.=0A>> As an individual, I=E2=80=99= m sympathetic to the argument that RFC 5987 (with =E2=80=9Cscope*=E2=80=9D = and language tags etc.) is overkill for OAuth implementations, where neithe= r of the sets of strings is intended to be presented to end-users.=C2=A0 He= nce, the possible attractiveness of options 3 and C.=0A>> Thoughts from oth= ers?=0A>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -- Mike=0A>> *From:* William Mills [mailto:wmills@yahoo-inc.com]= =0A>> *Sent:* Sunday, October 02, 2011 11:01 PM=0A>> *To:* Manger, James H;= Mike Jones; oauth@ietf.org=0A>> *Subject:* Re: [OAUTH-WG] Possible alterna= tive resolution to issue 26=0A>> I don't like dropping scope from the WWW-A= uthenticate responses, because my current discovery usage requires scope to= be returned so that it can be passed to the auth server if the user is for= ced to re-authenticate.=0A>> +1 for "explicitly restrict scope values to so= me subset of printable ASCII in OAuth2 Core. Not being able to support Unic= ode in a new protocol is slightly disappointing, but I can live with it."= =0A>> =0A>> ---------------------------------------------------------------= ---------=0A>> *From:* "Manger, James H" >=0A>> *To:* Mike Jones >; "oauth@ietf.org " >=0A>> *Sent:*= Sunday, October 2, 2011 5:50 AM=0A>> *Subject:* Re: [OAUTH-WG] Possible al= ternative resolution to issue 26=0A>> The best solution is to drop the =E2= =80=9Cscope=E2=80=9D field from the =E2=80=9CWWW-Authenticate: Bearer ...= =E2=80=9D response header. =E2=80=9Cscope=E2=80=9D is relevant to an OAuth2= -core flow, not to presenting a bearer token. =E2=80=9Cscope=E2=80=9D could= make sense in a =E2=80=9CWWW-Authenticate: OAuth2 ...=E2=80=9D response he= ader as long as other necessary details such as an authorization URI were a= lso provided. Dropping =E2=80=9Cscope=E2=80=9D and =E2=80=9Cerror_descripti= on=E2=80=9D (as the error should be described in the response body) would e= liminate these encoding problems.=0A>> If the group really wants to keep = =E2=80=9Cscope=E2=80=9D, I don=E2=80=99t think RFC 5987 is a good solution.= RFC 5987 might have been ok for adding internationalization support to lon= g-standing ASCII-only fields in a world of multiple character sets =E2=80= =93 but none of that applies here. Having to change the field name from =E2= =80=9Cscope=E2=80=9D to =E2=80=9Cscope*=E2=80=9D when you have a non-ASCII = value is the biggest flaw.=0A>> The simplest solution is to explicitly rest= rict scope values to some subset of printable ASCII in OAuth2 Core. Not bei= ng able to support Unicode in a new protocol is slightly disappointing, but= I can live with it.=0A>> My preferred escaping solution would be a JSON st= ring, UTF-8 encoded: json.org , RFC 4627; value in double-= quotes; slash is the escape char; supports Unicode; eg scope=3D"coll\u00E8g= ues". This is backward-compatible with HTTP=E2=80=99s quoted-string syntax.= It is forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is= well-supported (and required for other OAuth2 exchanges). [I might suggest= json-string to the httpbis group as a global replacement for quoted-string= (or at least as a recommendation for new fields).]=0A>> --=0A>> James Mang= er=0A>> *From:* oauth-bounces@ietf.org [mai= lto:oauth-bounces@ietf.org] *On Be= half Of *Mike Jones=0A>> *Sent:* Friday, 30 September 2011 4:53 AM=0A>> *To= :* oauth@ietf.org =0A>> *Subject:* [OAUTH-WG] Possib= le alternative resolution to issue 26=0A>> There seems to now be more worki= ng group interest in representing non-ASCII characters in scope strings tha= n had previously been in evidence.=C2=A0 If we decide to define a standard = representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hypertext Transfer Protocol = (HTTP) Header Field Parameters) seems to be the clear choice.=C2=A0 I=E2=80= =99d be interested in knowing how many working group members are in favor o= f either:=0A>> 1.=C2=A0 Using RFC 5987 encoding for the scope parameter.=0A= >> 2.=C2=A0 Continuing to specify no non-ASCII encoding for scope parameter= values.=0A>> As a related issue, some working group members have objected = to specifying UTF-8 encoding of the error_description value, requesting the= use of RFC 5987 encoding instead.=C2=A0 I=E2=80=99d also be interested in = knowing how many working group members are in favor of either:=0A>> A.=C2= =A0 Using RFC 5987 encoding for the error_description parameter.=0A>> B.=C2= =A0 Continuing to specify UTF-8 encoding for the error_description paramete= r.=0A>> (As editor, I would make the observation that if we choose RFC 5987= encoding for either of these parameters, it would be logical to do so for = the other one as well.)=0A>> In the interest of finishing the specification= in a way that meets everyone=E2=80=99s needs,=0A>>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike=0A>> =0A>> _________________= ______________________________=0A>> OAuth mailing list=0A>> OAuth@ietf.org = =0A>> https://www.ietf.org/mailman/listinfo/oauth=0A= >> =0A>> =0A>> =0A>> =0A>> _______________________________________________= =0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mail= man/listinfo/oauth=0A>>=C2=A0 =0A> =0A> ___________________________________= ____________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf= .org/mailman/listinfo/oauth=0A=0A__________________________________________= _____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/= listinfo/oauth --0-1378800985-1317747487=:89926 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't believe that scope is the right place to carry a more complex gra= nt, those would live in the token.  That would more logically go in th= e token.  XML gets weird when you get to the part about space separati= onoand order doesn't matter.  Scope's current definition makes it inco= mpatible in sublte ways with using it for XML.

From: Phil Hunt &l= t;phil.hunt@oracle.com>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Sent: Tuesday, October 4, 2011 9:47 AM
Subject: Re: [OAUTH-WG] Possible alterna= tive resolution to issue 26

=0AIn most cases, scope has just = been a set of simple "roles" as in "readProfile", "updateStatus", etc.
<= br>I tend to agree scope is an internal value that SHOULD never be seen by = end-users (this should be made clear). The meaning of a scope must be conve= yed in authorization dialog, the how of which is out of scope.  Since = the resource server defines how it scopes information, it should be able to= explain the meaning of a scope request in localized language.

I'm n= ot against encoding the value if necessary to handle non-printable characte= rs. The issue I think comes back to complexity for the clients. Would such = encoding be problematic for the clients envisioned?

Some examples I = can think of:
* A URL to a specific resource
* An XML or JSON structu= re representing a more complex "grant" or policy statement

Phil
<= br>@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-10-04, at 9:01 A= M, Michael Thomas wrote:

> On 10/03/2011 09:58 PM, William Mills = wrote:
>> You forgot:
>>
>> 4.  Restrict t= he character set for scope to the point where these issues all go away.
= >
> Assuming that this is *completely* internal, and no end users= will ever
> see either of these,  this seems like the most prud= ent if interoperability
> is the primary goal. The principle of least= surprise, and all.
>
> But completely internal is impossible = to guarantee, so I guess the question
> is whether an incomprehensibl= e katakana-encoded message/token is any
> worse than  an incompr= ehensible ascii-7 english one to the poor end user
> who's trying to = make sense of it. If it isn't then keeping things simple is
> probably safer. I assume the reason that 5987 exists is because as a
&g= t; whole, http shouldn't make any assumptions about whether users will
&= gt; see header field data. But these are individual cases here, not a proto= col-wide
> mandate.
>
> Mike
>
>>
&g= t;> --------------------------------------------------------------------= ----
>> *From:* Mike Jones <Michael.Jones@mi= crosoft.com>
>> *To:* "oauth@ietf.org" <oauth@ietf.org>
= >> *Cc:* "Manger, James H" <James.H.Man= ger@team.telstra.com>; William Mills <wmills@yahoo-inc.com>
>> *Sent:* Monday, October 3, 2011= 6:55 PM
>> *Subject:* RE: [OAUTH-WG] Possible alternative resolut= ion to issue 26
>>
>> As editor, based upon James=E2=80= =99 input, I=E2=80=99d like to expand the set of choices for the working gr= oup to consider by adding the possibility of using JSON string encodings fo= r scope and error_description where the characters used for the encoding ar= e restricted to the set of 7-bit ASCII characters compatible with the HTTPb= is and RFC 2617 parameter syntaxes.
>> 1.  Using RFC 5987 enc= oding for the scope parameter.
>> 2.  Continuing to specify n= o non-ASCII encoding for scope parameter values.
>> 3.  Using= JSON string encoding for the scope parameter.
>> A.  Using R= FC 5987 encoding for the error_description parameter.
>> B.  = Continuing to specify UTF-8 encoding for the error_description parameter.
>>= C.  Using JSON string encoding for the error_description parameter.>> As an individual, I=E2=80=99m sympathetic to the argument that R= FC 5987 (with =E2=80=9Cscope*=E2=80=9D and language tags etc.) is overkill = for OAuth implementations, where neither of the sets of strings is intended= to be presented to end-users.  Hence, the possible attractiveness of = options 3 and C.
>> Thoughts from others?
>>   =                     &nbs= p;                     &n= bsp;                 -- Mike
>= ;> *From:* William Mills [mailto:wmills@yahoo-inc.com]
>&= gt; *Sent:* Sunday, October 02, 2011 11:01 PM
>> *To:* Manger, Jam= es H; Mike Jones; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Possible alternat= ive resolution to issue 26
>> I don't like dropping scope from the= WWW-Authenticate responses, because my current discovery usage requires sc= ope to be returned so that it can be passed to the auth server if the user = is forced to re-authenticate.
>> +1 for "explicitly restrict scope= values to some subset of printable ASCII in OAuth2 Core. Not being able to= support Unicode in a new protocol is slightly disappointing, but I can liv= e with it."
>>
>> --------------------------------------= ----------------------------------
>> *From:* "Manger, James H" &l= t;James.H.Manger@team.telstra.com <mailto= :James.H.Manger@team.telstr= a.com>>
>> *To:* Mike Jones <Micha= el.Jones@microsoft.com <mailto:Michael.Jones@micr= osoft.com>>; "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org= <mailto:oauth@ietf.org>>
>> *Sent:* Sunday, October 2, = 2011 5:50 AM
>> *Subject:* Re: [OAUTH-WG] Possible alternative res= olution to issue 26
>> The best solution is to drop the =E2=80=9Cs= cope=E2=80=9D field from the =E2=80=9CWWW-Authenticate: Bearer ...=E2=80=9D response header. =E2=80=9Cs= cope=E2=80=9D is relevant to an OAuth2-core flow, not to presenting a beare= r token. =E2=80=9Cscope=E2=80=9D could make sense in a =E2=80=9CWWW-Authent= icate: OAuth2 ...=E2=80=9D response header as long as other necessary detai= ls such as an authorization URI were also provided. Dropping =E2=80=9Cscope= =E2=80=9D and =E2=80=9Cerror_description=E2=80=9D (as the error should be d= escribed in the response body) would eliminate these encoding problems.
= >> If the group really wants to keep =E2=80=9Cscope=E2=80=9D, I don= =E2=80=99t think RFC 5987 is a good solution. RFC 5987 might have been ok f= or adding internationalization support to long-standing ASCII-only fields i= n a world of multiple character sets =E2=80=93 but none of that applies her= e. Having to change the field name from =E2=80=9Cscope=E2=80=9D to =E2=80= =9Cscope*=E2=80=9D when you have a non-ASCII value is the biggest flaw.
= >> The simplest solution is to explicitly restrict scope values to so= me subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disa= ppointing, but I can live with it.
>> My preferred escaping soluti= on would be a JSON string, UTF-8 encoded: json.org <http://json.org>, RFC 4627; value in doubl= e-quotes; slash is the escape char; supports Unicode; eg scope=3D"coll\u00E= 8gues". This is backward-compatible with HTTP=E2=80=99s quoted-string synta= x. It is forward-compatible with UTF-8 HTTP headers (if that occurs). JSON = is well-supported (and required for other OAuth2 exchanges). [I might sugge= st json-string to the httpbis group as a global replacement for quoted-stri= ng (or at least as a recommendation for new fields).]
>> --
>= ;> James Manger
>> *From:* oauth-bounces@ietf.org = <mailto:oauth-bounces@ietf.org> [mai= lto:oauth-bounces@ietf.org] <mailto:[mailto:oauth-= bounces@ietf.org]> *On Behalf Of *Mike Jones
>> *Sent:* Fri= day, 30 September 2011 4:53 AM
>> *To:* oauth@ietf.org <mailto:oauth@ietf= .org>
>> *Subject:* [OAUTH-WG] Possible alternative resolut= ion to issue 26
>> There seems to now be more working group intere= st in representing non-ASCII characters in scope strings than had previousl= y been in evidence.  If we decide to define a standard representation = for doing so, using RFC 5987 <http://tools.ietf.org/html/rfc5987> (Character Se= t and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field= Parameters) seems to be the clear choice.  I=E2=80=99d be interested = in knowing how many working group members are in favor of either:
>&g= t; 1.  Using RFC 5987 encoding for the scope parameter.
>> 2.=   Continuing to specify no non-ASCII encoding for scope parameter valu= es.
>> As a related issue, some working group members have objecte= d to specifying UTF-8 encoding of the error_description value, requesting t= he use of RFC 5987 encoding instead.  I=E2=80=99d also be interested i= n knowing how many working group members are in favor of either:
>>= ; A.  Using RFC 5987 encoding for the error_description parameter.
= >> B.  Continuing to specify UTF-8 encoding for the error_descri= ption parameter.
>> (As editor, I would make the observation that = if we choose RFC 5987 encoding for either of these parameters, it would be logic= al to do so for the other one as well.)
>> In the interest of fini= shing the specification in a way that meets everyone=E2=80=99s needs,
&g= t;>                   =                     &nbs= p;                   -- Mike>>
>> _______________________________________________
= >> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>= ;
>>
>>
>>
>> _______________________________________________
>> OAuth mailing = list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listin= fo/oauth
>> 
>
> _________________________= ______________________
> OAuth mailing list
> OAuth@ietf.org
&g= t; https://www.ietf.org/mailman/listinfo/oauth

__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/oauth


--0-1378800985-1317747487=:89926-- From phil.hunt@oracle.com Tue Oct 4 10:15:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB0C21F8D80 for ; Tue, 4 Oct 2011 10:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcpI--190O4Y for ; Tue, 4 Oct 2011 10:15:39 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 88F6C21F8D7A for ; Tue, 4 Oct 2011 10:15:39 -0700 (PDT) Received: from ucsinet23.oracle.com (ucsinet23.oracle.com [156.151.31.71]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p94HIgPE003100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Oct 2011 17:18:44 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet23.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p94HIf3v020730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Oct 2011 17:18:42 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p94HIaot027545; Tue, 4 Oct 2011 12:18:36 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Oct 2011 10:18:35 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-61-139097759 From: Phil Hunt In-Reply-To: <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 4 Oct 2011 10:18:33 -0700 Message-Id: <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Source-IP: ucsinet23.oracle.com [156.151.31.71] X-CT-RefId: str=0001.0A090209.4E8B3FF4.01DA,ss=1,re=-2.300,fgs=0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:15:41 -0000 --Apple-Mail-61-139097759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I very much agree with you there. As I said, simple roles are best and = are by far the primary case. I'm just not so sure we should close the door. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-10-04, at 9:58 AM, William Mills wrote: > I don't believe that scope is the right place to carry a more complex = grant, those would live in the token. That would more logically go in = the token. XML gets weird when you get to the part about space = separationoand order doesn't matter. Scope's current definition makes = it incompatible in sublte ways with using it for XML. >=20 > From: Phil Hunt > To: "oauth@ietf.org WG" > Sent: Tuesday, October 4, 2011 9:47 AM > Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 >=20 > In most cases, scope has just been a set of simple "roles" as in = "readProfile", "updateStatus", etc. >=20 > I tend to agree scope is an internal value that SHOULD never be seen = by end-users (this should be made clear). The meaning of a scope must be = conveyed in authorization dialog, the how of which is out of scope. = Since the resource server defines how it scopes information, it should = be able to explain the meaning of a scope request in localized language. >=20 > I'm not against encoding the value if necessary to handle = non-printable characters. The issue I think comes back to complexity for = the clients. Would such encoding be problematic for the clients = envisioned? >=20 > Some examples I can think of: > * A URL to a specific resource > * An XML or JSON structure representing a more complex "grant" or = policy statement >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2011-10-04, at 9:01 AM, Michael Thomas wrote: >=20 > > On 10/03/2011 09:58 PM, William Mills wrote: > >> You forgot: > >>=20 > >> 4. Restrict the character set for scope to the point where these = issues all go away. > >=20 > > Assuming that this is *completely* internal, and no end users will = ever > > see either of these, this seems like the most prudent if = interoperability > > is the primary goal. The principle of least surprise, and all. > >=20 > > But completely internal is impossible to guarantee, so I guess the = question > > is whether an incomprehensible katakana-encoded message/token is any > > worse than an incomprehensible ascii-7 english one to the poor end = user > > who's trying to make sense of it. If it isn't then keeping things = simple is > > probably safer. I assume the reason that 5987 exists is because as a > > whole, http shouldn't make any assumptions about whether users will > > see header field data. But these are individual cases here, not a = protocol-wide > > mandate. > >=20 > > Mike > >=20 > >>=20 > >> = ------------------------------------------------------------------------ > >> *From:* Mike Jones > >> *To:* "oauth@ietf.org" > >> *Cc:* "Manger, James H" ; William = Mills > >> *Sent:* Monday, October 3, 2011 6:55 PM > >> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue = 26 > >>=20 > >> As editor, based upon James=92 input, I=92d like to expand the set = of choices for the working group to consider by adding the possibility = of using JSON string encodings for scope and error_description where the = characters used for the encoding are restricted to the set of 7-bit = ASCII characters compatible with the HTTPbis and RFC 2617 parameter = syntaxes. > >> 1. Using RFC 5987 encoding for the scope parameter. > >> 2. Continuing to specify no non-ASCII encoding for scope parameter = values. > >> 3. Using JSON string encoding for the scope parameter. > >> A. Using RFC 5987 encoding for the error_description parameter. > >> B. Continuing to specify UTF-8 encoding for the error_description = parameter. > >> C. Using JSON string encoding for the error_description parameter. > >> As an individual, I=92m sympathetic to the argument that RFC 5987 = (with =93scope*=94 and language tags etc.) is overkill for OAuth = implementations, where neither of the sets of strings is intended to be = presented to end-users. Hence, the possible attractiveness of options 3 = and C. > >> Thoughts from others? > >> -- = Mike > >> *From:* William Mills [mailto:wmills@yahoo-inc.com] > >> *Sent:* Sunday, October 02, 2011 11:01 PM > >> *To:* Manger, James H; Mike Jones; oauth@ietf.org > >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue = 26 > >> I don't like dropping scope from the WWW-Authenticate responses, = because my current discovery usage requires scope to be returned so that = it can be passed to the auth server if the user is forced to = re-authenticate. > >> +1 for "explicitly restrict scope values to some subset of = printable ASCII in OAuth2 Core. Not being able to support Unicode in a = new protocol is slightly disappointing, but I can live with it." > >>=20 > >> = ------------------------------------------------------------------------ > >> *From:* "Manger, James H" > > >> *To:* Mike Jones >; "oauth@ietf.org = " > > >> *Sent:* Sunday, October 2, 2011 5:50 AM > >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue = 26 > >> The best solution is to drop the =93scope=94 field from the = =93WWW-Authenticate: Bearer ...=94 response header. =93scope=94 is = relevant to an OAuth2-core flow, not to presenting a bearer token. = =93scope=94 could make sense in a =93WWW-Authenticate: OAuth2 ...=94 = response header as long as other necessary details such as an = authorization URI were also provided. Dropping =93scope=94 and = =93error_description=94 (as the error should be described in the = response body) would eliminate these encoding problems. > >> If the group really wants to keep =93scope=94, I don=92t think RFC = 5987 is a good solution. RFC 5987 might have been ok for adding = internationalization support to long-standing ASCII-only fields in a = world of multiple character sets =96 but none of that applies here. = Having to change the field name from =93scope=94 to =93scope*=94 when = you have a non-ASCII value is the biggest flaw. > >> The simplest solution is to explicitly restrict scope values to = some subset of printable ASCII in OAuth2 Core. Not being able to support = Unicode in a new protocol is slightly disappointing, but I can live with = it. > >> My preferred escaping solution would be a JSON string, UTF-8 = encoded: json.org , RFC 4627; value in double-quotes; = slash is the escape char; supports Unicode; eg scope=3D"coll\u00E8gues". = This is backward-compatible with HTTP=92s quoted-string syntax. It is = forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is = well-supported (and required for other OAuth2 exchanges). [I might = suggest json-string to the httpbis group as a global replacement for = quoted-string (or at least as a recommendation for new fields).] > >> -- > >> James Manger > >> *From:* oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] = *On Behalf Of *Mike Jones > >> *Sent:* Friday, 30 September 2011 4:53 AM > >> *To:* oauth@ietf.org > >> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 > >> There seems to now be more working group interest in representing = non-ASCII characters in scope strings than had previously been in = evidence. If we decide to define a standard representation for doing = so, using RFC 5987 (Character Set = and Language Encoding for Hypertext Transfer Protocol (HTTP) Header = Field Parameters) seems to be the clear choice. I=92d be interested in = knowing how many working group members are in favor of either: > >> 1. Using RFC 5987 encoding for the scope parameter. > >> 2. Continuing to specify no non-ASCII encoding for scope parameter = values. > >> As a related issue, some working group members have objected to = specifying UTF-8 encoding of the error_description value, requesting the = use of RFC 5987 encoding instead. I=92d also be interested in knowing = how many working group members are in favor of either: > >> A. Using RFC 5987 encoding for the error_description parameter. > >> B. Continuing to specify UTF-8 encoding for the error_description = parameter. > >> (As editor, I would make the observation that if we choose RFC 5987 = encoding for either of these parameters, it would be logical to do so = for the other one as well.) > >> In the interest of finishing the specification in a way that meets = everyone=92s needs, > >> -- Mike > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail-61-139097759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = very much agree with you there.  As I said, simple roles are best = and are by far the primary case.

I'm just not so sure = we should close the door.


On 2011-10-04, at 9:58 AM, William Mills wrote:

I = don't believe that scope is the right place to carry a more complex = grant, those would live in the token.  That would more logically go = in the token.  XML gets weird when you get to the part about space = separationoand order doesn't matter.  Scope's current definition = makes it incompatible in sublte ways with using it for = XML.

From: Phil Hunt <phil.hunt@oracle.com>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Sent: Tuesday, October 4, 2011 9:47 AM
Subject: Re: [OAUTH-WG] Possible = alternative resolution to issue 26

In most cases, scope has just been a set of simple "roles" as in = "readProfile", "updateStatus", etc.

I tend to agree scope is an = internal value that SHOULD never be seen by end-users (this should be = made clear). The meaning of a scope must be conveyed in authorization = dialog, the how of which is out of scope.  Since the resource = server defines how it scopes information, it should be able to explain = the meaning of a scope request in localized language.

I'm not = against encoding the value if necessary to handle non-printable = characters. The issue I think comes back to complexity for the clients. = Would such encoding be problematic for the clients = envisioned?

Some examples I can think of:
* A URL to a = specific resource
* An XML or JSON structure representing a more = complex "grant" or policy = statement

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


<= br>

On 2011-10-04, at 9:01 AM, Michael Thomas wrote:

> = On 10/03/2011 09:58 PM, William Mills wrote:
>> You = forgot:
>>
>> 4.  Restrict the character set for = scope to the point where these issues all go away.
>
> = Assuming that this is *completely* internal, and no end users will = ever
> see either of these,  this seems like the most prudent = if interoperability
> is the primary goal. The principle of least = surprise, and all.
>
> But completely internal is = impossible to guarantee, so I guess the question
> is whether an = incomprehensible katakana-encoded message/token is any
> worse = than  an incomprehensible ascii-7 english one to the poor end = user
> who's trying to make sense of it. If it isn't then keeping = things simple is
> probably safer. I assume the reason that 5987 exists is because as = a
> whole, http shouldn't make any assumptions about whether users = will
> see header field data. But these are individual cases here, = not a protocol-wide
> mandate.
>
> Mike
> =
>>
>> = ------------------------------------------------------------------------>> *From:* Mike Jones <Michael.Jones@microsoft.com>
>> *To:* "oauth@ietf.org" <oauth@ietf.org>
>> *Cc:* = "Manger, James H" <James.H.Manger@team.telstr= a.com>; William Mills <wmills@yahoo-inc.com>
>&= gt; *Sent:* Monday, October 3, 2011 6:55 PM
>> *Subject:* RE: = [OAUTH-WG] Possible alternative resolution to issue 26
>> =
>> As editor, based upon James=92 input, I=92d like to expand = the set of choices for the working group to consider by adding the = possibility of using JSON string encodings for scope and = error_description where the characters used for the encoding are = restricted to the set of 7-bit ASCII characters compatible with the = HTTPbis and RFC 2617 parameter syntaxes.
>> 1.  Using RFC = 5987 encoding for the scope parameter.
>> 2.  Continuing = to specify no non-ASCII encoding for scope parameter values.
>> = 3.  Using JSON string encoding for the scope parameter.
>> = A.  Using RFC 5987 encoding for the error_description = parameter.
>> B.  Continuing to specify UTF-8 encoding for the error_description = parameter.
>> C.  Using JSON string encoding for the = error_description parameter.
>> As an individual, I=92m = sympathetic to the argument that RFC 5987 (with =93scope*=94 and = language tags etc.) is overkill for OAuth implementations, where neither = of the sets of strings is intended to be presented to end-users.  = Hence, the possible attractiveness of options 3 and C.
>> = Thoughts from others?
>>          =                     =                     =               -- Mike
>> = *From:* William Mills [mailto:wmills@yahoo-inc.com]
>>= *Sent:* Sunday, October 02, 2011 11:01 PM
>> *To:* Manger, = James H; Mike Jones; oauth@ietf.org
>> *Subject:* = Re: [OAUTH-WG] Possible alternative resolution to issue 26
>> I = don't like dropping scope from the WWW-Authenticate responses, because = my current discovery usage requires scope to be returned so that it can = be passed to the auth server if the user is forced to = re-authenticate.
>> +1 for "explicitly restrict scope values to = some subset of printable ASCII in OAuth2 Core. Not being able to support = Unicode in a new protocol is slightly disappointing, but I can live with = it."
>>
>> = ------------------------------------------------------------------------>> *From:* "Manger, James H" <James.H.Manger@team.telstr= a.com <mailto:James.H.Manger@team.telstr= a.com>>
>> *To:* Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>>; "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org <mailto:oauth@ietf.org>>
>> = *Sent:* Sunday, October 2, 2011 5:50 AM
>> *Subject:* Re: = [OAUTH-WG] Possible alternative resolution to issue 26
>> The = best solution is to drop the =93scope=94 field from the =93WWW-Authenticate: Bearer ...=94 response header. =93scope=94 is = relevant to an OAuth2-core flow, not to presenting a bearer token. = =93scope=94 could make sense in a =93WWW-Authenticate: OAuth2 ...=94 = response header as long as other necessary details such as an = authorization URI were also provided. Dropping =93scope=94 and = =93error_description=94 (as the error should be described in the = response body) would eliminate these encoding problems.
>> If = the group really wants to keep =93scope=94, I don=92t think RFC 5987 is = a good solution. RFC 5987 might have been ok for adding = internationalization support to long-standing ASCII-only fields in a = world of multiple character sets =96 but none of that applies here. = Having to change the field name from =93scope=94 to =93scope*=94 when = you have a non-ASCII value is the biggest flaw.
>> The simplest = solution is to explicitly restrict scope values to some subset of = printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly = disappointing, but I can live with it.
>> My preferred escaping = solution would be a JSON string, UTF-8 encoded: json.org <http://json.org>, RFC 4627; value in = double-quotes; slash is the escape char; supports Unicode; eg = scope=3D"coll\u00E8gues". This is backward-compatible with HTTP=92s = quoted-string syntax. It is forward-compatible with UTF-8 HTTP headers = (if that occurs). JSON is well-supported (and required for other OAuth2 = exchanges). [I might suggest json-string to the httpbis group as a = global replacement for quoted-string (or at least as a recommendation = for new fields).]
>> --
>> James Manger
>> = *From:* oauth-bounces@ietf.org = <mailto:oauth-bounces@ietf.org> = [mailto:oauth-bounces@ietf.org] = <mailto:[mailto:oauth-bounces@ietf.org]> = *On Behalf Of *Mike Jones
>> *Sent:* Friday, 30 September 2011 = 4:53 AM
>> *To:* oauth@ietf.org <mailto:oauth@ietf.org>
>> = *Subject:* [OAUTH-WG] Possible alternative resolution to issue = 26
>> There seems to now be more working group interest in = representing non-ASCII characters in scope strings than had previously = been in evidence.  If we decide to define a standard representation = for doing so, using RFC 5987 <http://tools.ietf.org/html/rfc5987> (Character = Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header = Field Parameters) seems to be the clear choice.  I=92d be = interested in knowing how many working group members are in favor of = either:
>> 1.  Using RFC 5987 encoding for the scope = parameter.
>> 2.  Continuing to specify no non-ASCII = encoding for scope parameter values.
>> As a related issue, = some working group members have objected to specifying UTF-8 encoding of = the error_description value, requesting the use of RFC 5987 encoding = instead.  I=92d also be interested in knowing how many working = group members are in favor of either:
>> A.  Using RFC = 5987 encoding for the error_description parameter.
>> B.  = Continuing to specify UTF-8 encoding for the error_description = parameter.
>> (As editor, I would make the observation that if = we choose RFC 5987 encoding for either of these parameters, it would be = logical to do so for the other one as well.)
>> In the interest = of finishing the specification in a way that meets everyone=92s = needs,
>>              =                     =                     =       -- Mike
>>
>> = _______________________________________________
>> OAuth = mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>&= gt;
>>
>>
>>
>> _______________________________________________
>> OAuth = mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>&= gt; 
>
> = _______________________________________________
> 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

<= br>

= --Apple-Mail-61-139097759-- From mscurtescu@google.com Tue Oct 4 10:58:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AA021F8DFB for ; Tue, 4 Oct 2011 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.826 X-Spam-Level: X-Spam-Status: No, score=-105.826 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ3+j26BQp9R for ; Tue, 4 Oct 2011 10:58:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E9ED121F8DE6 for ; Tue, 4 Oct 2011 10:58:19 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p94I1Mvo026544 for ; Tue, 4 Oct 2011 11:01:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317751283; bh=x7fGXMtFzbYi/NJABauwh4ulr/g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Th+eddBkzZXBbwqRiIFOD6jId48Cqr2r6+0DwkcaAy6yRTfJMDbaNLNYejd9cRtQN 3/WEEe858GKUBboI6Ebgw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=oVe8P9pe56MQ3VDlZDE8o1JlMwQBisEh0kemqq1Tl2qUeYFtR7wcAh36eeCMCi8dt REbeT9u2bRvebn5UtEg+w== Received: from yxl11 (yxl11.prod.google.com [10.190.3.203]) by hpaq14.eem.corp.google.com with ESMTP id p94Hx2ZF031368 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 11:01:21 -0700 Received: by yxl11 with SMTP id 11so906654yxl.4 for ; Tue, 04 Oct 2011 11:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cZ7ItKAYnV7pJ/ClSRBY+gZJxmXWeh56Gv8od0+02ic=; b=N9Sts7wdJM5uLMe24LzjbqSNTfspGL3LZXZVWdRWSnsr2KwhP+nb3GuqJdUqJmgXHF v79HA8yr/IdCZ+ddt7fw== Received: by 10.100.240.2 with SMTP id n2mr1286395anh.101.1317751280575; Tue, 04 Oct 2011 11:01:20 -0700 (PDT) Received: by 10.100.240.2 with SMTP id n2mr1286385anh.101.1317751280280; Tue, 04 Oct 2011 11:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.14 with HTTP; Tue, 4 Oct 2011 11:01:00 -0700 (PDT) In-Reply-To: <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> From: Marius Scurtescu Date: Tue, 4 Oct 2011 11:01:00 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=0016368e2452f6a30104ae7ce068 X-System-Of-Record: true Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 17:58:22 -0000 --0016368e2452f6a30104ae7ce068 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I just realized that scopes are defined as a space separated list of strings, for some reason I though they are a list of URIs. Mark Lentczner just clarified for me that URIs are supposed to be ASCII only. IRIs can have non-ASCII characters and can be canonically converted t= o URIs using percent encoding (back to square one). If the core spec defines scope as list of URIs then the whole issue goes away. Any reason not to do that? Marius On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt wrote: > I very much agree with you there. As I said, simple roles are best and a= re > by far the primary case. > > I'm just not so sure we should close the door. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2011-10-04, at 9:58 AM, William Mills wrote: > > I don't believe that scope is the right place to carry a more complex > grant, those would live in the token. That would more logically go in th= e > token. XML gets weird when you get to the part about space separationoan= d > order doesn't matter. Scope's current definition makes it incompatible i= n > sublte ways with using it for XML. > > ------------------------------ > *From:* Phil Hunt > *To:* "oauth@ietf.org WG" > *Sent:* Tuesday, October 4, 2011 9:47 AM > *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 > > In most cases, scope has just been a set of simple "roles" as in > "readProfile", "updateStatus", etc. > > I tend to agree scope is an internal value that SHOULD never be seen by > end-users (this should be made clear). The meaning of a scope must be > conveyed in authorization dialog, the how of which is out of scope. Sinc= e > the resource server defines how it scopes information, it should be able = to > explain the meaning of a scope request in localized language. > > I'm not against encoding the value if necessary to handle non-printable > characters. The issue I think comes back to complexity for the clients. > Would such encoding be problematic for the clients envisioned? > > Some examples I can think of: > * A URL to a specific resource > * An XML or JSON structure representing a more complex "grant" or policy > statement > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2011-10-04, at 9:01 AM, Michael Thomas wrote: > > > On 10/03/2011 09:58 PM, William Mills wrote: > >> You forgot: > >> > >> 4. Restrict the character set for scope to the point where these issu= es > all go away. > > > > Assuming that this is *completely* internal, and no end users will ever > > see either of these, this seems like the most prudent if > interoperability > > is the primary goal. The principle of least surprise, and all. > > > > But completely internal is impossible to guarantee, so I guess the > question > > is whether an incomprehensible katakana-encoded message/token is any > > worse than an incomprehensible ascii-7 english one to the poor end use= r > > who's trying to make sense of it. If it isn't then keeping things simpl= e > is > > probably safer. I assume the reason that 5987 exists is because as a > > whole, http shouldn't make any assumptions about whether users will > > see header field data. But these are individual cases here, not a > protocol-wide > > mandate. > > > > Mike > > > >> > >> ----------------------------------------------------------------------= -- > >> *From:* Mike Jones > >> *To:* "oauth@ietf.org" > >> *Cc:* "Manger, James H" ; William > Mills > >> *Sent:* Monday, October 3, 2011 6:55 PM > >> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue 26 > >> > >> As editor, based upon James=92 input, I=92d like to expand the set of > choices for the working group to consider by adding the possibility of us= ing > JSON string encodings for scope and error_description where the character= s > used for the encoding are restricted to the set of 7-bit ASCII characters > compatible with the HTTPbis and RFC 2617 parameter syntaxes. > >> 1. Using RFC 5987 encoding for the scope parameter. > >> 2. Continuing to specify no non-ASCII encoding for scope parameter > values. > >> 3. Using JSON string encoding for the scope parameter. > >> A. Using RFC 5987 encoding for the error_description parameter. > >> B. Continuing to specify UTF-8 encoding for the error_description > parameter. > >> C. Using JSON string encoding for the error_description parameter. > >> As an individual, I=92m sympathetic to the argument that RFC 5987 (wit= h > =93scope*=94 and language tags etc.) is overkill for OAuth implementation= s, > where neither of the sets of strings is intended to be presented to > end-users. Hence, the possible attractiveness of options 3 and C. > >> Thoughts from others? > >> -- Mike > >> *From:* William Mills [mailto:wmills@yahoo-inc.com] > >> *Sent:* Sunday, October 02, 2011 11:01 PM > >> *To:* Manger, James H; Mike Jones; oauth@ietf.org > >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 > >> I don't like dropping scope from the WWW-Authenticate responses, becau= se > my current discovery usage requires scope to be returned so that it can b= e > passed to the auth server if the user is forced to re-authenticate. > >> +1 for "explicitly restrict scope values to some subset of printable > ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol= is > slightly disappointing, but I can live with it." > >> > >> ----------------------------------------------------------------------= -- > >> *From:* "Manger, James H" James.H.Manger@team.telstra.com>> > >> *To:* Mike Jones Michael.Jones@microsoft.com>>; "oauth@ietf.org " < > oauth@ietf.org > > >> *Sent:* Sunday, October 2, 2011 5:50 AM > >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 > >> The best solution is to drop the =93scope=94 field from the > =93WWW-Authenticate: Bearer ...=94 response header. =93scope=94 is releva= nt to an > OAuth2-core flow, not to presenting a bearer token. =93scope=94 could mak= e sense > in a =93WWW-Authenticate: OAuth2 ...=94 response header as long as other > necessary details such as an authorization URI were also provided. Droppi= ng > =93scope=94 and =93error_description=94 (as the error should be described= in the > response body) would eliminate these encoding problems. > >> If the group really wants to keep =93scope=94, I don=92t think RFC 598= 7 is a > good solution. RFC 5987 might have been ok for adding internationalizatio= n > support to long-standing ASCII-only fields in a world of multiple charact= er > sets =96 but none of that applies here. Having to change the field name f= rom > =93scope=94 to =93scope*=94 when you have a non-ASCII value is the bigges= t flaw. > >> The simplest solution is to explicitly restrict scope values to some > subset of printable ASCII in OAuth2 Core. Not being able to support Unico= de > in a new protocol is slightly disappointing, but I can live with it. > >> My preferred escaping solution would be a JSON string, UTF-8 encoded: > json.org , RFC 4627; value in double-quotes; slash is th= e > escape char; supports Unicode; eg scope=3D"coll\u00E8gues". This is > backward-compatible with HTTP=92s quoted-string syntax. It is > forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is > well-supported (and required for other OAuth2 exchanges). [I might sugges= t > json-string to the httpbis group as a global replacement for quoted-strin= g > (or at least as a recommendation for new fields).] > >> -- > >> James Manger > >> *From:* oauth-bounces@ietf.org [mailto= : > oauth-bounces@ietf.org] *On > Behalf Of *Mike Jones > >> *Sent:* Friday, 30 September 2011 4:53 AM > >> *To:* oauth@ietf.org > >> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 > >> There seems to now be more working group interest in representing > non-ASCII characters in scope strings than had previously been in evidenc= e. > If we decide to define a standard representation for doing so, using RFC > 5987 (Character Set and Language > Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) > seems to be the clear choice. I=92d be interested in knowing how many wo= rking > group members are in favor of either: > >> 1. Using RFC 5987 encoding for the scope parameter. > >> 2. Continuing to specify no non-ASCII encoding for scope parameter > values. > >> As a related issue, some working group members have objected to > specifying UTF-8 encoding of the error_description value, requesting the = use > of RFC 5987 encoding instead. I=92d also be interested in knowing how ma= ny > working group members are in favor of either: > >> A. Using RFC 5987 encoding for the error_description parameter. > >> B. Continuing to specify UTF-8 encoding for the error_description > parameter. > >> (As editor, I would make the observation that if we choose RFC 5987 > encoding for either of these parameters, it would be logical to do so for > the other one as well.) > >> In the interest of finishing the specification in a way that meets > everyone=92s needs, > >> -- Mike > >> > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016368e2452f6a30104ae7ce068 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I just realized that scopes are defined as a space separated list of string= s, for some reason I though they are a list of URIs.

Mar= k Lentczner just clarified for me that=A0URIs are supposed to be ASCII only= . IRIs can have non-ASCII characters and can be canonically converted to UR= Is using percent encoding (back to square one).

If the core spec defines scope as list of URIs then the= whole issue goes away. Any reason not to do that?

Marius


On Tue, Oct 4, 2011 at 10:18 AM, Phil Hu= nt <phil.hunt@= oracle.com> wrote:
I very much agree with you there. =A0As= I said, simple roles are best and are by far the primary case.

I'm just not so sure we should close the door.

Phil

On 2011-10-04, at 9:58 AM, William Mills wrote:

I don't believe that scope is the right place to carry a mor= e complex grant, those would live in the token.=A0 That would more logicall= y go in the token.=A0 XML gets weird when you get to the part about space s= eparationoand order doesn't matter.=A0 Scope's current definition m= akes it incompatible in sublte ways with using it for XML.

From: Phil Hunt <phil.hunt@oracle.com= >
To: "oauth@ietf.org WG" <<= a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org> Sent: Tuesday, October 4, 20= 11 9:47 AM
Subject: Re: [= OAUTH-WG] Possible alternative resolution to issue 26

In most cases, scope has just been a set of simple "roles" as in = "readProfile", "updateStatus", etc.

I tend to ag= ree scope is an internal value that SHOULD never be seen by end-users (this= should be made clear). The meaning of a scope must be conveyed in authoriz= ation dialog, the how of which is out of scope.=A0 Since the resource serve= r defines how it scopes information, it should be able to explain the meani= ng of a scope request in localized language.

I'm not against encoding the value if necessary to handle non-print= able characters. The issue I think comes back to complexity for the clients= . Would such encoding be problematic for the clients envisioned?

Some examples I can think of:
* A URL to a specific resource
* An XML= or JSON structure representing a more complex "grant" or policy = statement

Phil

@independentid
www.independentid.com
phil.hunt@oracle.= com





On 2011-10-04, at 9:01 AM, Michael Thomas wr= ote:

> On 10/03/2011 09:58 PM, William Mills wrote:
>> Y= ou forgot:
>>
>> 4.=A0 Restrict the character set for scope to the poi= nt where these issues all go away.
>
> Assuming that this is *= completely* internal, and no end users will ever
> see either of thes= e,=A0 this seems like the most prudent if interoperability
> is the primary goal. The principle of least surprise, and all.
>=
> But completely internal is impossible to guarantee, so I guess th= e question
> is whether an incomprehensible katakana-encoded message/= token is any
> worse than=A0 an incomprehensible ascii-7 english one to the poor end = user
> who's trying to make sense of it. If it isn't then kee= ping things simple is
> probably safer. I assume the reason that 5987 exists is because as a
&g= t; whole, http shouldn't make any assumptions about whether users will<= br>> see header field data. But these are individual cases here, not a p= rotocol-wide
> mandate.
>
> Mike
>
>>
>> -----= -------------------------------------------------------------------
>= > *From:* Mike Jones <Michael.Jones@microsoft.com>
>> *To:* "oa= uth@ietf.org" <oauth@ietf.org>
>> *Cc:* "Manger, James H" &l= t;Jame= s.H.Manger@team.telstra.com>; William Mills <wmills@yahoo-inc.com>
>> *Sent:* Monday, October 3, 2011 6:55 PM
>> *Subject:* RE:= [OAUTH-WG] Possible alternative resolution to issue 26
>>
>= ;> As editor, based upon James=92 input, I=92d like to expand the set of= choices for the working group to consider by adding the possibility of usi= ng JSON string encodings for scope and error_description where the characte= rs used for the encoding are restricted to the set of 7-bit ASCII character= s compatible with the HTTPbis and RFC 2617 parameter syntaxes.
>> 1.=A0 Using RFC 5987 encoding for the scope parameter.
>>= 2.=A0 Continuing to specify no non-ASCII encoding for scope parameter valu= es.
>> 3.=A0 Using JSON string encoding for the scope parameter. >> A.=A0 Using RFC 5987 encoding for the error_description parameter.=
>> B.=A0 Continuing to specify UTF-8 encoding for the error_description parameter.
>>= C.=A0 Using JSON string encoding for the error_description parameter.
&= gt;> As an individual, I=92m sympathetic to the argument that RFC 5987 (= with =93scope*=94 and language tags etc.) is overkill for OAuth implementat= ions, where neither of the sets of strings is intended to be presented to e= nd-users.=A0 Hence, the possible attractiveness of options 3 and C.
>> Thoughts from others?
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 -- Mike
>> *From:* William Mills [mailto:wmills@yahoo-inc.com<= /a>]
>> *Sent:* Sunday, October 02, 2011 11:01 PM
>> *To:* Manger= , James H; Mike Jones; oauth@ietf.org<= /a>
>> *Subject:* Re: [OAUTH-WG] Possible alternative resolution t= o issue 26
>> I don't like dropping scope from the WWW-Authent= icate responses, because my current discovery usage requires scope to be re= turned so that it can be passed to the auth server if the user is forced to= re-authenticate.
>> +1 for "explicitly restrict scope values to some subset of pr= intable ASCII in OAuth2 Core. Not being able to support Unicode in a new pr= otocol is slightly disappointing, but I can live with it."
>>=
>> ------------------------------------------------------------------= ------
>> *From:* "Manger, James H" <James.H.Manger@team.te= lstra.com <mailto:James.H.Manger@team.telstra.com>>
>> *To:* Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsof= t.com>>; "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org <mailto:oauth@ietf.org>>
>> *Sent:* Sunday, October 2, 2011 5:50 AM
>> *Subject:* Re:= [OAUTH-WG] Possible alternative resolution to issue 26
>> The bes= t solution is to drop the =93scope=94 field from the =93WWW-Authenticate: Bearer ...=94 response header. =93scope=94 is relevan= t to an OAuth2-core flow, not to presenting a bearer token. =93scope=94 cou= ld make sense in a =93WWW-Authenticate: OAuth2 ...=94 response header as lo= ng as other necessary details such as an authorization URI were also provid= ed. Dropping =93scope=94 and =93error_description=94 (as the error should b= e described in the response body) would eliminate these encoding problems.<= br> >> If the group really wants to keep =93scope=94, I don=92t think RFC= 5987 is a good solution. RFC 5987 might have been ok for adding internatio= nalization support to long-standing ASCII-only fields in a world of multipl= e character sets =96 but none of that applies here. Having to change the fi= eld name from =93scope=94 to =93scope*=94 when you have a non-ASCII value i= s the biggest flaw.
>> The simplest solution is to explicitly restrict scope values to so= me subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disa= ppointing, but I can live with it.
>> My preferred escaping soluti= on would be a JSON string, UTF-8 encoded: json.org <http://json.org>, RFC 4627; value in double-quotes; slash is the e= scape char; supports Unicode; eg scope=3D"coll\u00E8gues". This i= s backward-compatible with HTTP=92s quoted-string syntax. It is forward-com= patible with UTF-8 HTTP headers (if that occurs). JSON is well-supported (a= nd required for other OAuth2 exchanges). [I might suggest json-string to th= e httpbis group as a global replacement for quoted-string (or at least as a= recommendation for new fields).]
>> --
>> James Manger
>> *From:* oauth-bounces@ietf.org <ma= ilto:oauth-boun= ces@ietf.org> [mailto:oauth-bounces@ietf.org] <mailto:[mailto:oauth-bounces@ietf.org]&g= t; *On Behalf Of *Mike Jones
>> *Sent:* Friday, 30 September 2011 4:53 AM
>> *To:* oauth@ietf.org <mailto= :oauth@ietf.org>=
>> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26<= br>>> There seems to now be more working group interest in representi= ng non-ASCII characters in scope strings than had previously been in eviden= ce.=A0 If we decide to define a standard representation for doing so, using= RFC 5987 <http://tools.ietf.org/html/rfc5987> (Character Set and Language = Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) se= ems to be the clear choice.=A0 I=92d be interested in knowing how many work= ing group members are in favor of either:
>> 1.=A0 Using RFC 5987 encoding for the scope parameter.
>>= 2.=A0 Continuing to specify no non-ASCII encoding for scope parameter valu= es.
>> As a related issue, some working group members have objecte= d to specifying UTF-8 encoding of the error_description value, requesting t= he use of RFC 5987 encoding instead.=A0 I=92d also be interested in knowing= how many working group members are in favor of either:
>> A.=A0 Using RFC 5987 encoding for the error_description parameter.=
>> B.=A0 Continuing to specify UTF-8 encoding for the error_descr= iption parameter.
>> (As editor, I would make the observation that= if we choose RFC 5987 encoding for either of these parameters, it would be logic= al to do so for the other one as well.)
>> In the interest of fini= shing the specification in a way that meets everyone=92s needs,
>>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>>
>> _______________________________________________
&g= t;> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>= ;>
>>
>>
>> _______________________________________________
>> OAuth mailing = list
>> OAuth@= ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=A0
>
> ____________________________________________= ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/list= info/oauth

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




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--0016368e2452f6a30104ae7ce068-- From Michael.Jones@microsoft.com Tue Oct 4 11:04:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADB021F8CDB for ; Tue, 4 Oct 2011 11:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQnP5WVMPcwF for ; Tue, 4 Oct 2011 11:04:02 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 471DD21F8C89 for ; Tue, 4 Oct 2011 11:04:02 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 4 Oct 2011 11:07:07 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Tue, 4 Oct 2011 11:07:07 -0700 From: Mike Jones To: Marius Scurtescu , Phil Hunt Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gCGXHeAADaHZIAAGpwHEAAVgBWAABcn+4AAAZ5AgAAAWuaAAAC2sIAAAXuIAAAOfxNw Date: Tue, 4 Oct 2011 18:07:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C2276BDTK5EX14MBXC284r_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:04:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C2276BDTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Existing practice is that simple ASCII strings like "email" "profile", "ope= nid", etc. are used as scope elements. Requiring them to be URIs would bre= ak most existing practice. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= arius Scurtescu Sent: Tuesday, October 04, 2011 11:01 AM To: Phil Hunt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 I just realized that scopes are defined as a space separated list of string= s, for some reason I though they are a list of URIs. Mark Lentczner just clarified for me that URIs are supposed to be ASCII onl= y. IRIs can have non-ASCII characters and can be canonically converted to U= RIs using percent encoding (back to square one). If the core spec defines scope as list of URIs then the whole issue goes aw= ay. Any reason not to do that? Marius On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt > wrote: I very much agree with you there. As I said, simple roles are best and are= by far the primary case. I'm just not so sure we should close the door. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-10-04, at 9:58 AM, William Mills wrote: I don't believe that scope is the right place to carry a more complex grant= , those would live in the token. That would more logically go in the token= . XML gets weird when you get to the part about space separationoand order= doesn't matter. Scope's current definition makes it incompatible in sublt= e ways with using it for XML. ________________________________ From: Phil Hunt > To: "oauth@ietf.org WG" > Sent: Tuesday, October 4, 2011 9:47 AM Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 In most cases, scope has just been a set of simple "roles" as in "readProfi= le", "updateStatus", etc. I tend to agree scope is an internal value that SHOULD never be seen by end= -users (this should be made clear). The meaning of a scope must be conveyed= in authorization dialog, the how of which is out of scope. Since the reso= urce server defines how it scopes information, it should be able to explain= the meaning of a scope request in localized language. I'm not against encoding the value if necessary to handle non-printable cha= racters. The issue I think comes back to complexity for the clients. Would = such encoding be problematic for the clients envisioned? Some examples I can think of: * A URL to a specific resource * An XML or JSON structure representing a more complex "grant" or policy st= atement Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-10-04, at 9:01 AM, Michael Thomas wrote: > On 10/03/2011 09:58 PM, William Mills wrote: >> You forgot: >> >> 4. Restrict the character set for scope to the point where these issues= all go away. > > Assuming that this is *completely* internal, and no end users will ever > see either of these, this seems like the most prudent if interoperabilit= y > is the primary goal. The principle of least surprise, and all. > > But completely internal is impossible to guarantee, so I guess the questi= on > is whether an incomprehensible katakana-encoded message/token is any > worse than an incomprehensible ascii-7 english one to the poor end user > who's trying to make sense of it. If it isn't then keeping things simple = is > probably safer. I assume the reason that 5987 exists is because as a > whole, http shouldn't make any assumptions about whether users will > see header field data. But these are individual cases here, not a protoco= l-wide > mandate. > > Mike > >> >> ------------------------------------------------------------------------ >> *From:* Mike Jones > >> *To:* "oauth@ietf.org" > >> *Cc:* "Manger, James H" >; William Mills > >> *Sent:* Monday, October 3, 2011 6:55 PM >> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue 26 >> >> As editor, based upon James' input, I'd like to expand the set of choice= s for the working group to consider by adding the possibility of using JSON= string encodings for scope and error_description where the characters used= for the encoding are restricted to the set of 7-bit ASCII characters compa= tible with the HTTPbis and RFC 2617 parameter syntaxes. >> 1. Using RFC 5987 encoding for the scope parameter. >> 2. Continuing to specify no non-ASCII encoding for scope parameter valu= es. >> 3. Using JSON string encoding for the scope parameter. >> A. Using RFC 5987 encoding for the error_description parameter. >> B. Continuing to specify UTF-8 encoding for the error_description param= eter. >> C. Using JSON string encoding for the error_description parameter. >> As an individual, I'm sympathetic to the argument that RFC 5987 (with "s= cope*" and language tags etc.) is overkill for OAuth implementations, where= neither of the sets of strings is intended to be presented to end-users. = Hence, the possible attractiveness of options 3 and C. >> Thoughts from others? >> -- Mike >> *From:* William Mills [mailto:wmills@yahoo-inc.com] >> *Sent:* Sunday, October 02, 2011 11:01 PM >> *To:* Manger, James H; Mike Jones; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 >> I don't like dropping scope from the WWW-Authenticate responses, because= my current discovery usage requires scope to be returned so that it can be= passed to the auth server if the user is forced to re-authenticate. >> +1 for "explicitly restrict scope values to some subset of printable ASC= II in OAuth2 Core. Not being able to support Unicode in a new protocol is s= lightly disappointing, but I can live with it." >> >> ------------------------------------------------------------------------ >> *From:* "Manger, James H" >> >> *To:* Mike Jones >>; "oauth@ietf.org >" >> >> *Sent:* Sunday, October 2, 2011 5:50 AM >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 >> The best solution is to drop the "scope" field from the "WWW-Authenticat= e: Bearer ..." response header. "scope" is relevant to an OAuth2-core flow,= not to presenting a bearer token. "scope" could make sense in a "WWW-Authe= nticate: OAuth2 ..." response header as long as other necessary details suc= h as an authorization URI were also provided. Dropping "scope" and "error_d= escription" (as the error should be described in the response body) would e= liminate these encoding problems. >> If the group really wants to keep "scope", I don't think RFC 5987 is a g= ood solution. RFC 5987 might have been ok for adding internationalization s= upport to long-standing ASCII-only fields in a world of multiple character = sets - but none of that applies here. Having to change the field name from = "scope" to "scope*" when you have a non-ASCII value is the biggest flaw. >> The simplest solution is to explicitly restrict scope values to some sub= set of printable ASCII in OAuth2 Core. Not being able to support Unicode in= a new protocol is slightly disappointing, but I can live with it. >> My preferred escaping solution would be a JSON string, UTF-8 encoded: js= on.org >, RFC 4627; valu= e in double-quotes; slash is the escape char; supports Unicode; eg scope=3D= "coll\u00E8gues". This is backward-compatible with HTTP's quoted-string syn= tax. It is forward-compatible with UTF-8 HTTP headers (if that occurs). JSO= N is well-supported (and required for other OAuth2 exchanges). [I might sug= gest json-string to the httpbis group as a global replacement for quoted-st= ring (or at least as a recommendation for new fields).] >> -- >> James Manger >> *From:* oauth-bounces@ietf.org > [mailto:oauth-bounces@= ietf.org] ]> *On Behalf Of *Mike Jones >> *Sent:* Friday, 30 September 2011 4:53 AM >> *To:* oauth@ietf.org > >> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 >> There seems to now be more working group interest in representing non-AS= CII characters in scope strings than had previously been in evidence. If w= e decide to define a standard representation for doing so, using RFC 5987 <= http://tools.ietf.org/html/rfc5987> (Character Set and Language Encoding fo= r Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be t= he clear choice. I'd be interested in knowing how many working group membe= rs are in favor of either: >> 1. Using RFC 5987 encoding for the scope parameter. >> 2. Continuing to specify no non-ASCII encoding for scope parameter valu= es. >> As a related issue, some working group members have objected to specifyi= ng UTF-8 encoding of the error_description value, requesting the use of RFC= 5987 encoding instead. I'd also be interested in knowing how many working= group members are in favor of either: >> A. Using RFC 5987 encoding for the error_description parameter. >> B. Continuing to specify UTF-8 encoding for the error_description param= eter. >> (As editor, I would make the observation that if we choose RFC 5987 enco= ding for either of these parameters, it would be logical to do so for the o= ther one as well.) >> In the interest of finishing the specification in a way that meets every= one's needs, >> -- Mike >> >> _______________________________________________ >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435C2276BDTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Existing practice is that= simple ASCII strings like “email” “profile”, ̶= 0;openid”, etc. are used as scope elements.  Requiring them to b= e URIs would break most existing practice.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu
Sent: Tuesday, October 04, 2011 11:01 AM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= o:p>

 

I just realized that scopes are defined as a space s= eparated list of strings, for some reason I though they are a list of URIs.=

 

Mark Lentczner just clarified for me that URIs = are supposed to be ASCII only. IRIs can have non-ASCII characters and can b= e canonically converted to URIs using percent encoding (back to square one)= .

 

If the core spec defines scope as list of URIs then = the whole issue goes away. Any reason not to do that?

 

Marius

On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt <phil.hunt@oracle.com> wrote:=

I very much agree with you there.  As I said, s= imple roles are best and are by far the primary case.

 

I'm just not so sure we should close the door.<= /o:p>

 

Phil

 

@independentid<= /span>

phil.hunt@o= racle.com

 <= /p>

 

 

On 2011-10-04, at 9:58 AM, William Mills wrote:=



I don't believe that scope is the ri= ght place to carry a more complex grant, those would live in the token.&nbs= p; That would more logically go in the token.  XML gets weird when you get to the part about space separationoand order doesn't ma= tter.  Scope's current definition makes it incompatible in sublte ways= with using it for XML.

 

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: Phil Hunt <= ;phil.hunt@oracle= .com>
To: "oauth@= ietf.org WG" <oauth@ietf.org>
Sent: Tuesday, October 4, 2011 9:47 AM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= br>
In most cases, scope has just been a set of simple "roles" as in = "readProfile", "updateStatus", etc.

I tend to agree scope is an internal value that SHOULD never be seen by end= -users (this should be made clear). The meaning of a scope must be conveyed= in authorization dialog, the how of which is out of scope.  Since the= resource server defines how it scopes information, it should be able to explain the meaning of a scope request i= n localized language.

I'm not against encoding the value if necessary to handle non-printable cha= racters. The issue I think comes back to complexity for the clients. Would = such encoding be problematic for the clients envisioned?

Some examples I can think of:
* A URL to a specific resource
* An XML or JSON structure representing a more complex "grant" or= policy statement

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com





On 2011-10-04, at 9:01 AM, Michael Thomas wrote:

> On 10/03/2011 09:58 PM, William Mills wrote:
>> You forgot:
>>
>> 4.  Restrict the character set for scope to the point where t= hese issues all go away.
>
> Assuming that this is *completely* internal, and no end users will eve= r
> see either of these,  this seems like the most prudent if interop= erability
> is the primary goal. The principle of least surprise, and all.
>
> But completely internal is impossible to guarantee, so I guess the que= stion
> is whether an incomprehensible katakana-encoded message/token is any > worse than  an incomprehensible ascii-7 english one to the poor e= nd user
> who's trying to make sense of it. If it isn't then keeping things simp= le is
> probably safer. I assume the reason that 5987 exists is because as a > whole, http shouldn't make any assumptions about whether users will > see header field data. But these are individual cases here, not a prot= ocol-wide
> mandate.
>
> Mike
>
>>
>> ------------------------------------------------------------------= ------
>> *From:* Mike Jones <Michael.Jones@microsoft.com>
>> *To:* "oa= uth@ietf.org" <oauth@ietf.org>
>> *Cc:* "Manger, James H" <James.H.Manger@team.telstra.com>; William Mills <wmills@yahoo-inc.com>
>> *Sent:* Monday, October 3, 2011 6:55 PM
>> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue= 26
>>
>> As editor, based upon James’ input, I’d like to expand= the set of choices for the working group to consider by adding the possibi= lity of using JSON string encodings for scope and error_description where t= he characters used for the encoding are restricted to the set of 7-bit ASCII characters compatible with the HTTPbis and RFC 2= 617 parameter syntaxes.
>> 1.  Using RFC 5987 encoding for the scope parameter.
>> 2.  Continuing to specify no non-ASCII encoding for scope par= ameter values.
>> 3.  Using JSON string encoding for the scope parameter.
>> A.  Using RFC 5987 encoding for the error_description paramet= er.
>> B.  Continuing to specify UTF-8 encoding for the error_descri= ption parameter.
>> C.  Using JSON string encoding for the error_description para= meter.
>> As an individual, I’m sympathetic to the argument that RFC 5= 987 (with “scope*” and language tags etc.) is overkill for OAut= h implementations, where neither of the sets of strings is intended to be p= resented to end-users.  Hence, the possible attractiveness of options 3 and C.
>> Thoughts from others?
>>                  &nbs= p;                     &n= bsp;                     =   -- Mike
>> *From:* William Mills [mailto:wmills@yahoo-inc.com]
>> *Sent:* Sunday, October 02, 2011 11:01 PM
>> *To:* Manger, James H; Mike Jones; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue= 26
>> I don't like dropping scope from the WWW-Authenticate responses, b= ecause my current discovery usage requires scope to be returned so that it = can be passed to the auth server if the user is forced to re-authenticate.<= br> >> +1 for "explicitly restrict scope values to some subset o= f printable ASCII in OAuth2 Core. Not being able to support Unicode in a ne= w protocol is slightly disappointing, but I can live with it."
>>
>> ------------------------------------------------------------------= ------
>> *From:* "Manger, James H" <James.H.Manger@team.telstra.com<= /a> <mailto:James.H.Manger@team.telstra.com>>
>> *To:* Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsof= t.com>>; "oauth@ietf.org <mailto:oauth@ietf.= org>" <o= auth@ietf.org <mailto:oauth@ietf.org>>
>> *Sent:* Sunday, October 2, 2011 5:50 AM
>> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue= 26
>> The best solution is to drop the “scope” field from th= e “WWW-Authenticate: Bearer ...” response header. “scope&= #8221; is relevant to an OAuth2-core flow, not to presenting a bearer token= . “scope” could make sense in a “WWW-Authenticate: OAuth2= ...” response header as long as other necessary details such as an authorization URI were also = provided. Dropping “scope” and “error_description” = (as the error should be described in the response body) would eliminate the= se encoding problems.
>> If the group really wants to keep “scope”, I don’= ;t think RFC 5987 is a good solution. RFC 5987 might have been ok for addin= g internationalization support to long-standing ASCII-only fields in a worl= d of multiple character sets – but none of that applies here. Having to change the field name from “scope” to “s= cope*” when you have a non-ASCII value is the biggest flaw.
>> The simplest solution is to explicitly restrict scope values to so= me subset of printable ASCII in OAuth2 Core. Not being able to support Unic= ode in a new protocol is slightly disappointing, but I can live with it. >> My preferred escaping solution would be a JSON string, UTF-8 encod= ed: json.org <http://json= .org>, RFC 4627; value in double-quotes; slash is the escape char; s= upports Unicode; eg scope=3D"coll\u00E8gues". This is backward-co= mpatible with HTTP’s quoted-string syntax. It is forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is well-supported (and requ= ired for other OAuth2 exchanges). [I might suggest json-string to the httpb= is group as a global replacement for quoted-string (or at least as a recomm= endation for new fields).]
>> --
>> James Manger
>> *From:* oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org= ] <mailto:[mailto:oauth-bounces@ietf.org]> *On Behalf Of *Mike Jones
>> *Sent:* Friday, 30 September 2011 4:53 AM
>> *To:* oauth@ie= tf.org <mailto:o= auth@ietf.org>
>> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26<= br> >> There seems to now be more working group interest in representing = non-ASCII characters in scope strings than had previously been in evidence.=   If we decide to define a standard representation for doing so, using= RFC 5987 <http://tools.ietf.org/html/rfc5987> (Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP= ) Header Field Parameters) seems to be the clear choice.  I’d be= interested in knowing how many working group members are in favor of eithe= r:
>> 1.  Using RFC 5987 encoding for the scope parameter.
>> 2.  Continuing to specify no non-ASCII encoding for scope par= ameter values.
>> As a related issue, some working group members have objected to sp= ecifying UTF-8 encoding of the error_description value, requesting the use = of RFC 5987 encoding instead.  I’d also be interested in knowing= how many working group members are in favor of either:
>> A.  Using RFC 5987 encoding for the error_description paramet= er.
>> B.  Continuing to specify UTF-8 encoding for the error_descri= ption parameter.
>> (As editor, I would make the observation that if we choose RFC 598= 7 encoding for either of these parameters, it would be logical to do so for= the other one as well.)
>> In the interest of finishing the specification in a way that meets= everyone’s needs,
>>                  &nbs= p;                     &n= bsp;                   -- Mike=
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org= <mailto:OAuth@i= etf.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
h= ttps://www.ietf.org/mailman/listinfo/oauth

 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B16804296739435C2276BDTK5EX14MBXC284r_-- From andredemarre@gmail.com Tue Oct 4 11:29:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0331721F8DD7 for ; Tue, 4 Oct 2011 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QfSWMWFdxyb for ; Tue, 4 Oct 2011 11:29:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 03F3021F8D16 for ; Tue, 4 Oct 2011 11:29:37 -0700 (PDT) Received: by iaby26 with SMTP id y26so1096697iab.31 for ; Tue, 04 Oct 2011 11:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ySvq5qVswWZ7XgdcWXWcdhlfmrKxFwjaggvsXKuu0ZE=; b=Taq4zCWwoEYj9OyDInb0bu859pafJcXULxwCV9IIWnIjYsxWIBNfR4Xkxq5IgLy3+n pgeNsc5jkyDfCHKE8PdZscbbWQoBovj/Q6ASAVrOYFYQ7wrt/P4QBmyTKXXQ0l62znL1 i2KtFuoYDZRVjxW1nbklcpRhyrjiVWD3XOdMQ= MIME-Version: 1.0 Received: by 10.42.73.193 with SMTP id t1mr2298899icj.188.1317753163674; Tue, 04 Oct 2011 11:32:43 -0700 (PDT) Received: by 10.42.18.129 with HTTP; Tue, 4 Oct 2011 11:32:43 -0700 (PDT) Date: Tue, 4 Oct 2011 11:32:43 -0700 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Phishing with Client Application Name Spoofing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:29:39 -0000 I've not seen this particular variant of phishing and client impersonation discussed. A cursory search revealed that most of the related discussion centers around either (a) client impersonation with stolen client credentials or (b) phishing by malicious clients directing resource owners to spoofed authorization servers. This is different. This attack exploits the trust a resource owner has for an OAuth authorization server so as to lend repute to a malicious client pretending to be from a trustworthy source. This is not necessarily a direct vulnerability of OAuth; rather, it shows that authorization servers have a responsibility regarding client application names and how they present resource owners with the option to allow or deny authorization. A key to this exploit is the process of client registration with the authorization server. A malicious client developer registers his client application with a name that appears to represent a legitimate organization which resource owners are likely to trust. Resource owners at the authorization endpoint may be misled into granting authorization when they see the authorization server asserting " is requesting permission to..." Imagine someone registers a client application with an OAuth service, let's call it Foobar, and he names his client app "Google, Inc.". The Foobar authorization server will engage the user with "Google, Inc. is requesting permission to do the following." The resource owner might reason, "I see that I'm legitimately on the https://www.foobar.com site, and Foobar is telling me that Google wants permission. I trust Foobar and Google, so I'll click Allow." To make the masquerade act even more convincing, many of the most popular OAuth services allow app developers to upload images which could be official logos of the organizations they are posing as. Often app developers can supply arbitrary, unconfirmed URIs which are shown to the resource owner as the app's website, even if the domain does not match the redirect URI. Some OAuth services blindly entrust client apps to customize the authorization page in other ways. This is hard to defend against. Authorization server administrators could police client names, but that approach gives them a burden similar to certificate authorities to verify organizations before issuing certificates. Very expensive. A much simpler solution is for authorization servers to be careful with their wording and educate resource owners about the need for discretion when granting authority. Foobar's message above could be changed: "An application calling itself Google, Inc. is requesting permission to do the following" later adding, "Only allow this request if you are sure of the application's source." Such wording is less likely to give the impression that the resource server is vouching for the application's identity. Authorization servers would also do well to show the resource owner additional information about the client application to help them make informed decisions. For example, it could display all or part of the app's redirect URI, saying, "The application is operating on example.com" or "If you decide to allow this application, your browser will be directed to http://www.example.com/." Further, if the client app's redirect URI uses TLS (something authorization servers might choose to mandate), then auth servers can verify the certificate and show the certified organization name to resource owners. This attack is possible with OAuth 1, but OAuth 2 makes successful exploitation easier. OAuth 1 required the client to obtain temporary credentials (aka access tokens) before sending resource owners to the authorization endpoint. Now with OAuth 2, this attack does not require resource owners to interact with the client application before visiting the authorization server. The malicious client developer only needs to distribute links around the web to the authorization server's authorization endpoint. If the HTTP service is a social platform, the client app might distribute links using resource owners' accounts with the access tokens it has acquired, becoming a sort of worm. Continuing the Google/Foobar example above, it might use anchor text such as "I used Google Plus to synchronize with my Foobar account." Moreover, if the app's redirect URI bounces the resource owner back to the HTTP service after acquiring an authorization code, the victim will never see a page rendered at the insidious app's domain. This is especially dangerous because the public is not trained to defend against it. Savvy users are (arguably) getting better at protecting themselves from traditional phishing by verifying the domain in the address bar, and perhaps checking TLS certificates, but such defenses are irrelevent here. Resource owners now need to verify not only that they are on the legitimate authorization server, but to consider the trustworthyness of the link that referred them there. I'm not sure what can or should be done, but I think it's important for authorization server implementers to be aware of this attack. If administrators are not able to authenticate client organizations, then they are shifting this burden to resource owners. They should do all they can to educate resource owners and help them make informed decisions before granting authorization. Regards, Andre DeMarre From mscurtescu@google.com Tue Oct 4 11:36:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44BB21F8E0B for ; Tue, 4 Oct 2011 11:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.119 X-Spam-Level: X-Spam-Status: No, score=-106.119 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1uExJmNYdRJ for ; Tue, 4 Oct 2011 11:36:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 328C121F8E01 for ; Tue, 4 Oct 2011 11:36:11 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p94IdGLc028250 for ; Tue, 4 Oct 2011 11:39:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317753556; bh=lY6kqql/34ixrQEE8DWQK0HyZbg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CdhCjTKrP4PxNBe0PFVLMewlQzGOzppQcgDfdclUTaVn15lDdf4R3LRkei/VrG33O 9MBa8WNUwR69b8T4opMrw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=cCU6zSveJvLAOUVH/QvDoHs4BhTJDVVJ8TtPF2G6fvEfhRRxSfeg6tpM0LJ2VCYAg ZL5g2F1aiJZgBeUGfMPKg== Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by hpaq7.eem.corp.google.com with ESMTP id p94IcMHr027388 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 11:39:15 -0700 Received: by yxt3 with SMTP id 3so1513190yxt.30 for ; Tue, 04 Oct 2011 11:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A6AbeEGbMtZb47ZB72sUhOwHMa9bnxWYPPK0jnwqyEQ=; b=lAlv4c8kYhkFrBwF5iOPn2qzpC/sA4wytl6CtzdcUNTiBYY1OgE/LFziF01Gi3s7pA AYj899Rvvjh08UYun9lQ== Received: by 10.100.233.33 with SMTP id f33mr1317666anh.123.1317753550410; Tue, 04 Oct 2011 11:39:10 -0700 (PDT) Received: by 10.100.233.33 with SMTP id f33mr1317651anh.123.1317753549975; Tue, 04 Oct 2011 11:39:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.14 with HTTP; Tue, 4 Oct 2011 11:38:48 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Tue, 4 Oct 2011 11:38:48 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001636ed62ee3f739704ae7d68aa X-System-Of-Record: true Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:36:13 -0000 --001636ed62ee3f739704ae7d68aa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones wr= ote: > Existing practice is that simple ASCII strings like =93email=94 =93profi= le=94, > =93openid=94, etc. are used as scope elements. Requiring them to be URIs= would > break most existing practice. > Aren't these simple strings URIs? I think they are parsed as a URI with no scheme and authority only a path. Marius > **** > > ** ** > > -- Mike**** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Marius Scurtescu > *Sent:* Tuesday, October 04, 2011 11:01 AM > *To:* Phil Hunt > *Cc:* oauth@ietf.org WG > > *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26**** > > ** ** > > I just realized that scopes are defined as a space separated list of > strings, for some reason I though they are a list of URIs.**** > > ** ** > > Mark Lentczner just clarified for me that URIs are supposed to be ASCII > only. IRIs can have non-ASCII characters and can be canonically converted= to > URIs using percent encoding (back to square one).**** > > ** ** > > If the core spec defines scope as list of URIs then the whole issue goes > away. Any reason not to do that?**** > > ** ** > > Marius > > **** > > On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt wrote:*= * > ** > > I very much agree with you there. As I said, simple roles are best and a= re > by far the primary case.**** > > ** ** > > I'm just not so sure we should close the door.**** > > ** ** > > Phil**** > > ** ** > > @independentid**** > > www.independentid.com**** > > phil.hunt@oracle.com**** > > ** ** > > ** ** > > ** ** > > On 2011-10-04, at 9:58 AM, William Mills wrote:**** > > > > **** > > I don't believe that scope is the right place to carry a more complex > grant, those would live in the token. That would more logically go in th= e > token. XML gets weird when you get to the part about space separationoan= d > order doesn't matter. Scope's current definition makes it incompatible i= n > sublte ways with using it for XML.**** > > ** ** > ------------------------------ > > *From:* Phil Hunt > *To:* "oauth@ietf.org WG" > *Sent:* Tuesday, October 4, 2011 9:47 AM > *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 > > In most cases, scope has just been a set of simple "roles" as in > "readProfile", "updateStatus", etc. > > I tend to agree scope is an internal value that SHOULD never be seen by > end-users (this should be made clear). The meaning of a scope must be > conveyed in authorization dialog, the how of which is out of scope. Sinc= e > the resource server defines how it scopes information, it should be able = to > explain the meaning of a scope request in localized language. > > I'm not against encoding the value if necessary to handle non-printable > characters. The issue I think comes back to complexity for the clients. > Would such encoding be problematic for the clients envisioned? > > Some examples I can think of: > * A URL to a specific resource > * An XML or JSON structure representing a more complex "grant" or policy > statement > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2011-10-04, at 9:01 AM, Michael Thomas wrote: > > > On 10/03/2011 09:58 PM, William Mills wrote: > >> You forgot: > >> > >> 4. Restrict the character set for scope to the point where these issu= es > all go away. > > > > Assuming that this is *completely* internal, and no end users will ever > > see either of these, this seems like the most prudent if > interoperability > > is the primary goal. The principle of least surprise, and all. > > > > But completely internal is impossible to guarantee, so I guess the > question > > is whether an incomprehensible katakana-encoded message/token is any > > worse than an incomprehensible ascii-7 english one to the poor end use= r > > who's trying to make sense of it. If it isn't then keeping things simpl= e > is > > probably safer. I assume the reason that 5987 exists is because as a > > whole, http shouldn't make any assumptions about whether users will > > see header field data. But these are individual cases here, not a > protocol-wide > > mandate. > > > > Mike > > > >> > >> ----------------------------------------------------------------------= -- > >> *From:* Mike Jones > >> *To:* "oauth@ietf.org" > >> *Cc:* "Manger, James H" ; William > Mills > >> *Sent:* Monday, October 3, 2011 6:55 PM > >> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue 26 > >> > >> As editor, based upon James=92 input, I=92d like to expand the set of > choices for the working group to consider by adding the possibility of us= ing > JSON string encodings for scope and error_description where the character= s > used for the encoding are restricted to the set of 7-bit ASCII characters > compatible with the HTTPbis and RFC 2617 parameter syntaxes. > >> 1. Using RFC 5987 encoding for the scope parameter. > >> 2. Continuing to specify no non-ASCII encoding for scope parameter > values. > >> 3. Using JSON string encoding for the scope parameter. > >> A. Using RFC 5987 encoding for the error_description parameter. > >> B. Continuing to specify UTF-8 encoding for the error_description > parameter. > >> C. Using JSON string encoding for the error_description parameter. > >> As an individual, I=92m sympathetic to the argument that RFC 5987 (wit= h > =93scope*=94 and language tags etc.) is overkill for OAuth implementation= s, > where neither of the sets of strings is intended to be presented to > end-users. Hence, the possible attractiveness of options 3 and C. > >> Thoughts from others? > >> -- Mike > >> *From:* William Mills [mailto:wmills@yahoo-inc.com] > >> *Sent:* Sunday, October 02, 2011 11:01 PM > >> *To:* Manger, James H; Mike Jones; oauth@ietf.org > >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 > >> I don't like dropping scope from the WWW-Authenticate responses, becau= se > my current discovery usage requires scope to be returned so that it can b= e > passed to the auth server if the user is forced to re-authenticate. > >> +1 for "explicitly restrict scope values to some subset of printable > ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol= is > slightly disappointing, but I can live with it." > >> > >> ----------------------------------------------------------------------= -- > >> *From:* "Manger, James H" James.H.Manger@team.telstra.com>> > >> *To:* Mike Jones Michael.Jones@microsoft.com>>; "oauth@ietf.org " < > oauth@ietf.org > > >> *Sent:* Sunday, October 2, 2011 5:50 AM > >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26 > >> The best solution is to drop the =93scope=94 field from the > =93WWW-Authenticate: Bearer ...=94 response header. =93scope=94 is releva= nt to an > OAuth2-core flow, not to presenting a bearer token. =93scope=94 could mak= e sense > in a =93WWW-Authenticate: OAuth2 ...=94 response header as long as other > necessary details such as an authorization URI were also provided. Droppi= ng > =93scope=94 and =93error_description=94 (as the error should be described= in the > response body) would eliminate these encoding problems. > >> If the group really wants to keep =93scope=94, I don=92t think RFC 598= 7 is a > good solution. RFC 5987 might have been ok for adding internationalizatio= n > support to long-standing ASCII-only fields in a world of multiple charact= er > sets =96 but none of that applies here. Having to change the field name f= rom > =93scope=94 to =93scope*=94 when you have a non-ASCII value is the bigges= t flaw. > >> The simplest solution is to explicitly restrict scope values to some > subset of printable ASCII in OAuth2 Core. Not being able to support Unico= de > in a new protocol is slightly disappointing, but I can live with it. > >> My preferred escaping solution would be a JSON string, UTF-8 encoded: > json.org , RFC 4627; value in double-quotes; slash is th= e > escape char; supports Unicode; eg scope=3D"coll\u00E8gues". This is > backward-compatible with HTTP=92s quoted-string syntax. It is > forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is > well-supported (and required for other OAuth2 exchanges). [I might sugges= t > json-string to the httpbis group as a global replacement for quoted-strin= g > (or at least as a recommendation for new fields).] > >> -- > >> James Manger > >> *From:* oauth-bounces@ietf.org [mailto= : > oauth-bounces@ietf.org] *On > Behalf Of *Mike Jones > >> *Sent:* Friday, 30 September 2011 4:53 AM > >> *To:* oauth@ietf.org > >> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 > >> There seems to now be more working group interest in representing > non-ASCII characters in scope strings than had previously been in evidenc= e. > If we decide to define a standard representation for doing so, using RFC > 5987 (Character Set and Language > Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) > seems to be the clear choice. I=92d be interested in knowing how many wo= rking > group members are in favor of either: > >> 1. Using RFC 5987 encoding for the scope parameter. > >> 2. Continuing to specify no non-ASCII encoding for scope parameter > values. > >> As a related issue, some working group members have objected to > specifying UTF-8 encoding of the error_description value, requesting the = use > of RFC 5987 encoding instead. I=92d also be interested in knowing how ma= ny > working group members are in favor of either: > >> A. Using RFC 5987 encoding for the error_description parameter. > >> B. Continuing to specify UTF-8 encoding for the error_description > parameter. > >> (As editor, I would make the observation that if we choose RFC 5987 > encoding for either of these parameters, it would be logical to do so for > the other one as well.) > >> In the interest of finishing the specification in a way that meets > everyone=92s needs, > >> -- Mike > >> > >> _______________________________________________ > >> 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 > > **** > > ** ** > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > ** ** > --001636ed62ee3f739704ae7d68aa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones <Michael.Jo= nes@microsoft.com> wrote:

Exist= ing practice is that simple ASCII strings like =93email=94 =93profile=94, = =93openid=94, etc. are used as scope elements.=A0 Requiring them to be URIs= would break most existing practice.


= Aren't these simple strings URIs? I think they are parsed as a URI with= no scheme and authority only a path.

Marius
=A0

=A0

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu
Sent: Tuesday, October 04, 2011 11:01 AM
To: Phil Hunt
Cc: oauth@ietf.o= rg WG


Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= u>

=A0

I just realized that scopes are defined as a space s= eparated list of strings, for some reason I though they are a list of URIs.=

=A0

Mark Lentczner just clarified for me that=A0URIs are= supposed to be ASCII only. IRIs can have non-ASCII characters and can be c= anonically converted to URIs using percent encoding (back to square one).

=A0

If the core spec defines scope as list of URIs then = the whole issue goes away. Any reason not to do that?

=A0

Marius

On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

I very much agree with you there. =A0As I said, simp= le roles are best and are by far the primary case.

=A0

I'm just not so sure we should close the door.

=A0

Phil

=A0

On 2011-10-04, at 9:58 AM, William Mills wrote:



I don't believe that scope is th= e right place to carry a more complex grant, those would live in the token.= =A0 That would more logically go in the token.=A0 XML gets weird when you get to the part about space separationoand order doesn'= t matter.=A0 Scope's current definition makes it incompatible in sublte= ways with using it for XML.

=A0

<= span style=3D"font-size:10.0pt;color:black">From: Phil Hunt <phil.hunt@oracle.com>
To: "oauth@= ietf.org WG" <oauth@ietf.org>
Sent: Tuesday, October 4, 2011 9:47 AM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26<= br>
In most cases, scope has just been a set of simple "roles" as in = "readProfile", "updateStatus", etc.

I tend to agree scope is an internal value that SHOULD never be seen by end= -users (this should be made clear). The meaning of a scope must be conveyed= in authorization dialog, the how of which is out of scope.=A0 Since the re= source server defines how it scopes information, it should be able to explain the meaning of a scope request i= n localized language.

I'm not against encoding the value if necessary to handle non-printable= characters. The issue I think comes back to complexity for the clients. Wo= uld such encoding be problematic for the clients envisioned?

Some examples I can think of:
* A URL to a specific resource
* An XML or JSON structure representing a more complex "grant" or= policy statement

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com





On 2011-10-04, at 9:01 AM, Michael Thomas wrote:

> On 10/03/2011 09:58 PM, William Mills wrote:
>> You forgot:
>>
>> 4.=A0 Restrict the character set for scope to the point where thes= e issues all go away.
>
> Assuming that this is *completely* internal, and no end users will eve= r
> see either of these,=A0 this seems like the most prudent if interopera= bility
> is the primary goal. The principle of least surprise, and all.
>
> But completely internal is impossible to guarantee, so I guess the que= stion
> is whether an incomprehensible katakana-encoded message/token is any > worse than=A0 an incomprehensible ascii-7 english one to the poor end = user
> who's trying to make sense of it. If it isn't then keeping thi= ngs simple is
> probably safer. I assume the reason that 5987 exists is because as a > whole, http shouldn't make any assumptions about whether users wil= l
> see header field data. But these are individual cases here, not a prot= ocol-wide
> mandate.
>
> Mike
>
>>
>> ------------------------------------------------------------------= ------
>> *From:* Mike Jones <Michael.Jones@microsoft.com>
>> *To:* "oa= uth@ietf.org" <oauth@ietf.org>
>> *Cc:* "Manger, James H" <James.H.Manger@team.telstra.com>; William Mills <wmills@yahoo-inc.com>
>> *Sent:* Monday, October 3, 2011 6:55 PM
>> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue= 26
>>
>> As editor, based upon James=92 input, I=92d like to expand the set= of choices for the working group to consider by adding the possibility of = using JSON string encodings for scope and error_description where the chara= cters used for the encoding are restricted to the set of 7-bit ASCII characters compatible with the HTTPbis and RFC 2= 617 parameter syntaxes.
>> 1.=A0 Using RFC 5987 encoding for the scope parameter.
>> 2.=A0 Continuing to specify no non-ASCII encoding for scope parame= ter values.
>> 3.=A0 Using JSON string encoding for the scope parameter.
>> A.=A0 Using RFC 5987 encoding for the error_description parameter.=
>> B.=A0 Continuing to specify UTF-8 encoding for the error_descripti= on parameter.
>> C.=A0 Using JSON string encoding for the error_description paramet= er.
>> As an individual, I=92m sympathetic to the argument that RFC 5987 = (with =93scope*=94 and language tags etc.) is overkill for OAuth implementa= tions, where neither of the sets of strings is intended to be presented to = end-users.=A0 Hence, the possible attractiveness of options 3 and C.
>> Thoughts from others?
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>> *From:* William Mills [mailto:wmills@yahoo-inc.com]
>> *Sent:* Sunday, October 02, 2011 11:01 PM
>> *To:* Manger, James H; Mike Jones; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue= 26
>> I don't like dropping scope from the WWW-Authenticate response= s, because my current discovery usage requires scope to be returned so that= it can be passed to the auth server if the user is forced to re-authentica= te.
>> +1 for "explicitly restrict scope values to some subset of pr= intable ASCII in OAuth2 Core. Not being able to support Unicode in a new pr= otocol is slightly disappointing, but I can live with it."
>>
>> ------------------------------------------------------------------= ------
>> *From:* "Manger, James H" <James.H.Manger@team.telstra.com<= /a> <mailto:James.H.Manger@team.telstra.com>>
>> *To:* Mike Jones <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsof= t.com>>; "oauth@ietf.org <mailto:oauth@ietf.= org>" <o= auth@ietf.org <mailto:oauth@ietf.org>>
>> *Sent:* Sunday, October 2, 2011 5:50 AM
>> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue= 26
>> The best solution is to drop the =93scope=94 field from the =93WWW= -Authenticate: Bearer ...=94 response header. =93scope=94 is relevant to an= OAuth2-core flow, not to presenting a bearer token. =93scope=94 could make= sense in a =93WWW-Authenticate: OAuth2 ...=94 response header as long as other necessary details such as an authorization URI were also = provided. Dropping =93scope=94 and =93error_description=94 (as the error sh= ould be described in the response body) would eliminate these encoding prob= lems.
>> If the group really wants to keep =93scope=94, I don=92t think RFC= 5987 is a good solution. RFC 5987 might have been ok for adding internatio= nalization support to long-standing ASCII-only fields in a world of multipl= e character sets =96 but none of that applies here. Having to change the field name from =93scope=94 to =93scope*=94 whe= n you have a non-ASCII value is the biggest flaw.
>> The simplest solution is to explicitly restrict scope values to so= me subset of printable ASCII in OAuth2 Core. Not being able to support Unic= ode in a new protocol is slightly disappointing, but I can live with it. >> My preferred escaping solution would be a JSON string, UTF-8 encod= ed: json.org <http://json= .org>, RFC 4627; value in double-quotes; slash is the escape char; s= upports Unicode; eg scope=3D"coll\u00E8gues". This is backward-co= mpatible with HTTP=92s quoted-string syntax. It is forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is well-supported (and requ= ired for other OAuth2 exchanges). [I might suggest json-string to the httpb= is group as a global replacement for quoted-string (or at least as a recomm= endation for new fields).]
>> --
>> James Manger
>> *From:* oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org= ] <mailto:[mailto:oauth-bounces@ietf.org]> *On Behalf Of *Mike Jones
>> *Sent:* Friday, 30 September 2011 4:53 AM
>> *To:* oauth@ie= tf.org <mailto:o= auth@ietf.org>
>> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26<= br> >> There seems to now be more working group interest in representing = non-ASCII characters in scope strings than had previously been in evidence.= =A0 If we decide to define a standard representation for doing so, using RF= C 5987 <http://tools.ietf.org/html/rfc5987> (Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP= ) Header Field Parameters) seems to be the clear choice.=A0 I=92d be intere= sted in knowing how many working group members are in favor of either:
>> 1.=A0 Using RFC 5987 encoding for the scope parameter.
>> 2.=A0 Continuing to specify no non-ASCII encoding for scope parame= ter values.
>> As a related issue, some working group members have objected to sp= ecifying UTF-8 encoding of the error_description value, requesting the use = of RFC 5987 encoding instead.=A0 I=92d also be interested in knowing how ma= ny working group members are in favor of either:
>> A.=A0 Using RFC 5987 encoding for the error_description parameter.=
>> B.=A0 Continuing to specify UTF-8 encoding for the error_descripti= on parameter.
>> (As editor, I would make the observation that if we choose RFC 598= 7 encoding for either of these parameters, it would be logical to do so for= the other one as well.)
>> In the interest of finishing the specification in a way that meets= everyone=92s needs,
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org= <mailto:OAuth@i= etf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>>=A0
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0


--001636ed62ee3f739704ae7d68aa-- From john@jkemp.net Tue Oct 4 11:45:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38621F8D1F for ; Tue, 4 Oct 2011 11:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TszjR0+SWBbZ for ; Tue, 4 Oct 2011 11:45:44 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id B861621F8D1A for ; Tue, 4 Oct 2011 11:45:43 -0700 (PDT) Received: (qmail 18806 invoked by uid 0); 4 Oct 2011 18:48:48 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by oproxy1.bluehost.com with SMTP; 4 Oct 2011 18:48:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jkemp.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=PGi8Ragr4UgCRv5VV+P5iQ3Deoly6sprjJSuMWbj9VQ=; b=MHTmVg0egGi4EPCjbWO5/iLPyDNcJqP7pGeXjCu1zGqUIzCwEHMXo/x+KxUxmb5yttQeN5QepFEBseppaPAYWsPQ7g1KxQKqkwJQX2ersOWRE63KzaXtQt9Vf7vNcaHz; Received: from [32.178.29.78] (helo=mobile000.mycingular.net) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1RBA2p-0007hS-6M; Tue, 04 Oct 2011 12:48:47 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: John Kemp In-Reply-To: Date: Tue, 4 Oct 2011 14:48:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36B99077-FF46-4A05-8976-24C1A0B19138@jkemp.net> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Marius Scurtescu X-Mailer: Apple Mail (2.1244.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 32.178.29.78 authed with john+jkemp.net} Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:45:45 -0000 On Oct 4, 2011, at 2:38 PM, Marius Scurtescu wrote: > On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones = wrote: > Existing practice is that simple ASCII strings like =93email=94 = =93profile=94, =93openid=94, etc. are used as scope elements. Requiring = them to be URIs would break most existing practice. >=20 >=20 > Aren't these simple strings URIs? I think they are parsed as a URI = with no scheme and authority only a path. Is there a need to parse these things as URIs semantically-speaking? Why = wouldn't we restrict the character set of scopes to be those possible in = a URI, but not say they have to be URIs semantically? I'd hate to = require them to actually be URIs... - John >=20 > Marius > =20 >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Marius Scurtescu > Sent: Tuesday, October 04, 2011 11:01 AM > To: Phil Hunt > Cc: oauth@ietf.org WG >=20 >=20 > Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 >=20 > =20 >=20 > I just realized that scopes are defined as a space separated list of = strings, for some reason I though they are a list of URIs. >=20 > =20 >=20 > Mark Lentczner just clarified for me that URIs are supposed to be = ASCII only. IRIs can have non-ASCII characters and can be canonically = converted to URIs using percent encoding (back to square one). >=20 > =20 >=20 > If the core spec defines scope as list of URIs then the whole issue = goes away. Any reason not to do that? >=20 > =20 >=20 > Marius >=20 >=20 > On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt = wrote: >=20 > I very much agree with you there. As I said, simple roles are best = and are by far the primary case. >=20 > =20 >=20 > I'm just not so sure we should close the door. >=20 > =20 >=20 > Phil >=20 > =20 >=20 > @independentid >=20 > www.independentid.com >=20 > phil.hunt@oracle.com >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On 2011-10-04, at 9:58 AM, William Mills wrote: >=20 >=20 >=20 >=20 > I don't believe that scope is the right place to carry a more complex = grant, those would live in the token. That would more logically go in = the token. XML gets weird when you get to the part about space = separationoand order doesn't matter. Scope's current definition makes = it incompatible in sublte ways with using it for XML. >=20 > =20 >=20 > From: Phil Hunt > To: "oauth@ietf.org WG" > Sent: Tuesday, October 4, 2011 9:47 AM > Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 >=20 > In most cases, scope has just been a set of simple "roles" as in = "readProfile", "updateStatus", etc. >=20 > I tend to agree scope is an internal value that SHOULD never be seen = by end-users (this should be made clear). The meaning of a scope must be = conveyed in authorization dialog, the how of which is out of scope. = Since the resource server defines how it scopes information, it should = be able to explain the meaning of a scope request in localized language. >=20 > I'm not against encoding the value if necessary to handle = non-printable characters. The issue I think comes back to complexity for = the clients. Would such encoding be problematic for the clients = envisioned? >=20 > Some examples I can think of: > * A URL to a specific resource > * An XML or JSON structure representing a more complex "grant" or = policy statement >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2011-10-04, at 9:01 AM, Michael Thomas wrote: >=20 > > On 10/03/2011 09:58 PM, William Mills wrote: > >> You forgot: > >>=20 > >> 4. Restrict the character set for scope to the point where these = issues all go away. > >=20 > > Assuming that this is *completely* internal, and no end users will = ever > > see either of these, this seems like the most prudent if = interoperability > > is the primary goal. The principle of least surprise, and all. > >=20 > > But completely internal is impossible to guarantee, so I guess the = question > > is whether an incomprehensible katakana-encoded message/token is any > > worse than an incomprehensible ascii-7 english one to the poor end = user > > who's trying to make sense of it. If it isn't then keeping things = simple is > > probably safer. I assume the reason that 5987 exists is because as a > > whole, http shouldn't make any assumptions about whether users will > > see header field data. But these are individual cases here, not a = protocol-wide > > mandate. > >=20 > > Mike > >=20 > >>=20 > >> = ------------------------------------------------------------------------ > >> *From:* Mike Jones > >> *To:* "oauth@ietf.org" > >> *Cc:* "Manger, James H" ; William = Mills > >> *Sent:* Monday, October 3, 2011 6:55 PM > >> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue = 26 > >>=20 > >> As editor, based upon James=92 input, I=92d like to expand the set = of choices for the working group to consider by adding the possibility = of using JSON string encodings for scope and error_description where the = characters used for the encoding are restricted to the set of 7-bit = ASCII characters compatible with the HTTPbis and RFC 2617 parameter = syntaxes. > >> 1. Using RFC 5987 encoding for the scope parameter. > >> 2. Continuing to specify no non-ASCII encoding for scope parameter = values. > >> 3. Using JSON string encoding for the scope parameter. > >> A. Using RFC 5987 encoding for the error_description parameter. > >> B. Continuing to specify UTF-8 encoding for the error_description = parameter. > >> C. Using JSON string encoding for the error_description parameter. > >> As an individual, I=92m sympathetic to the argument that RFC 5987 = (with =93scope*=94 and language tags etc.) is overkill for OAuth = implementations, where neither of the sets of strings is intended to be = presented to end-users. Hence, the possible attractiveness of options 3 = and C. > >> Thoughts from others? > >> -- = Mike > >> *From:* William Mills [mailto:wmills@yahoo-inc.com] > >> *Sent:* Sunday, October 02, 2011 11:01 PM > >> *To:* Manger, James H; Mike Jones; oauth@ietf.org > >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue = 26 > >> I don't like dropping scope from the WWW-Authenticate responses, = because my current discovery usage requires scope to be returned so that = it can be passed to the auth server if the user is forced to = re-authenticate. > >> +1 for "explicitly restrict scope values to some subset of = printable ASCII in OAuth2 Core. Not being able to support Unicode in a = new protocol is slightly disappointing, but I can live with it." > >>=20 > >> = ------------------------------------------------------------------------ > >> *From:* "Manger, James H" > > >> *To:* Mike Jones >; "oauth@ietf.org = " > > >> *Sent:* Sunday, October 2, 2011 5:50 AM > >> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue = 26 > >> The best solution is to drop the =93scope=94 field from the = =93WWW-Authenticate: Bearer ...=94 response header. =93scope=94 is = relevant to an OAuth2-core flow, not to presenting a bearer token. = =93scope=94 could make sense in a =93WWW-Authenticate: OAuth2 ...=94 = response header as long as other necessary details such as an = authorization URI were also provided. Dropping =93scope=94 and = =93error_description=94 (as the error should be described in the = response body) would eliminate these encoding problems. > >> If the group really wants to keep =93scope=94, I don=92t think RFC = 5987 is a good solution. RFC 5987 might have been ok for adding = internationalization support to long-standing ASCII-only fields in a = world of multiple character sets =96 but none of that applies here. = Having to change the field name from =93scope=94 to =93scope*=94 when = you have a non-ASCII value is the biggest flaw. > >> The simplest solution is to explicitly restrict scope values to = some subset of printable ASCII in OAuth2 Core. Not being able to support = Unicode in a new protocol is slightly disappointing, but I can live with = it. > >> My preferred escaping solution would be a JSON string, UTF-8 = encoded: json.org , RFC 4627; value in double-quotes; = slash is the escape char; supports Unicode; eg scope=3D"coll\u00E8gues". = This is backward-compatible with HTTP=92s quoted-string syntax. It is = forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is = well-supported (and required for other OAuth2 exchanges). [I might = suggest json-string to the httpbis group as a global replacement for = quoted-string (or at least as a recommendation for new fields).] > >> -- > >> James Manger > >> *From:* oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] = *On Behalf Of *Mike Jones > >> *Sent:* Friday, 30 September 2011 4:53 AM > >> *To:* oauth@ietf.org > >> *Subject:* [OAUTH-WG] Possible alternative resolution to issue 26 > >> There seems to now be more working group interest in representing = non-ASCII characters in scope strings than had previously been in = evidence. If we decide to define a standard representation for doing = so, using RFC 5987 (Character Set = and Language Encoding for Hypertext Transfer Protocol (HTTP) Header = Field Parameters) seems to be the clear choice. I=92d be interested in = knowing how many working group members are in favor of either: > >> 1. Using RFC 5987 encoding for the scope parameter. > >> 2. Continuing to specify no non-ASCII encoding for scope parameter = values. > >> As a related issue, some working group members have objected to = specifying UTF-8 encoding of the error_description value, requesting the = use of RFC 5987 encoding instead. I=92d also be interested in knowing = how many working group members are in favor of either: > >> A. Using RFC 5987 encoding for the error_description parameter. > >> B. Continuing to specify UTF-8 encoding for the error_description = parameter. > >> (As editor, I would make the observation that if we choose RFC 5987 = encoding for either of these parameters, it would be logical to do so = for the other one as well.) > >> In the interest of finishing the specification in a way that meets = everyone=92s needs, > >> -- Mike > >>=20 > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Tue Oct 4 12:15:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6F621F8F58 for ; Tue, 4 Oct 2011 12:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I098jDY-970M for ; Tue, 4 Oct 2011 12:15:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DE73C21F8F57 for ; Tue, 4 Oct 2011 12:15:13 -0700 (PDT) Received: (qmail invoked by alias); 04 Oct 2011 19:18:18 -0000 Received: from p5DCC39D6.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.57.214] by mail.gmx.net (mp037) with SMTP; 04 Oct 2011 21:18:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18pNIJLoccpcHDzitm8+lcJI15wIkP+z969WKh+kK BjE/XZa8C9oxmO Message-ID: <4E8B5BF8.3040407@gmx.de> Date: Tue, 04 Oct 2011 21:18:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Marius Scurtescu References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:15:15 -0000 On 2011-10-04 20:38, Marius Scurtescu wrote: > On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones > wrote: > > Existing practice is that simple ASCII strings like “email” > “profile”, “openid”, etc. are used as scope elements. Requiring > them to be URIs would break most existing practice. > > > Aren't these simple strings URIs? I think they are parsed as a URI with > no scheme and authority only a path. No, they are relative references: . From mscurtescu@google.com Tue Oct 4 13:00:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C3E21F8F08 for ; Tue, 4 Oct 2011 13:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36k98dZ2xrCo for ; Tue, 4 Oct 2011 13:00:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9022621F8F0A for ; Tue, 4 Oct 2011 13:00:29 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p94K3V0g001803 for ; Tue, 4 Oct 2011 13:03:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317758611; bh=cC6PQ6SxJXw99l/4lt7oqpssnec=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=jdqaiPHi06V75R1tE2ujH3GPUhjkUnRTDaM2MLDvbwVRm6ca4LIt20ZTTFVYLLNWR elMR9CeMBZ7E0RCfxM/Zw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=SVmwWaApfczvOzT0RJDSy13Ig3ctaGIsVjnDExEuZy60fx8K0MHPiPJBPPNqgu+Sa NJoMyZmTek7culD8ZPlUw== Received: from ywa8 (ywa8.prod.google.com [10.192.1.8]) by wpaz37.hot.corp.google.com with ESMTP id p94K3FdN016849 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 13:03:30 -0700 Received: by ywa8 with SMTP id 8so865070ywa.15 for ; Tue, 04 Oct 2011 13:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=smiM7rheGFcKd6mZRaEg8P6mL+hTMrxCwMMobISQdTY=; b=Z0E627nyPGR35vkPhvk2lec3a7f6K1usNQd2YbGSCyFLwEdP36dpKp5h0exOKB3sCo I9NTloH6RDjKGZTUyEWg== Received: by 10.100.17.30 with SMTP id 30mr1413089anq.79.1317758609703; Tue, 04 Oct 2011 13:03:29 -0700 (PDT) Received: by 10.100.17.30 with SMTP id 30mr1413073anq.79.1317758609172; Tue, 04 Oct 2011 13:03:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.14 with HTTP; Tue, 4 Oct 2011 13:03:09 -0700 (PDT) In-Reply-To: <4E8B5BF8.3040407@gmx.de> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E8B5BF8.3040407@gmx.de> From: Marius Scurtescu Date: Tue, 4 Oct 2011 13:03:09 -0700 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:00:30 -0000 On Tue, Oct 4, 2011 at 12:18 PM, Julian Reschke wro= te: > On 2011-10-04 20:38, Marius Scurtescu wrote: >> >> On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones > > wrote: >> >> =A0 =A0Existing practice is that simple ASCII strings like =93email=94 >> =A0 =A0=93profile=94, =93openid=94, etc. are used as scope elements. =A0= Requiring >> =A0 =A0them to be URIs would break most existing practice. >> >> >> Aren't these simple strings URIs? I think they are parsed as a URI with >> no scheme and authority only a path. > > No, they are relative references: > . Right, which in this case are path elements. Marius From lainhart@us.ibm.com Tue Oct 4 13:49:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8196D21F8D4A for ; Tue, 4 Oct 2011 13:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txkHO+L+rhwc for ; Tue, 4 Oct 2011 13:49:39 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id D6EA421F8D44 for ; Tue, 4 Oct 2011 13:49:38 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p94KGxsg000594 for ; Tue, 4 Oct 2011 16:16:59 -0400 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p94Kqgr23088422 for ; Tue, 4 Oct 2011 16:52:42 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p94KqgsO002732 for ; Tue, 4 Oct 2011 16:52:42 -0400 Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p94Kqglw002729 for ; Tue, 4 Oct 2011 16:52:42 -0400 To: OAuth Mailing List MIME-Version: 1.0 X-KeepSent: 7AFAAB2C:12365054-8525791F:00716C91; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Todd W Lainhart Date: Tue, 4 Oct 2011 16:52:41 -0400 X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF11|June 14, 2011) at 10/04/2011 16:52:42, Serialize complete at 10/04/2011 16:52:42 Content-Type: text/plain; charset="US-ASCII" Subject: [OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:49:39 -0000 Although it seems like an abuse of the protocol, I'm wondering at Draft 22 as a mechanism for providing authorization without specifying client credentials (i.e. evaluating it as part of an SSO solution). Specifically, I'm referencing the scenario/flow in Section 4.3 ("Resource Owner Password Credentials") where a callback_uri parameter is not specified. Assume that the client type is "public". I'm also referencing Section 2.4, "Unregistered Clients", where the text says that the spec does not exclude the use of unregistered clients (with the appropriate disclaimers). Under these conditions then, can I then expect a spec-compliant authorization server to not require client credentials when requesting an access token? -- Todd From Martin.Thomson@commscope.com Tue Oct 4 16:05:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE0521F8E26 for ; Tue, 4 Oct 2011 16:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbSD6E1tEKBU for ; Tue, 4 Oct 2011 16:05:39 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id BD12C21F8E33 for ; Tue, 4 Oct 2011 16:05:30 -0700 (PDT) X-AuditID: 0a0404e8-b7c2eae000002297-cd-4e8b91f4abba Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 0D.D9.08855.4F19B8E4; Tue, 4 Oct 2011 18:08:36 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 4 Oct 2011 18:08:36 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 5 Oct 2011 07:08:32 +0800 From: "Thomson, Martin" To: Mike Jones , Marius Scurtescu , Phil Hunt Date: Wed, 5 Oct 2011 07:08:31 +0800 Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gCGXHeAADaHZIAAGpwHEAAVgBWAABcn+4AAAZ5AgAAAWuaAAAC2sIAAAXuIAAAOfxNwABJ+pGA= Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> 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-Brightmail-Tracker: AAAAAA== Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 23:05:40 -0000 On 2011-10-05 at 05:07:06, Mike Jones wrote: > Existing practice is that simple ASCII strings like "email" "profile",=20 > "openid", etc. are used as scope elements. Requiring them to be URIs=20 > would break most existing practice. Constraining syntax to an ascii token OR a URI (relative reference) might w= ork. Anything with a colon can be interpreted as a URI; anything without b= etter use a constrained set of characters. From barryleiba.mailing.lists@gmail.com Tue Oct 4 16:45:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828F921F8BEC for ; Tue, 4 Oct 2011 16:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT4zuxIvV+PM for ; Tue, 4 Oct 2011 16:45:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5321F8BE7 for ; Tue, 4 Oct 2011 16:45:06 -0700 (PDT) Received: by yxt33 with SMTP id 33so1232518yxt.31 for ; Tue, 04 Oct 2011 16:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LHuPoFwXMC1Pb0rxwT41tYtoCuEsXr5prD0O8VV8eQo=; b=k7b+UgP8tu37jc0Y25rXUnoQ/d8vwfx6aBoqqceFfc8FPzAhzCstoNUwnzp0ukotzy JBwejYI+YxruvaFPfX2pGu4Bu2tOMl/EC0dJNmiWn2wiN5UlwvtBiuOWQAN9ACht6IpN hW9iIfirpLEFytz1BSNCVK1WjcfM/1PcouPyE= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr10150102yhm.74.1317772093199; Tue, 04 Oct 2011 16:48:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Tue, 4 Oct 2011 16:48:12 -0700 (PDT) In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> Date: Tue, 4 Oct 2011 19:48:12 -0400 X-Google-Sender-Auth: oPydjYtEhfDqGfPI_7rlmSHpWG0 Message-ID: From: Barry Leiba To: "Thomson, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 23:45:07 -0000 >> Existing practice is that simple ASCII strings like "email" "profile", >> "openid", etc. are used as scope elements. =A0Requiring them to be URIs >> would break most existing practice. > > Constraining syntax to an ascii token OR a URI (relative reference) might > work. =A0Anything with a colon can be interpreted as a URI; anything with= out > better use a constrained set of characters. This sounds like a good compromise. URI encoding is already specified elsewhere, and then ASCII tokens can be limited as they already are, with no encoding. Are there any objections to this approach? Barry From mzero@google.com Tue Oct 4 16:49:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A691921F8C44 for ; Tue, 4 Oct 2011 16:49:57 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvo-LxVN-Wu0 for ; Tue, 4 Oct 2011 16:49:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id AD61721F8CA1 for ; Tue, 4 Oct 2011 16:49:56 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p94NquTE017308 for ; Tue, 4 Oct 2011 16:52:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317772377; bh=yEdPycReIS34EP9e2UTCsH1smHI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=wyONH5RYoe7Md5nuhrGK8HnTz3qGDxjDKt6h7guY/gL+tGccOQ/JGHruxRXFI05tP quFb0+C5zacHUH7ipctuA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:content-type:x-system-of-record; b=Hd9u/OZJCojtWtY4bffdaL1iTHXnAZ/1dfANLz4JfZy79uAznPhDpwPDH7s4gUGVh m1B4bFCwwMCKFsSKUm68Q== Received: from iabn5 (iabn5.prod.google.com [10.12.90.5]) by wpaz24.hot.corp.google.com with ESMTP id p94NpcDU008309 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 16:52:55 -0700 Received: by iabn5 with SMTP id n5so1585838iab.24 for ; Tue, 04 Oct 2011 16:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=PHLNJ5y8cEsfOS20+iHr0SgqiJ1z2SX/iOg1Xbi4hGQ=; b=XulrbuIFmCsxbnbIRzjv+y77hdEYer1GugaAp1SUMd4SxTAHIBS+UovgQXXptDrO/k m+rHHsHtDYrsckLBdpeQ== Received: by 10.231.73.139 with SMTP id q11mr3100888ibj.97.1317772375235; Tue, 04 Oct 2011 16:52:55 -0700 (PDT) Received: by 10.231.73.139 with SMTP id q11mr3100883ibj.97.1317772375093; Tue, 04 Oct 2011 16:52:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.32.140 with HTTP; Tue, 4 Oct 2011 16:52:35 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> From: Mark Lentczner Date: Tue, 4 Oct 2011 16:52:35 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cd4b0ee4ff35f04ae81cabd X-System-Of-Record: true Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 23:49:57 -0000 --000e0cd4b0ee4ff35f04ae81cabd Content-Type: text/plain; charset=UTF-8 I think James has made the case that there is an issue clear. As for what to pick, I favor not restricting scopes in the core spec, and clearly specifying the way scopes will be presented in HTTP headers in the bearer spec. For the later, James supplies a nice list of the alternatives. Personally, I think the URI-escaping is least likely to trip developers up. One must be aware, though, that if there is only one scope string to provide, and it meets the token production, then the scope needn't be in quotes. I believe RFC 5987 is vast over-kill in this case. We have no need to enable multiple different encodings, nor multiple encodings with a single header. Further, I wonder how widespread support for it is in various HTTP frameworks. - Mark --000e0cd4b0ee4ff35f04ae81cabd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think James has made the case that there is an issue clear.

As for what to pick, I favor not restricting scopes in the core spec,= and clearly specifying the way scopes will be presented in HTTP headers in= the bearer spec.

For the later, James supplies a nice list of the altern= atives. Personally, I think the URI-escaping is least likely to trip develo= pers up. One must be aware, though, that if there is only one scope string = to provide, and it meets the token production, then the scope needn't b= e in quotes.

I believe RFC 5987 is vast over-kill in this case. We h= ave no need to enable multiple different encodings, nor multiple encodings = with a single header. Further, I wonder how widespread support for it is in= various HTTP frameworks.

=C2=A0 - Mark

--000e0cd4b0ee4ff35f04ae81cabd-- From wmills@yahoo-inc.com Tue Oct 4 16:53:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5141721F8CDE for ; Tue, 4 Oct 2011 16:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.399 X-Spam-Level: X-Spam-Status: No, score=-17.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5GfwJaB45Et for ; Tue, 4 Oct 2011 16:53:07 -0700 (PDT) Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by ietfa.amsl.com (Postfix) with SMTP id 5301E21F8CDC for ; Tue, 4 Oct 2011 16:53:07 -0700 (PDT) Received: from [98.139.212.151] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 04 Oct 2011 23:56:08 -0000 Received: from [98.139.212.237] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 04 Oct 2011 23:56:08 -0000 Received: from [127.0.0.1] by omp1046.mail.bf1.yahoo.com with NNFMP; 04 Oct 2011 23:56:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 360448.399.bm@omp1046.mail.bf1.yahoo.com Received: (qmail 51997 invoked by uid 60001); 4 Oct 2011 23:56:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1317772567; bh=vgWJ8LZZBuQU3QM2JJYPVfYIHYed5i4nsAJwKcgbLJk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=e0sthhkPuzja8fMxagoTeV8Q72qB2bFvj9tdeWFn7qdFedc3oyUBRns2H4POZQBP787dd7E2GksaDhpUy68FepGjRSSo4mWmgA7Mus3i5DT+jN6s+7McrO1SBxuaIFSYN8DzC32dFSdi2YzyyQFr0l5mU+2vUNuOPTdzpcBKTS8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=I+4OUfSmCUtNCexzFnUX72vJRF8gRwWmp5/mzbHZ5pa2G7+PjIO/aowQY/mGnx4jp/sVflZyRTYmzDwh6Znct+bHJutjlrR8f4hN9N6McvvErAJ22jtah8AhnYrm9jSLw79aJnILjUz/wNXXJ8lrdi2BUxVi8BVX8L8gKRJqLXE=; X-YMail-OSG: yLRDjSUVM1nQyDrqpRIpGKiouOwesKi7XdF89dxoUmC6FkC c3gkA9hofezJb_IEr1sbOdQJcOPgsVY7mOpsgzlEv5uvgcV5_Tq1alPH0_1O _yEBBeRCWLsYAoYkmh.wb3Y_837TPCetUZbXdctqmry4Gjyj9WdoQH1mrSRp 6ZLPyBkMH9DQ7JZVQ1zA5LJtbf_1RNh7BvqSdikM72vY23rNIHge_hbkKfIi IXYUdWpkawfwbukpNARFgbMmHd6i9CHfLOV8Ylmb_lyS0RKK17vKmgGr9EJp F7WGmhz1tL1_XcItXr4XJlNtj.En.qhCOJThTaw.q6CayuN1gXvmtCS5vCTQ Z.kkw_7rmAOM.4wy3LTh3QZxoG6qkpbgioi8kv2OFas2DGgvhpfXS9gVd4lt l_E9WbQiCycNsVhN7d5UVhHJNo5E.Qe.P0aZI71rXqiuY06b0TMk2aMoQdR_ 8xP1MC2AzRw96Iy0YsyVeE5AET5u0bdOSzPdjPSfbcGl8LN8.2jcXzshmaPn o5t.d_pI.NyPCW_2pLq9Z41J5g2iso.1kdHD61Mp00PVK6SX7SBl1dYSxcHe v9UN1AK5JX9hJN0gELA-- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Tue, 04 Oct 2011 16:56:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> Message-ID: <1317772567.49150.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 4 Oct 2011 16:56:07 -0700 (PDT) From: William Mills To: "Thomson, Martin" , Mike Jones , Marius Scurtescu , Phil Hunt In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1399109201-1317772567=:49150" Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 23:53:08 -0000 --0-1399109201-1317772567=:49150 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Allowing URI requires allowing % encoding, which is workable.=A0 As far as = the protocol goes URI is a form of space separated string and the protocol = doesn't care.=A0 URI doesn't include quote or qhitespace in the allowed cha= racters so there's no problem there.=0A=0AI agree that we'd have to write i= t such that=A0 it's clear you don't have to use a URI.=A0 Drawing from http= ://labs.apache.org/webarch/uri/rev-2002/rfc2396bis.html#path perhaps the al= lowed charset becomes=0A=0Ascope =3D *( unreserved / reserved / pct-encoded= )=0A=0Awith the clarification that a scope MAY take the form of a properly= formatted URI.=0A=0A-bill=0A=0A=0A=0A=0A________________________________= =0AFrom: "Thomson, Martin" =0ATo: Mike Jones = ; Marius Scurtescu ; Ph= il Hunt =0ACc: "oauth@ietf.org WG" = =0ASent: Tuesday, October 4, 2011 4:08 PM=0ASubject: Re: [OAUTH-WG] Possibl= e alternative resolution to issue 26=0A=0AOn 2011-10-05 at 05:07:06, Mike J= ones wrote:=0A> Existing practice is that simple ASCII strings like "email"= "profile", =0A> "openid", etc. are used as scope elements.=A0 Requiring th= em to be URIs =0A> would break most existing practice.=0A=0AConstraining sy= ntax to an ascii token OR a URI (relative reference) might work.=A0 Anythin= g with a colon can be interpreted as a URI; anything without better use a c= onstrained set of characters.=0A___________________________________________= ____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/oauth --0-1399109201-1317772567=:49150 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Allowing URI requires allowing % encoding, which is workable.  As fa= r as the protocol goes URI is a form of space separated string and the prot= ocol doesn't care.  URI doesn't include quote or qhitespace in the all= owed characters so there's no problem there.

I agree that we'd have to write it such that  it's clear= you don't have to use a URI.  Drawing from http://labs.apache.org/w= ebarch/uri/rev-2002/rfc2396bis.html#path perhaps the allowed charset be= comes

scope =3D *( unreserved / reserved / =
pct-encoded )

with the clarification that a scope MAY take the form =
of a properly formatted URI.

-bill



<= /span>
From: "Th= omson, Martin" <Martin.Thomson@commscope.com>
To: Mike Jones <Michael.Jones@microsoft.com>; Mari= us Scurtescu <mscurtescu@google.com>; Phil Hunt <phil.hunt@oracle.= com>
Cc: "oauth@ietf= .org WG" <oauth@ietf.org>
Se= nt: Tuesday, October 4, 2011 4:08 PM
Subject: Re: [OAUTH-WG] Possible alternative resol= ution to issue 26

=0AOn 2011-10-05 at 05:07:06, Mike Jones wr= ote:
> Existing practice is that simple ASCII strings like "email" "p= rofile",
> "openid", etc. are used as scope elements.  Requirin= g them to be URIs
> would break most existing practice.

Const= raining syntax to an ascii token OR a URI (relative reference) might work.&= nbsp; Anything with a colon can be interpreted as a URI; anything without b= etter use a constrained set of characters.
_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth


--0-1399109201-1317772567=:49150-- From julian.reschke@gmx.de Wed Oct 5 00:20:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4E021F8B46 for ; Wed, 5 Oct 2011 00:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.043 X-Spam-Level: X-Spam-Status: No, score=-103.043 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THL9nm1MKr3e for ; Wed, 5 Oct 2011 00:20:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B283F21F8B45 for ; Wed, 5 Oct 2011 00:20:19 -0700 (PDT) Received: (qmail invoked by alias); 05 Oct 2011 07:23:24 -0000 Received: from p5DCC39D6.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.57.214] by mail.gmx.net (mp044) with SMTP; 05 Oct 2011 09:23:24 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ZyEg/u6eZ6KdS6D3ASNJs0CseLk7OpTMRaWWJ4r ipu6xBSbvn0TjF Message-ID: <4E8C05EA.5060004@gmx.de> Date: Wed, 05 Oct 2011 09:23:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mark Lentczner References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 07:20:21 -0000 On 2011-10-05 01:52, Mark Lentczner wrote: > I think James has made the case that there is an issue clear. > > As for what to pick, I favor not restricting scopes in the core spec, > and clearly specifying the way scopes will be presented in HTTP headers > in the bearer spec. > > For the later, James supplies a nice list of the alternatives. > Personally, I think the URI-escaping is least likely to trip developers > up. One must be aware, though, that if there is only one scope string to > provide, and it meets the token production, then the scope needn't be in > quotes. > > I believe RFC 5987 is vast over-kill in this case. We have no need to > enable multiple different encodings, nor multiple encodings with a > single header. Further, I wonder how widespread support for it is in > various HTTP frameworks. To answer that: RFC 5987 requires recipients to support UTF-8 and ISO-8859-1: so *two* encoding schemes. RFC 5987bis which is currently under discussion restricts this further to UTF-8. HTTP frameworks that support Content-Disposition properly should have support for it. I'm not saying that many do right now, but the number is growing. Format-wise: the value field is the same as for URI encoding, except that it adds a prefix specifying the encoding (and the optional language). It's dead easy to parse as you can just split on single quotes, take the first as encoding name and the third as URI-encoded value. Finally, "just" specifying URI encoding still requires that people are told which encoding to use before percent encoding. In RFC 5987 this is explicit on the wire. If you do just URI encoding there's always the risk that people don't "get" it and just use what seems simple and works for ASCII (for instance, String.getBytes() without encoding parameter). Best regards, Julian From julian.reschke@gmx.de Wed Oct 5 00:22:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76A521F8513 for ; Wed, 5 Oct 2011 00:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.993 X-Spam-Level: X-Spam-Status: No, score=-102.993 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcvP9n-eVl-Q for ; Wed, 5 Oct 2011 00:22:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 05AA821F84FB for ; Wed, 5 Oct 2011 00:22:38 -0700 (PDT) Received: (qmail invoked by alias); 05 Oct 2011 07:25:42 -0000 Received: from p5DCC39D6.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.57.214] by mail.gmx.net (mp062) with SMTP; 05 Oct 2011 09:25:42 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19hZKcNTWFhLD54v/ivjGtiRNIfmM8ezZP6cbUgfS wQoC7XavQWdQuG Message-ID: <4E8C066A.2030504@gmx.de> Date: Wed, 05 Oct 2011 09:25:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: William Mills References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> <1317772567.49150.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1317772567.49150.YahooMailNeo@web31811.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 07:22:40 -0000 On 2011-10-05 01:56, William Mills wrote: > Allowing URI requires allowing % encoding, which is workable. As far as > the protocol goes URI is a form of space separated string and the > protocol doesn't care. URI doesn't include quote or qhitespace in the > allowed characters so there's no problem there. > > I agree that we'd have to write it such that it's clear you don't have > to use a URI. Drawing from > http://labs.apache.org/webarch/uri/rev-2002/rfc2396bis.html#path perhaps > the allowed charset becomes > ... Note that RFC 2396 has been obsoleted by RFC 3986 a long time ago. Don't use it as base syntax. Best regards, Julian From jricher@mitre.org Wed Oct 5 05:45:17 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A7521F8D35 for ; Wed, 5 Oct 2011 05:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bp1xA6O2FSRP for ; Wed, 5 Oct 2011 05:45:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1538B21F8D31 for ; Wed, 5 Oct 2011 05:45:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A0AED21B10DC; Wed, 5 Oct 2011 08:48:24 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9B89D21B0B03; Wed, 5 Oct 2011 08:48:24 -0400 (EDT) Received: from [129.83.50.1] (129.83.31.55) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.339.1; Wed, 5 Oct 2011 08:48:24 -0400 From: Justin Richer To: Mark Lentczner In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 5 Oct 2011 08:46:50 -0400 Message-ID: <1317818810.13049.10.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 12:45:17 -0000 +1 I would also prefer to not restrict scope values but provide clear encoding for places where transport is going to be an issue. This is what we do with tokens, which show up in the same places. Am I missing the reason we can't use the exact same rules (modulo the single space character) that apply to tokens? -- Justin On Tue, 2011-10-04 at 19:52 -0400, Mark Lentczner wrote: > I think James has made the case that there is an issue clear. > > > As for what to pick, I favor not restricting scopes in the core spec, > and clearly specifying the way scopes will be presented in HTTP > headers in the bearer spec. > > > For the later, James supplies a nice list of the alternatives. > Personally, I think the URI-escaping is least likely to trip > developers up. One must be aware, though, that if there is only one > scope string to provide, and it meets the token production, then the > scope needn't be in quotes. > > > I believe RFC 5987 is vast over-kill in this case. We have no need to > enable multiple different encodings, nor multiple encodings with a > single header. Further, I wonder how widespread support for it is in > various HTTP frameworks. > > > - Mark > > From eran@hueniverse.com Wed Oct 5 10:25:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B5C1F0C61 for ; Wed, 5 Oct 2011 10:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6XRAFyi8Wd5 for ; Wed, 5 Oct 2011 10:25:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 050791F0C5A for ; Wed, 5 Oct 2011 10:25:35 -0700 (PDT) Received: (qmail 18548 invoked from network); 5 Oct 2011 17:28:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Oct 2011 17:28:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 5 Oct 2011 10:28:19 -0700 From: Eran Hammer-Lahav To: William Mills , "Thomson, Martin" , Mike Jones , Marius Scurtescu , Phil Hunt Date: Wed, 5 Oct 2011 10:28:13 -0700 Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26 Thread-Index: AcyC8TXeHr+mLpCCQKK8/zcqiFejegAkmqhg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452602A522F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> <1317772567.49150.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1317772567.49150.YahooMailNeo@web31811.mail.mud.yahoo.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_90C41DD21FB7C64BB94121FBBC2E723452602A522FP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:25:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723452602A522FP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It should be much simpler than that. The v2 spec should simply limit the ch= aracter set to printable ascii with special meaning for space. Beyond that,= these are just ascii strings which can be URIs or anything else. If the se= rver choose to use these strings with some internal meaning (i.e. URI or en= coded data), it should specify how normalization may occure. But the point is, these are meant to be opaque, space-delimited string. Any= interop beyond that requires additional specification (e.g. comma delimite= d inner string values, etc.). It would be really helpful if people provide actual use cases and requireme= nts. Everything I have seen so far will work just fine with a limited ascii= set. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam Mills Sent: Tuesday, October 04, 2011 4:56 PM To: Thomson, Martin; Mike Jones; Marius Scurtescu; Phil Hunt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 Allowing URI requires allowing % encoding, which is workable. As far as th= e protocol goes URI is a form of space separated string and the protocol do= esn't care. URI doesn't include quote or qhitespace in the allowed charact= ers so there's no problem there. I agree that we'd have to write it such that it's clear you don't have to = use a URI. Drawing from http://labs.apache.org/webarch/uri/rev-2002/rfc239= 6bis.html#path perhaps the allowed charset becomes scope =3D *( unreserved / reserved / pct-encoded ) with the clarification that a scope MAY take the form of a properly formatt= ed URI. -bill ________________________________ From: "Thomson, Martin" > To: Mike Jones >; Marius Scurtescu >; Phil Hunt > Cc: "oauth@ietf.org WG" > Sent: Tuesday, October 4, 2011 4:08 PM Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 On 2011-10-05 at 05:07:06, Mike Jones wrote: > Existing practice is that simple ASCII strings like "email" "profile", > "openid", etc. are used as scope elements. Requiring them to be URIs > would break most existing practice. Constraining syntax to an ascii token OR a URI (relative reference) might w= ork. Anything with a colon can be interpreted as a URI; anything without b= etter use a constrained set of characters. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723452602A522FP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It should= be much simpler than that. The v2 spec should simply limit the character s= et to printable ascii with special meaning for space. Beyond that, these ar= e just ascii strings which can be URIs or anything else. If the server choo= se to use these strings with some internal meaning (i.e. URI or encoded dat= a), it should specify how normalization may occure.

 

= But the point is, these are meant to be opaque, space-delimited stri= ng. Any interop beyond that requires additional specification (e.g. comma d= elimited inner string values, etc.).

 

It would= be really helpful if people provide actual use cases and requirements. Eve= rything I have seen so far will work just fine with a limited ascii set.

 

=

EHL

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From= : oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= William Mills
Sent: Tuesday, October 04, 2011 4:56 PM
= To: Thomson, Martin; Mike Jones; Marius Scurtescu; Phil Hunt
Cc:<= /b> oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Possible alternativ= e resolution to issue 26

 

Allowing URI = requires allowing % encoding, which is workable.  As far as the protoc= ol goes URI is a form of space separated string and the protocol doesn't ca= re.  URI doesn't include quote or qhitespace in the allowed characters= so there's no problem there.

 

I agree that we'd have to write it such that  it's clear you don't ha= ve to use a URI.  Drawing from http://labs.apache.org/webarch/uri/re= v-2002/rfc2396bis.html#path perhaps the allowed charset becomes

= 

scope =3D *( unr=
eserved / reserved / pct-encoded )

with the clarification that a sco=
pe MAY take the form of a properly formatted URI.
-bill= 

 

 

 

From: "Thomson, = Martin" <Martin.Tho= mson@commscope.com>
To: Mike Jones <Michael.Jones@microsoft.com>; Marius Scu= rtescu <mscurtescu@google.com>; Phil Hunt <phil.hunt@ora= cle.com>
Cc: "= oauth@ietf.org WG" <oauth@iet= f.org>
Sent: Tuesday, October 4, 2011 4:08 PM
Subjec= t: Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-05 at 05:07:06, Mike Jones wrot= e:
> Existing practice is that simple ASCII strings like "email&= quot; "profile",
> "openid", etc. are used as sc= ope elements.  Requiring them to be URIs
> would break most exi= sting practice.

Constraining syntax to an ascii token OR a URI (rela= tive reference) might work.  Anything with a colon can be interpreted = as a URI; anything without better use a constrained set of characters.
_= ______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/oauth

= --_000_90C41DD21FB7C64BB94121FBBC2E723452602A522FP3PW5EX1MB01E_-- From wmills@yahoo-inc.com Wed Oct 5 10:39:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AFB1F0C55 for ; Wed, 5 Oct 2011 10:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.413 X-Spam-Level: X-Spam-Status: No, score=-17.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV2jkYCczjYi for ; Wed, 5 Oct 2011 10:39:06 -0700 (PDT) Received: from nm40-vm3.bullet.mail.bf1.yahoo.com (nm40-vm3.bullet.mail.bf1.yahoo.com [72.30.239.211]) by ietfa.amsl.com (Postfix) with SMTP id 34DAD1F0C49 for ; Wed, 5 Oct 2011 10:39:06 -0700 (PDT) Received: from [98.139.212.144] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 05 Oct 2011 17:42:08 -0000 Received: from [98.139.212.192] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 05 Oct 2011 17:42:08 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 05 Oct 2011 17:42:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 648153.2140.bm@omp1001.mail.bf1.yahoo.com Received: (qmail 99097 invoked by uid 60001); 5 Oct 2011 17:42:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1317836527; bh=E0SqpunLmMWm8ygXhRlgOBlS2SolH0Vsa/Nd7xIfLWo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dIuC1Viqbf6cjBjrHB2hYlVqQF6eCIFFhuxP4hfjiXw4eG0NYS8p3P9NdgvQtXwphDsNWJ2Ecxu4Au+/3C++Y52yoWuSNpP5Vn7Wk7xC5f72OdKSKvMZHEao++egieNKuSQxGVyiqpaAfSzc7zBfRQz/bbft4J7mXQQ8Sk9gfoE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TxwNq5GQfxbHOxEcRY6YeEvDgn72f3AygrjteYp2AL2eKuC6TaQZMRGGAw2VT4xUdmpP+IpMqbTC/Ti9aT58wB1JOaVFNE78CBKS7kll0H/phxo9CqgTX+nmsfjs8GFIkbsWhA8I1fQM0aJxUGmAX+5lo9SlaqKDRZrd88/Gv/A=; X-YMail-OSG: MZETjSwVM1nkIhX2mMgn59rcWN3vaNcic5zafcRgADzi21f m9cIj9GxyVxrU8yTChSEs7zhBRYpMPhsda7U3kvlb_BZYTOtVtrM8_wK7VXv 0XxCzo35zYlbFw7h3qDQVU.hR40GQXI7djJTpr0DihsYTWJmBy5uTCrmZLaC Ful11UkWWPjd1E85cSnc8joHYHIWiw7kuuE_gDW_lwcm_PITgSVdW75ZZ1kp S0QyJq6gmdHwu0OQVa4Y6833DB5Lf2DGved43HIfICVDLjbZu1lvGoKBr_id kxehaCLk.Xtv3Q._21KeiMucnJ4BcpZ2xNN3BLjhncoJmdnFa5Xw7F_7C74. 9RFJF63P7lQrX5fTEtXr56CWlWyPwnTItzwAOnVIMUBKHQrlEPEnc8v7kkgK vpBhIAHto2yG4PPrIQRE6Kt6WHvqDN8HU1oEBQqslQjS.m1795Rv.C37HCQu GiAcGUI1YxJQCUDh.p1qqI4gCPqUrTU9xH4tYzAp3X9nkTYRTaKLZkmW8QNv gEK2I_P4lJkvaUD5LlvELap.tuXuMhEunVGFhUFppJn6D2rMTuOtMcKWA Received: from [209.131.62.113] by web31813.mail.mud.yahoo.com via HTTP; Wed, 05 Oct 2011 10:42:06 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> <1317772567.49150.YahooMailNeo@web31811.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723452602A522F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1317836526.95577.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 5 Oct 2011 10:42:06 -0700 (PDT) From: William Mills To: Eran Hammer-Lahav , "Thomson, Martin" , Mike Jones , Marius Scurtescu , Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452602A522F@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-547435607-1317836526=:95577" Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:39:07 -0000 --0-547435607-1317836526=:95577 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Are quotes a problem?=A0 I think it's simpler if we leave them out.=0A=0A= =0A=0A________________________________=0AFrom: Eran Hammer-Lahav =0ATo: William Mills ; "Thomson, Martin" <= Martin.Thomson@commscope.com>; Mike Jones ; Ma= rius Scurtescu ; Phil Hunt =0A= Cc: "oauth@ietf.org WG" =0ASent: Wednesday, October 5, 2011= 10:28 AM=0ASubject: RE: [OAUTH-WG] Possible alternative resolution to issu= e 26=0A=0A=0AIt should be much simpler than that. The v2 spec should simply= limit the character set to printable ascii with special meaning for space.= Beyond that, these are just ascii strings which can be URIs or anything el= se. If the server choose to use these strings with some internal meaning (i= .e. URI or encoded data), it should specify how normalization may occure.= =0A=A0=0ABut the point is, these are meant to be opaque, space-delimited st= ring. Any interop beyond that requires additional specification (e.g. comma= delimited inner string values, etc.).=0A=A0=0AIt would be really helpful i= f people provide actual use cases and requirements. Everything I have seen = so far will work just fine with a limited ascii set.=0A=A0=0AEHL=0A=A0=0AFr= om:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Will= iam Mills=0ASent: Tuesday, October 04, 2011 4:56 PM=0ATo: Thomson, Martin; = Mike Jones; Marius Scurtescu; Phil Hunt=0ACc: oauth@ietf.org WG=0ASubject: = Re: [OAUTH-WG] Possible alternative resolution to issue 26=0A=A0=0AAllowing= URI requires allowing % encoding, which is workable.=A0 As far as the prot= ocol goes URI is a form of space separated string and the protocol doesn't = care.=A0 URI doesn't include quote or qhitespace in the allowed characters = so there's no problem there.=0A=A0=0AI agree that we'd have to write it suc= h that=A0 it's clear you don't have to use a URI.=A0 Drawing from http://la= bs.apache.org/webarch/uri/rev-2002/rfc2396bis.html#path perhaps the allowed= charset becomes=0A=0A=0A=0Ascope =3D *( unreserved / reserved / pct-encode= d )=0A=0Awith the clarification that a scope MAY take the form of a properl= y formatted URI.=0A-bill=0A=A0=0A=A0=0A=A0=0A=0A___________________________= _____=0A=0AFrom:"Thomson, Martin" =0ATo: Mike= Jones ; Marius Scurtescu ; Phil Hunt =0ACc: "oauth@ietf.org WG" =0ASent: Tuesday, October 4, 2011 4:08 PM=0ASubject: Re: [OAUTH-WG] Po= ssible alternative resolution to issue 26=0A=0AOn 2011-10-05 at 05:07:06, M= ike Jones wrote:=0A> Existing practice is that simple ASCII strings like "e= mail" "profile", =0A> "openid", etc. are used as scope elements.=A0 Requiri= ng them to be URIs =0A> would break most existing practice.=0A=0AConstraini= ng syntax to an ascii token OR a URI (relative reference) might work.=A0 An= ything with a colon can be interpreted as a URI; anything without better us= e a constrained set of characters.=0A______________________________________= _________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/oauth --0-547435607-1317836526=:95577 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Are quotes a problem?  I think it's simpler if we leave them out.

F= rom: Eran Hammer-Lahav <eran@hueniverse.com>
To: William Mills <wmills@yahoo-i= nc.com>; "Thomson, Martin" <Martin.Thomson@commscope.com>; Mike Jo= nes <Michael.Jones@microsoft.com>; Marius Scurtescu <mscurtescu@go= ogle.com>; Phil Hunt <phil.hunt@oracle.com>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>= ;
Sent: Wednesday, October 5, 2011 1= 0:28 AM
Subject: RE: [O= AUTH-WG] Possible alternative resolution to issue 26

=0A
It should be much simpler than that. The v2 spec sh= ould simply limit the character set to printable ascii with special meaning= for space. Beyond that, these are just ascii strings which can be URIs or = anything else. If the server choose to use these strings with some internal= meaning (i.e. URI or encoded data), it should specify how normalization ma= y occure.
 <= /span>
But the point is, = these are meant to be opaque, space-delimited string. Any interop beyond th= at requires additional specification (e.g. comma delimited inner string val= ues, etc.).
 
It would be really h= elpful if people provide actual use cases and requirements. Everything I ha= ve seen so far will work just fine with a limited ascii set.
 
EHL
 
From: oauth-bounces@ietf.org [= mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent= : Tuesday, October 04, 2011 4:56 PM
To: Thomson, Martin; Mike= Jones; Marius Scurtescu; Phil Hunt
Cc: oauth@ietf.org WG
S= ubject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
 
=
Allowing URI re= quires allowing % encoding, which is workable.  As far as the protocol= goes URI is a form of space separated string and the protocol doesn't care= .  URI doesn't include quote or qhitespace in the allowed characters so there= 's no problem there.
 
I agree that we'd have to write it such that&= nbsp; it's clear you don't have to use a URI.  Drawing from http://lab= s.apache.org/webarch/uri/rev-2002/rfc2396bis.html#path perhaps the allowed = charset becomes


scope =3D=
 *( unreserved / reserved / pct-encoded )

with the clarification tha=
t a scope MAY
 take the form of a properly formatted URI.
-bill
  
  
  
From: "Thomso=
n, Martin" <Mart=
in.Thomson@commscope.com>
To: Mike Jones <Michael.Jones@microsoft.com>=
;; Marius Scurtescu <mscurtesc=
u@google.com>; Phil Hunt <phil.hunt@oracle.com>
Cc=
: "oauth@ietf.org WG" <oauth@ietf.org>
Sent: Tuesday, =
October 4, 2011 4:08 PM
Subject: Re: [OAUTH-WG] Possible alternat=
ive resolution to issue 26

On 20=
11-10-05 at 05:07:06, Mike Jones wrote:
> Existing practice is that s=
imple ASCII strings like "email" "profile", 
> "openid", etc. are use=
d as scope elements.  Requiring them to be URIs 
> would break m=
ost existing practice.

Constraining syntax to an ascii token OR a UR=
I (relative reference) might work.  Anything with a colon can be inter=
preted as a URI; anything without better use a constrained set of
 characters.
_______________________________________________
OAuth ma=
iling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<=
/div>


<= /html> --0-547435607-1317836526=:95577-- From Michael.Jones@microsoft.com Fri Oct 7 01:58:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729F621F8A56 for ; Fri, 7 Oct 2011 01:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFlj6ZWO4xwq for ; Fri, 7 Oct 2011 01:58:06 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 929CC21F8A35 for ; Fri, 7 Oct 2011 01:58:06 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 7 Oct 2011 02:01:19 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0339.002; Fri, 7 Oct 2011 02:01:19 -0700 From: Mike Jones To: Barry Leiba , "Thomson, Martin" Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gCGXHeAADaHZIAAGpwHEAAVgBWAABcn+4AAAZ5AgAAAWuaAAAC2sIAAAXuIAAAOfxNwABJ+pGD//1kTAP/8t1Ug Date: Fri, 7 Oct 2011 09:01:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C22C90F@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 08:58:07 -0000 Introducing URI semantics for scope values containing colons seems like unn= ecessary and unmotivated invention at this point. In the core spec, scope = values are case-sensitive strings separated by spaces. That's it. Nothing= about URIs or colons. I believe that the scope semantics of the core and = bearer specs should be consistent; this would not be. Writing as an individual working group member... -- Mike -----Original Message----- From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Tuesday, October 04, 2011 4:48 PM To: Thomson, Martin Cc: Mike Jones; Marius Scurtescu; Phil Hunt; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 >> Existing practice is that simple ASCII strings like "email"=20 >> "profile", "openid", etc. are used as scope elements. =A0Requiring them= =20 >> to be URIs would break most existing practice. > > Constraining syntax to an ascii token OR a URI (relative reference)=20 > might work. =A0Anything with a colon can be interpreted as a URI;=20 > anything without better use a constrained set of characters. This sounds like a good compromise. URI encoding is already specified else= where, and then ASCII tokens can be limited as they already are, with no en= coding. Are there any objections to this approach? Barry From julian.reschke@gmx.de Fri Oct 7 02:09:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4D021F87E2 for ; Fri, 7 Oct 2011 02:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV48dXyCa38z for ; Fri, 7 Oct 2011 02:09:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B3F4D21F87FA for ; Fri, 7 Oct 2011 02:09:30 -0700 (PDT) Received: (qmail invoked by alias); 07 Oct 2011 09:12:41 -0000 Received: from p5DCC3D4D.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.61.77] by mail.gmx.net (mp023) with SMTP; 07 Oct 2011 11:12:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+1iUgQvE61ha7D0DX6ve0cveQ0/H8JKCCdQwLDfS R54Jgv+YWdttSm Message-ID: <4E8EC285.6080507@gmx.de> Date: Fri, 07 Oct 2011 11:12:37 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 09:09:32 -0000 On 2011-09-28 05:50, Manger, James H wrote: > I'll have another go trying to explain the problem I see with the scope parameter in the Bearer spec. > > Consider a French social network that decides to offer an API using OAuth2. It chooses 3 scope values for parts of the API related to family, friends, and business colleagues: > * "famille" > * "ami" > * "collègues" > Let's focus on the last scope. > > The site describes the scope and its semantics in HTML developer docs. That works. >
collègues
...
> > Client apps construct authorization URIs to which users are sent. That works. > https://example.fr/authz?scope=coll%C3%A8gues... > ... Wait a minute. This only works if the spec explicitly states that non-ASCII characters need to be UTF-8 encoded before escaping (this is not part of "application/x-www-form-urlencoded". Best regards, Julian From Michael.Jones@microsoft.com Fri Oct 7 02:14:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25BA21F8A91 for ; Fri, 7 Oct 2011 02:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6Lu4o1OAkop for ; Fri, 7 Oct 2011 02:14:43 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7E321F8AF2 for ; Fri, 7 Oct 2011 02:14:39 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 7 Oct 2011 02:17:52 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0339.002; Fri, 7 Oct 2011 02:17:52 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gCGXHeAADaHZIAAGpwHEACmef4A Date: Fri, 7 Oct 2011 09:17:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C22CA77TK5EX14MBXC284r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 09:14:44 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C22CA77TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGh1cyBmYXIsIEkgYmVsaWV2ZSB0aG9zZSB3aG8gaGF2ZSBleHByZXNzZWQgb3BpbmlvbnMgaGF2 ZSBiZWVuIHByZXR0eSBldmVubHkgc3BsaXQgYmV0d2VlbiAyIGFuZCAzIG9uIHRoZSBzY29wZSBp c3N1ZS4gIEnigJl2ZSBzZWVuIG5vIHN1cHBvcnQgZm9yIDEgc2luY2UgSSBzZW50IG15IHJlcXVl c3QgZm9yIG9waW5pb25zLg0KDQpGb3IgdGhlIGVycm9yX2Rlc2NyaXB0aW9uIGlzc3VlLCBJ4oCZ dmUgc2VlbiBzdXBwb3J0IGZvciBDLCB3aGVyZWFzIEnigJl2ZSBoZWFyZCBjcml0aWNpc21zIHZv aWNlZCBhZ2FpbnN0IEEgYW5kIEIsIGFuZCBoYXZlIGhlYXJkIG5vIHN1cHBvcnQgZm9yIGVpdGhl ciBvZiB0aGVtLg0KDQpJbiB0aGUgaW50ZXJlc3Qgb2YgcmVzb2x2aW5nIHRoZXNlIGlzc3Vlcywg SeKAmWQgYXBwcmVjaWF0ZSBpdCBpZiBvdGhlcnMgd291bGQgd2VpZ2ggaW4gc29vbi4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhhbmtzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6 IE1vbmRheSwgT2N0b2JlciAwMywgMjAxMSA2OjU1IFBNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFBvc3NpYmxlIGFsdGVybmF0aXZlIHJlc29sdXRpb24gdG8g aXNzdWUgMjYNCg0KQXMgZWRpdG9yLCBiYXNlZCB1cG9uIEphbWVz4oCZIGlucHV0LCBJ4oCZZCBs aWtlIHRvIGV4cGFuZCB0aGUgc2V0IG9mIGNob2ljZXMgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRv IGNvbnNpZGVyIGJ5IGFkZGluZyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgSlNPTiBzdHJpbmcg ZW5jb2RpbmdzIGZvciBzY29wZSBhbmQgZXJyb3JfZGVzY3JpcHRpb24gd2hlcmUgdGhlIGNoYXJh Y3RlcnMgdXNlZCBmb3IgdGhlIGVuY29kaW5nIGFyZSByZXN0cmljdGVkIHRvIHRoZSBzZXQgb2Yg Ny1iaXQgQVNDSUkgY2hhcmFjdGVycyBjb21wYXRpYmxlIHdpdGggdGhlIEhUVFBiaXMgYW5kIFJG QyAyNjE3IHBhcmFtZXRlciBzeW50YXhlcy4NCg0KMS4gIFVzaW5nIFJGQyA1OTg3IGVuY29kaW5n IGZvciB0aGUgc2NvcGUgcGFyYW1ldGVyLg0KMi4gIENvbnRpbnVpbmcgdG8gc3BlY2lmeSBubyBu b24tQVNDSUkgZW5jb2RpbmcgZm9yIHNjb3BlIHBhcmFtZXRlciB2YWx1ZXMuDQozLiAgVXNpbmcg SlNPTiBzdHJpbmcgZW5jb2RpbmcgZm9yIHRoZSBzY29wZSBwYXJhbWV0ZXIuDQoNCkEuICBVc2lu ZyBSRkMgNTk4NyBlbmNvZGluZyBmb3IgdGhlIGVycm9yX2Rlc2NyaXB0aW9uIHBhcmFtZXRlci4N CkIuICBDb250aW51aW5nIHRvIHNwZWNpZnkgVVRGLTggZW5jb2RpbmcgZm9yIHRoZSBlcnJvcl9k ZXNjcmlwdGlvbiBwYXJhbWV0ZXIuDQpDLiAgVXNpbmcgSlNPTiBzdHJpbmcgZW5jb2RpbmcgZm9y IHRoZSBlcnJvcl9kZXNjcmlwdGlvbiBwYXJhbWV0ZXIuDQoNCkFzIGFuIGluZGl2aWR1YWwsIEni gJltIHN5bXBhdGhldGljIHRvIHRoZSBhcmd1bWVudCB0aGF0IFJGQyA1OTg3ICh3aXRoIOKAnHNj b3BlKuKAnSBhbmQgbGFuZ3VhZ2UgdGFncyBldGMuKSBpcyBvdmVya2lsbCBmb3IgT0F1dGggaW1w bGVtZW50YXRpb25zLCB3aGVyZSBuZWl0aGVyIG9mIHRoZSBzZXRzIG9mIHN0cmluZ3MgaXMgaW50 ZW5kZWQgdG8gYmUgcHJlc2VudGVkIHRvIGVuZC11c2Vycy4gIEhlbmNlLCB0aGUgcG9zc2libGUg YXR0cmFjdGl2ZW5lc3Mgb2Ygb3B0aW9ucyAzIGFuZCBDLg0KDQpUaG91Z2h0cyBmcm9tIG90aGVy cz8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogV2lsbGlhbSBNaWxscyBbbWFpbHRvOndtaWxs c0B5YWhvby1pbmMuY29tXQ0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDAyLCAyMDExIDExOjAxIFBN DQpUbzogTWFuZ2VyLCBKYW1lcyBIOyBNaWtlIEpvbmVzOyBvYXV0aEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gUG9zc2libGUgYWx0ZXJuYXRpdmUgcmVzb2x1dGlvbiB0byBpc3N1 ZSAyNg0KDQpJIGRvbid0IGxpa2UgZHJvcHBpbmcgc2NvcGUgZnJvbSB0aGUgV1dXLUF1dGhlbnRp Y2F0ZSByZXNwb25zZXMsIGJlY2F1c2UgbXkgY3VycmVudCBkaXNjb3ZlcnkgdXNhZ2UgcmVxdWly ZXMgc2NvcGUgdG8gYmUgcmV0dXJuZWQgc28gdGhhdCBpdCBjYW4gYmUgcGFzc2VkIHRvIHRoZSBh dXRoIHNlcnZlciBpZiB0aGUgdXNlciBpcyBmb3JjZWQgdG8gcmUtYXV0aGVudGljYXRlLg0KDQor MSBmb3IgImV4cGxpY2l0bHkgcmVzdHJpY3Qgc2NvcGUgdmFsdWVzIHRvIHNvbWUgc3Vic2V0IG9m IHByaW50YWJsZSBBU0NJSSBpbiBPQXV0aDIgQ29yZS4gTm90IGJlaW5nIGFibGUgdG8gc3VwcG9y dCBVbmljb2RlIGluIGEgbmV3IHByb3RvY29sIGlzIHNsaWdodGx5IGRpc2FwcG9pbnRpbmcsIGJ1 dCBJIGNhbiBsaXZlIHdpdGggaXQuIg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206ICJNYW5nZXIsIEphbWVzIEgiIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29t PG1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPj4NClRvOiBNaWtlIEpvbmVz IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbT4+OyAib2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiIgPG9hdXRo QGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTZW50OiBTdW5kYXksIE9jdG9iZXIg MiwgMjAxMSA1OjUwIEFNDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQb3NzaWJsZSBhbHRlcm5h dGl2ZSByZXNvbHV0aW9uIHRvIGlzc3VlIDI2DQpUaGUgYmVzdCBzb2x1dGlvbiBpcyB0byBkcm9w IHRoZSDigJxzY29wZeKAnSBmaWVsZCBmcm9tIHRoZSDigJxXV1ctQXV0aGVudGljYXRlOiBCZWFy ZXIgLi4u4oCdIHJlc3BvbnNlIGhlYWRlci4g4oCcc2NvcGXigJ0gaXMgcmVsZXZhbnQgdG8gYW4g T0F1dGgyLWNvcmUgZmxvdywgbm90IHRvIHByZXNlbnRpbmcgYSBiZWFyZXIgdG9rZW4uIOKAnHNj b3Bl4oCdIGNvdWxkIG1ha2Ugc2Vuc2UgaW4gYSDigJxXV1ctQXV0aGVudGljYXRlOiBPQXV0aDIg Li4u4oCdIHJlc3BvbnNlIGhlYWRlciBhcyBsb25nIGFzIG90aGVyIG5lY2Vzc2FyeSBkZXRhaWxz IHN1Y2ggYXMgYW4gYXV0aG9yaXphdGlvbiBVUkkgd2VyZSBhbHNvIHByb3ZpZGVkLiBEcm9wcGlu ZyDigJxzY29wZeKAnSBhbmQg4oCcZXJyb3JfZGVzY3JpcHRpb27igJ0gKGFzIHRoZSBlcnJvciBz aG91bGQgYmUgZGVzY3JpYmVkIGluIHRoZSByZXNwb25zZSBib2R5KSB3b3VsZCBlbGltaW5hdGUg dGhlc2UgZW5jb2RpbmcgcHJvYmxlbXMuDQoNCg0KSWYgdGhlIGdyb3VwIHJlYWxseSB3YW50cyB0 byBrZWVwIOKAnHNjb3Bl4oCdLCBJIGRvbuKAmXQgdGhpbmsgUkZDIDU5ODcgaXMgYSBnb29kIHNv bHV0aW9uLiBSRkMgNTk4NyBtaWdodCBoYXZlIGJlZW4gb2sgZm9yIGFkZGluZyBpbnRlcm5hdGlv bmFsaXphdGlvbiBzdXBwb3J0IHRvIGxvbmctc3RhbmRpbmcgQVNDSUktb25seSBmaWVsZHMgaW4g YSB3b3JsZCBvZiBtdWx0aXBsZSBjaGFyYWN0ZXIgc2V0cyDigJMgYnV0IG5vbmUgb2YgdGhhdCBh cHBsaWVzIGhlcmUuIEhhdmluZyB0byBjaGFuZ2UgdGhlIGZpZWxkIG5hbWUgZnJvbSDigJxzY29w ZeKAnSB0byDigJxzY29wZSrigJ0gd2hlbiB5b3UgaGF2ZSBhIG5vbi1BU0NJSSB2YWx1ZSBpcyB0 aGUgYmlnZ2VzdCBmbGF3Lg0KDQpUaGUgc2ltcGxlc3Qgc29sdXRpb24gaXMgdG8gZXhwbGljaXRs eSByZXN0cmljdCBzY29wZSB2YWx1ZXMgdG8gc29tZSBzdWJzZXQgb2YgcHJpbnRhYmxlIEFTQ0lJ IGluIE9BdXRoMiBDb3JlLiBOb3QgYmVpbmcgYWJsZSB0byBzdXBwb3J0IFVuaWNvZGUgaW4gYSBu ZXcgcHJvdG9jb2wgaXMgc2xpZ2h0bHkgZGlzYXBwb2ludGluZywgYnV0IEkgY2FuIGxpdmUgd2l0 aCBpdC4NCg0KTXkgcHJlZmVycmVkIGVzY2FwaW5nIHNvbHV0aW9uIHdvdWxkIGJlIGEgSlNPTiBz dHJpbmcsIFVURi04IGVuY29kZWQ6IGpzb24ub3JnPGh0dHA6Ly9qc29uLm9yZz4sIFJGQyA0NjI3 OyB2YWx1ZSBpbiBkb3VibGUtcXVvdGVzOyBzbGFzaCBpcyB0aGUgZXNjYXBlIGNoYXI7IHN1cHBv cnRzIFVuaWNvZGU7IGVnIHNjb3BlPSJjb2xsXHUwMEU4Z3VlcyIuIFRoaXMgaXMgYmFja3dhcmQt Y29tcGF0aWJsZSB3aXRoIEhUVFDigJlzIHF1b3RlZC1zdHJpbmcgc3ludGF4LiBJdCBpcyBmb3J3 YXJkLWNvbXBhdGlibGUgd2l0aCBVVEYtOCBIVFRQIGhlYWRlcnMgKGlmIHRoYXQgb2NjdXJzKS4g SlNPTiBpcyB3ZWxsLXN1cHBvcnRlZCAoYW5kIHJlcXVpcmVkIGZvciBvdGhlciBPQXV0aDIgZXhj aGFuZ2VzKS4gW0kgbWlnaHQgc3VnZ2VzdCBqc29uLXN0cmluZyB0byB0aGUgaHR0cGJpcyBncm91 cCBhcyBhIGdsb2JhbCByZXBsYWNlbWVudCBmb3IgcXVvdGVkLXN0cmluZyAob3IgYXQgbGVhc3Qg YXMgYSByZWNvbW1lbmRhdGlvbiBmb3IgbmV3IGZpZWxkcykuXQ0KDQotLQ0KSmFtZXMgTWFuZ2Vy DQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQpTZW50OiBGcmlk YXksIDMwIFNlcHRlbWJlciAyMDExIDQ6NTMgQU0NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86 b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbT0FVVEgtV0ddIFBvc3NpYmxlIGFsdGVybmF0aXZl IHJlc29sdXRpb24gdG8gaXNzdWUgMjYNCg0KVGhlcmUgc2VlbXMgdG8gbm93IGJlIG1vcmUgd29y a2luZyBncm91cCBpbnRlcmVzdCBpbiByZXByZXNlbnRpbmcgbm9uLUFTQ0lJIGNoYXJhY3RlcnMg aW4gc2NvcGUgc3RyaW5ncyB0aGFuIGhhZCBwcmV2aW91c2x5IGJlZW4gaW4gZXZpZGVuY2UuICBJ ZiB3ZSBkZWNpZGUgdG8gZGVmaW5lIGEgc3RhbmRhcmQgcmVwcmVzZW50YXRpb24gZm9yIGRvaW5n IHNvLCB1c2luZyBSRkMgNTk4NzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTg3PiAo Q2hhcmFjdGVyIFNldCBhbmQgTGFuZ3VhZ2UgRW5jb2RpbmcgZm9yIEh5cGVydGV4dCBUcmFuc2Zl ciBQcm90b2NvbCAoSFRUUCkgSGVhZGVyIEZpZWxkIFBhcmFtZXRlcnMpIHNlZW1zIHRvIGJlIHRo ZSBjbGVhciBjaG9pY2UuICBJ4oCZZCBiZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgaG93IG1hbnkg d29ya2luZyBncm91cCBtZW1iZXJzIGFyZSBpbiBmYXZvciBvZiBlaXRoZXI6DQoNCjEuICBVc2lu ZyBSRkMgNTk4NyBlbmNvZGluZyBmb3IgdGhlIHNjb3BlIHBhcmFtZXRlci4NCjIuICBDb250aW51 aW5nIHRvIHNwZWNpZnkgbm8gbm9uLUFTQ0lJIGVuY29kaW5nIGZvciBzY29wZSBwYXJhbWV0ZXIg dmFsdWVzLg0KDQpBcyBhIHJlbGF0ZWQgaXNzdWUsIHNvbWUgd29ya2luZyBncm91cCBtZW1iZXJz IGhhdmUgb2JqZWN0ZWQgdG8gc3BlY2lmeWluZyBVVEYtOCBlbmNvZGluZyBvZiB0aGUgZXJyb3Jf ZGVzY3JpcHRpb24gdmFsdWUsIHJlcXVlc3RpbmcgdGhlIHVzZSBvZiBSRkMgNTk4NyBlbmNvZGlu ZyBpbnN0ZWFkLiAgSeKAmWQgYWxzbyBiZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgaG93IG1hbnkg d29ya2luZyBncm91cCBtZW1iZXJzIGFyZSBpbiBmYXZvciBvZiBlaXRoZXI6DQoNCkEuICBVc2lu ZyBSRkMgNTk4NyBlbmNvZGluZyBmb3IgdGhlIGVycm9yX2Rlc2NyaXB0aW9uIHBhcmFtZXRlci4N CkIuICBDb250aW51aW5nIHRvIHNwZWNpZnkgVVRGLTggZW5jb2RpbmcgZm9yIHRoZSBlcnJvcl9k ZXNjcmlwdGlvbiBwYXJhbWV0ZXIuDQoNCihBcyBlZGl0b3IsIEkgd291bGQgbWFrZSB0aGUgb2Jz ZXJ2YXRpb24gdGhhdCBpZiB3ZSBjaG9vc2UgUkZDIDU5ODcgZW5jb2RpbmcgZm9yIGVpdGhlciBv ZiB0aGVzZSBwYXJhbWV0ZXJzLCBpdCB3b3VsZCBiZSBsb2dpY2FsIHRvIGRvIHNvIGZvciB0aGUg b3RoZXIgb25lIGFzIHdlbGwuKQ0KDQpJbiB0aGUgaW50ZXJlc3Qgb2YgZmluaXNoaW5nIHRoZSBz cGVjaWZpY2F0aW9uIGluIGEgd2F5IHRoYXQgbWVldHMgZXZlcnlvbmXigJlzIG5lZWRzLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0gTWlrZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_4E1F6AAD24975D4BA5B16804296739435C22CA77TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC55aXYxMzc5NDAyNTVtc29ub3JtYWwsIGxpLnlpdjEzNzk0MDI1NW1zb25v cm1hbCwgZGl2LnlpdjEzNzk0MDI1NW1zb25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5aXYxMzc5 NDAyNTVtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnAueWl2MTM3OTQwMjU1bXNvY2hwZGVmYXVsdCwgbGkueWl2MTM3OTQwMjU1bXNvY2hwZGVm YXVsdCwgZGl2LnlpdjEzNzk0MDI1NW1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MTM3OTQwMjU1bXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KcC55aXYxMzc5NDAyNTVtc29ub3JtYWwxLCBsaS55aXYxMzc5NDAyNTVtc29u b3JtYWwxLCBkaXYueWl2MTM3OTQwMjU1bXNvbm9ybWFsMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYx Mzc5NDAyNTVtc29ub3JtYWwxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 fQ0KcC55aXYxMzc5NDAyNTVtc29jaHBkZWZhdWx0MSwgbGkueWl2MTM3OTQwMjU1bXNvY2hwZGVm YXVsdDEsIGRpdi55aXYxMzc5NDAyNTVtc29jaHBkZWZhdWx0MQ0KCXttc28tc3R5bGUtbmFtZTp5 aXYxMzc5NDAyNTVtc29jaHBkZWZhdWx0MTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxMzc5NDAyNTVtc29oeXBlcmxpbmsNCgl7bXNvLXN0eWxl LW5hbWU6eWl2MTM3OTQwMjU1bXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2MTM3OTQwMjU1bXNvaHlw ZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTM3OTQwMjU1bXNvaHlwZXJsaW5r Zm9sbG93ZWQ7fQ0Kc3Bhbi55aXYxMzc5NDAyNTVlbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxlLW5h bWU6eWl2MTM3OTQwMjU1ZW1haWxzdHlsZTE3O30NCnNwYW4ueWl2MTM3OTQwMjU1ZW1haWxzdHls ZTE4DQoJe21zby1zdHlsZS1uYW1lOnlpdjEzNzk0MDI1NWVtYWlsc3R5bGUxODt9DQpzcGFuLnlp djEzNzk0MDI1NW1zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTM3OTQwMjU1bXNv aHlwZXJsaW5rMTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi55aXYxMzc5NDAyNTVtc29oeXBlcmxpbmtmb2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MTM3OTQwMjU1bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueWl2MTM3OTQwMjU1ZW1haWxzdHlsZTE3MQ0K CXttc28tc3R5bGUtbmFtZTp5aXYxMzc5NDAyNTVlbWFpbHN0eWxlMTcxOw0KCWZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi55aXYxMzc5 NDAyNTVlbWFpbHN0eWxlMTgxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEzNzk0MDI1NWVtYWlsc3R5 bGUxODE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMwMDIwNjA7fQ0Kc3Bhbi5F bWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+VGh1cyBmYXIsIEkgYmVs aWV2ZSB0aG9zZSB3aG8gaGF2ZSBleHByZXNzZWQgb3BpbmlvbnMgaGF2ZSBiZWVuIHByZXR0eSBl dmVubHkgc3BsaXQgYmV0d2VlbiAyIGFuZCAzIG9uIHRoZSBzY29wZSBpc3N1ZS4mbmJzcDsgSeKA mXZlIHNlZW4gbm8gc3VwcG9ydCBmb3IgMSBzaW5jZSBJDQogc2VudCBteSByZXF1ZXN0IGZvciBv cGluaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDIwNjAiPkZvciB0aGUgZXJyb3JfZGVzY3JpcHRpb24gaXNzdWUsIEnigJl2 ZSBzZWVuIHN1cHBvcnQgZm9yIEMsIHdoZXJlYXMgSeKAmXZlIGhlYXJkIGNyaXRpY2lzbXMgdm9p Y2VkIGFnYWluc3QgQSBhbmQgQiwgYW5kIGhhdmUgaGVhcmQgbm8gc3VwcG9ydCBmb3IgZWl0aGVy IG9mIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDAyMDYwIj5JbiB0aGUgaW50ZXJlc3Qgb2YgcmVzb2x2aW5nIHRoZXNlIGlz c3VlcywgSeKAmWQgYXBwcmVjaWF0ZSBpdCBpZiBvdGhlcnMgd291bGQgd2VpZ2ggaW4gc29vbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gb2F1dGgtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPk1pa2UgSm9uZXM8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDAzLCAy MDExIDY6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbT0FVVEgtV0ddIFBvc3NpYmxlIGFsdGVybmF0aXZlIHJlc29sdXRpb24gdG8g aXNzdWUgMjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+QXMgZWRpdG9yLCBiYXNl ZCB1cG9uIEphbWVz4oCZIGlucHV0LCBJ4oCZZCBsaWtlIHRvIGV4cGFuZCB0aGUgc2V0IG9mIGNo b2ljZXMgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGNvbnNpZGVyIGJ5IGFkZGluZyB0aGUgcG9z c2liaWxpdHkgb2YgdXNpbmcgSlNPTiBzdHJpbmcgZW5jb2RpbmdzDQogZm9yIHNjb3BlIGFuZCBl cnJvcl9kZXNjcmlwdGlvbiB3aGVyZSB0aGUgY2hhcmFjdGVycyB1c2VkIGZvciB0aGUgZW5jb2Rp bmcgYXJlIHJlc3RyaWN0ZWQgdG8gdGhlIHNldCBvZiA3LWJpdCBBU0NJSSBjaGFyYWN0ZXJzIGNv bXBhdGlibGUgd2l0aCB0aGUgSFRUUGJpcyBhbmQgUkZDIDI2MTcgcGFyYW1ldGVyIHN5bnRheGVz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4xLiZuYnNwOyBVc2luZyBSRkMgNTk4NyBlbmNvZGluZyBmb3Ig dGhlIHNjb3BlIHBhcmFtZXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4yLiZuYnNwOyBDb250aW51aW5nIHRvIHNwZWNpZnkgbm8gbm9uLUFTQ0lJIGVuY29kaW5nIGZv ciBzY29wZSBwYXJhbWV0ZXIgdmFsdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjMuJm5ic3A7IFVzaW5nIEpTT04gc3RyaW5nIGVuY29kaW5nIGZvciB0aGUgc2NvcGUg cGFyYW1ldGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkEuJm5ic3A7IFVzaW5nIFJGQyA1 OTg3IGVuY29kaW5nIGZvciB0aGUgZXJyb3JfZGVzY3JpcHRpb24gcGFyYW1ldGVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkIuJm5ic3A7IENvbnRpbnVpbmcgdG8gc3Bl Y2lmeSBVVEYtOCBlbmNvZGluZyBmb3IgdGhlIGVycm9yX2Rlc2NyaXB0aW9uIHBhcmFtZXRlci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DLiZuYnNwOyBVc2luZyBKU09O IHN0cmluZyBlbmNvZGluZyBmb3IgdGhlIGVycm9yX2Rlc2NyaXB0aW9uIHBhcmFtZXRlci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDIwNjAiPkFzIGFuIGluZGl2aWR1YWwsIEnigJltIHN5bXBhdGhldGljIHRvIHRoZSBhcmd1bWVu dCB0aGF0IFJGQyA1OTg3ICh3aXRoIOKAnHNjb3BlKuKAnSBhbmQgbGFuZ3VhZ2UgdGFncyBldGMu KSBpcyBvdmVya2lsbCBmb3IgT0F1dGggaW1wbGVtZW50YXRpb25zLCB3aGVyZSBuZWl0aGVyDQog b2YgdGhlIHNldHMgb2Ygc3RyaW5ncyBpcyBpbnRlbmRlZCB0byBiZSBwcmVzZW50ZWQgdG8gZW5k LXVzZXJzLiZuYnNwOyBIZW5jZSwgdGhlIHBvc3NpYmxlIGF0dHJhY3RpdmVuZXNzIG9mIG9wdGlv bnMgMyBhbmQgQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDIwNjAiPlRob3VnaHRzIGZyb20gb3RoZXJzPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBXaWxsaWFtIE1pbGxzIFttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gU3VuZGF5LCBPY3RvYmVyIDAyLCAyMDExIDExOjAxIFBNPGJyPg0KPGI+VG86 PC9iPiBNYW5nZXIsIEphbWVzIEg7IE1pa2UgSm9uZXM7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFBvc3NpYmxlIGFsdGVybmF0aXZlIHJlc29sdXRp b24gdG8gaXNzdWUgMjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgZG9uJ3Qg bGlrZSBkcm9wcGluZyBzY29wZSBmcm9tIHRoZSBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlcywg YmVjYXVzZSBteSBjdXJyZW50IGRpc2NvdmVyeSB1c2FnZSByZXF1aXJlcyBzY29wZSB0byBiZSBy ZXR1cm5lZCBzbyB0aGF0IGl0IGNhbiBiZSBwYXNzZWQgdG8gdGhlDQogYXV0aCBzZXJ2ZXIgaWYg dGhlIHVzZXIgaXMgZm9yY2VkIHRvIHJlLWF1dGhlbnRpY2F0ZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiYjNDM7MSBmb3IgJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5leHBsaWNpdGx5IHJlc3Ry aWN0IHNjb3BlIHZhbHVlcyB0byBzb21lIHN1YnNldCBvZiBwcmludGFibGUgQVNDSUkgaW4NCiBP QXV0aDIgQ29yZS4gTm90IGJlaW5nIGFibGUgdG8gc3VwcG9ydCBVbmljb2RlIGluIGEgbmV3IHBy b3RvY29sIGlzIHNsaWdodGx5IGRpc2FwcG9pbnRpbmcsIGJ1dCBJIGNhbiBsaXZlIHdpdGggaXQu JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bh bj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+ICZxdW90O01hbmdlciwgSmFtZXMgSCZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86SmFt ZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbSI+SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJh LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208L2E+Jmd0OzsgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1 dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIgMiwg MjAxMSA1OjUwIEFNPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFBvc3NpYmxl IGFsdGVybmF0aXZlIHJlc29sdXRpb24gdG8gaXNzdWUgMjY8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5aXYxMzc5NDAyNTUi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgYmVzdCBzb2x1dGlv biBpcyB0byBkcm9wIHRoZSDigJxzY29wZeKAnSBmaWVsZCBmcm9tIHRoZSDigJxXV1ctQXV0aGVu dGljYXRlOiBCZWFyZXIgLi4u4oCdIHJlc3BvbnNlIGhlYWRlci4g4oCcc2NvcGXigJ0gaXMgcmVs ZXZhbnQgdG8gYW4gT0F1dGgyLWNvcmUgZmxvdywgbm90IHRvIHByZXNlbnRpbmcgYSBiZWFyZXIg dG9rZW4uIOKAnHNjb3Bl4oCdDQogY291bGQgbWFrZSBzZW5zZSBpbiBhIOKAnFdXVy1BdXRoZW50 aWNhdGU6IE9BdXRoMiAuLi7igJ0gcmVzcG9uc2UgaGVhZGVyIGFzIGxvbmcgYXMgb3RoZXIgbmVj ZXNzYXJ5IGRldGFpbHMgc3VjaCBhcyBhbiBhdXRob3JpemF0aW9uIFVSSSB3ZXJlIGFsc28gcHJv dmlkZWQuIERyb3BwaW5nIOKAnHNjb3Bl4oCdIGFuZCDigJxlcnJvcl9kZXNjcmlwdGlvbuKAnSAo YXMgdGhlIGVycm9yIHNob3VsZCBiZSBkZXNjcmliZWQgaW4gdGhlIHJlc3BvbnNlIGJvZHkpIHdv dWxkDQogZWxpbWluYXRlIHRoZXNlIGVuY29kaW5nIHByb2JsZW1zLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklmIHRoZSBncm91cCByZWFsbHkgd2Fu dHMgdG8ga2VlcCDigJxzY29wZeKAnSwgSSBkb27igJl0IHRoaW5rIFJGQyA1OTg3IGlzIGEgZ29v ZCBzb2x1dGlvbi4gUkZDIDU5ODcgbWlnaHQgaGF2ZSBiZWVuIG9rIGZvciBhZGRpbmcgaW50ZXJu YXRpb25hbGl6YXRpb24gc3VwcG9ydCB0byBsb25nLXN0YW5kaW5nIEFTQ0lJLW9ubHkgZmllbGRz DQogaW4gYSB3b3JsZCBvZiBtdWx0aXBsZSBjaGFyYWN0ZXIgc2V0cyDigJMgYnV0IG5vbmUgb2Yg dGhhdCBhcHBsaWVzIGhlcmUuIEhhdmluZyB0byBjaGFuZ2UgdGhlIGZpZWxkIG5hbWUgZnJvbSDi gJxzY29wZeKAnSB0byDigJxzY29wZSrigJ0gd2hlbiB5b3UgaGF2ZSBhIG5vbi1BU0NJSSB2YWx1 ZSBpcyB0aGUgYmlnZ2VzdCBmbGF3Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgc2ltcGxlc3Qgc29sdXRpb24g aXMgdG8gZXhwbGljaXRseSByZXN0cmljdCBzY29wZSB2YWx1ZXMgdG8gc29tZSBzdWJzZXQgb2Yg cHJpbnRhYmxlIEFTQ0lJIGluIE9BdXRoMiBDb3JlLiBOb3QgYmVpbmcgYWJsZSB0byBzdXBwb3J0 IFVuaWNvZGUgaW4gYSBuZXcgcHJvdG9jb2wgaXMgc2xpZ2h0bHkgZGlzYXBwb2ludGluZywNCiBi dXQgSSBjYW4gbGl2ZSB3aXRoIGl0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NeSBwcmVmZXJyZWQgZXNjYXBpbmcg c29sdXRpb24gd291bGQgYmUgYSBKU09OIHN0cmluZywgVVRGLTggZW5jb2RlZDoNCjxhIGhyZWY9 Imh0dHA6Ly9qc29uLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpzb24ub3JnPC9hPiwgUkZDIDQ2Mjc7 IHZhbHVlIGluIGRvdWJsZS1xdW90ZXM7IHNsYXNoIGlzIHRoZSBlc2NhcGUgY2hhcjsgc3VwcG9y dHMgVW5pY29kZTsgZWcgc2NvcGU9JnF1b3Q7Y29sbFx1MDBFOGd1ZXMmcXVvdDsuIFRoaXMgaXMg YmFja3dhcmQtY29tcGF0aWJsZSB3aXRoIEhUVFDigJlzIHF1b3RlZC1zdHJpbmcgc3ludGF4LiBJ dCBpcyBmb3J3YXJkLWNvbXBhdGlibGUgd2l0aCBVVEYtOA0KIEhUVFAgaGVhZGVycyAoaWYgdGhh dCBvY2N1cnMpLiBKU09OIGlzIHdlbGwtc3VwcG9ydGVkIChhbmQgcmVxdWlyZWQgZm9yIG90aGVy IE9BdXRoMiBleGNoYW5nZXMpLiBbSSBtaWdodCBzdWdnZXN0IGpzb24tc3RyaW5nIHRvIHRoZSBo dHRwYmlzIGdyb3VwIGFzIGEgZ2xvYmFsIHJlcGxhY2VtZW50IGZvciBxdW90ZWQtc3RyaW5nIChv ciBhdCBsZWFzdCBhcyBhIHJlY29tbWVuZGF0aW9uIGZvciBuZXcgZmllbGRzKS5dPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4tLTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2Vy PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIj4NClttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108L2E+IDxiPk9u IEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIDMwIFNl cHRlbWJlciAyMDExIDQ6NTMgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0 aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVU SC1XR10gUG9zc2libGUgYWx0ZXJuYXRpdmUgcmVzb2x1dGlvbiB0byBpc3N1ZSAyNjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGVyZSBzZWVtcyB0byBu b3cgYmUgbW9yZSB3b3JraW5nIGdyb3VwIGludGVyZXN0IGluIHJlcHJlc2VudGluZyBub24tQVND SUkgY2hhcmFjdGVycyBpbiBzY29wZSBzdHJpbmdzIHRoYW4gaGFkIHByZXZpb3VzbHkgYmVlbiBp biBldmlkZW5jZS4mbmJzcDsgSWYgd2UgZGVjaWRlIHRvIGRlZmluZSBhIHN0YW5kYXJkIHJlcHJl c2VudGF0aW9uDQogZm9yIGRvaW5nIHNvLCB1c2luZyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1OTg3IiB0YXJnZXQ9Il9ibGFuayI+DQpSRkMgNTk4NzwvYT4gKENoYXJh Y3RlciBTZXQgYW5kIExhbmd1YWdlIEVuY29kaW5nIGZvciBIeXBlcnRleHQgVHJhbnNmZXIgUHJv dG9jb2wgKEhUVFApIEhlYWRlciBGaWVsZCBQYXJhbWV0ZXJzKSBzZWVtcyB0byBiZSB0aGUgY2xl YXIgY2hvaWNlLiZuYnNwOyBJ4oCZZCBiZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgaG93IG1hbnkg d29ya2luZyBncm91cCBtZW1iZXJzIGFyZSBpbiBmYXZvciBvZiBlaXRoZXI6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MS4mbmJzcDsgVXNp bmcgUkZDIDU5ODcgZW5jb2RpbmcgZm9yIHRoZSBzY29wZSBwYXJhbWV0ZXIuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Mi4mbmJzcDsgQ29udGlu dWluZyB0byBzcGVjaWZ5IG5vIG5vbi1BU0NJSSBlbmNvZGluZyBmb3Igc2NvcGUgcGFyYW1ldGVy IHZhbHVlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5BcyBhIHJlbGF0ZWQgaXNzdWUsIHNvbWUgd29ya2luZyBncm91cCBtZW1iZXJzIGhh dmUgb2JqZWN0ZWQgdG8gc3BlY2lmeWluZyBVVEYtOCBlbmNvZGluZyBvZiB0aGUgZXJyb3JfZGVz Y3JpcHRpb24gdmFsdWUsIHJlcXVlc3RpbmcgdGhlIHVzZSBvZiBSRkMgNTk4NyBlbmNvZGluZyBp bnN0ZWFkLiZuYnNwOyBJ4oCZZCBhbHNvIGJlIGludGVyZXN0ZWQNCiBpbiBrbm93aW5nIGhvdyBt YW55IHdvcmtpbmcgZ3JvdXAgbWVtYmVycyBhcmUgaW4gZmF2b3Igb2YgZWl0aGVyOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkEuJm5ic3A7 IFVzaW5nIFJGQyA1OTg3IGVuY29kaW5nIGZvciB0aGUgZXJyb3JfZGVzY3JpcHRpb24gcGFyYW1l dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkIuJm5ic3A7IENvbnRpbnVpbmcgdG8gc3BlY2lmeSBVVEYtOCBlbmNvZGluZyBmb3IgdGhlIGVy cm9yX2Rlc2NyaXB0aW9uIHBhcmFtZXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4oQXMgZWRpdG9yLCBJIHdvdWxkIG1ha2UgdGhlIG9i c2VydmF0aW9uIHRoYXQgaWYgd2UgY2hvb3NlIFJGQyA1OTg3IGVuY29kaW5nIGZvciBlaXRoZXIg b2YgdGhlc2UgcGFyYW1ldGVycywgaXQgd291bGQgYmUgbG9naWNhbCB0byBkbyBzbyBmb3IgdGhl IG90aGVyIG9uZSBhcyB3ZWxsLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5JbiB0aGUgaW50ZXJlc3Qgb2YgZmluaXNoaW5nIHRoZSBzcGVj aWZpY2F0aW9uIGluIGEgd2F5IHRoYXQgbWVldHMgZXZlcnlvbmXigJlzIG5lZWRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739435C22CA77TK5EX14MBXC284r_-- From julian.reschke@gmx.de Fri Oct 7 02:29:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A20F21F8AF5 for ; Fri, 7 Oct 2011 02:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.922 X-Spam-Level: X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABADURXPbqC8 for ; Fri, 7 Oct 2011 02:29:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3EF1721F8A66 for ; Fri, 7 Oct 2011 02:29:06 -0700 (PDT) Received: (qmail invoked by alias); 07 Oct 2011 09:32:18 -0000 Received: from p5DCC8042.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.128.66] by mail.gmx.net (mp057) with SMTP; 07 Oct 2011 11:32:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/N6z4c6erNR08thkWlKDa1oYmK0HcrXYgRTTcl2V 60ho0dXKDuaqAx Message-ID: <4E8EC720.8030909@gmx.de> Date: Fri, 07 Oct 2011 11:32:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 09:29:08 -0000 On 2011-10-07 11:17, Mike Jones wrote: > Thus far, I believe those who have expressed opinions have been pretty > evenly split between 2 and 3 on the scope issue. I’ve seen no support > for 1 since I sent my request for opinions. Option 3 has a serious flaw in that it requires escaping the "\" in "\uNNNN", because it is the escape character in quoted-string. I think it's certain that people will be confused by that, and interop problems will happen (unless you have a strong test suite). I do support 1; I just didn't repeat what I said before. > For the error_description issue, I’ve seen support for C, whereas I’ve > heard criticisms voiced against A and B, and have heard no support for > either of them. See above. > In the interest of resolving these issues, I’d appreciate it if others > would weigh in soon. > ... Best regards, Julian From James.H.Manger@team.telstra.com Fri Oct 7 07:12:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1D521F84CD for ; Fri, 7 Oct 2011 07:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-bZYuTyOPrW for ; Fri, 7 Oct 2011 07:12:47 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC1C21F8509 for ; Fri, 7 Oct 2011 07:12:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,502,1312120800"; d="scan'208";a="47955907" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 08 Oct 2011 01:15:55 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6491"; a="39461175" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 08 Oct 2011 01:15:55 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sat, 8 Oct 2011 01:15:55 +1100 From: "Manger, James H" To: Julian Reschke , "oauth@ietf.org" Date: Sat, 8 Oct 2011 01:15:53 +1100 Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26 Thread-Index: AcyE1BA3fTFiTxlMRDayootCIcJijQAHqpnw Message-ID: <255B9BB34FB7D647A506DC292726F6E112904F03C7@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E8EC720.8030909@gmx.de> In-Reply-To: <4E8EC720.8030909@gmx.de> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 14:12:47 -0000 > Option 3 has a serious flaw in that it requires escaping the "\" in=20 > "\uNNNN", because it is the escape character in quoted-string. I think=20 > it's certain that people will be confused by that, and interop problems=20 > will happen (unless you have a strong test suite). No, the "\" in "\uNNNN" would not be escaped. The intention with adopting json-string would be to *replace* quoted-string= . I suggested this was ok as json-string is backward compatible with quoted-string. That is not strictly true. While json-string decodes "\u00E8" to a single char "=E8", quoted-string decodes it to the 5 chars "u00E8". This clash, however, may only be theoretical. It is totally pointless to escape "u" as "\u" in a quoted-string. I can confidently say it will never have been done legitimately. If it does occurs in the wild, 99% of cases will be because the sender forgot to escape the slash; and 99% of the remaining 1% will be because a malicious sender is trying to bypass a security check by escaping a char that the software never anticipated would be escaped. Quoted-string allows 93 ASCII chars to be used as themselves, and defines an escaping mechanism to add 2 more chars: double-quote and backslash (the escape char itself). An escape mechanism to support the last ASCII visible char might have been useful in an ASCII world, but it is pointless today if it doesn't allow the other 100,000 Unicode chars. If we specify json-string for a field specified elsewhere as quoted-string I suspect we will get lucky and solve our Unicode issue without causing any actual problems. That is partly because I don't think most/many OAuth HTTP clients use frameworks that automatically decode quoted-string values in their bowels. Do others who write HTTP clients have experience to the contrary? I prefer option 3 (of the 3), perhaps with a note in the spec saying: "Specifying json-string is a wilful violation of RFC 2617 that uses quoted-string. It is done to add support for Unicode values while supporting all valid quoted-string values that occur in practise." -- James Manger From julian.reschke@gmx.de Fri Oct 7 07:27:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D63721F877F for ; Fri, 7 Oct 2011 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.306 X-Spam-Level: X-Spam-Status: No, score=-104.306 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r391KTR4uVK for ; Fri, 7 Oct 2011 07:27:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 33C6C21F8753 for ; Fri, 7 Oct 2011 07:27:24 -0700 (PDT) Received: (qmail invoked by alias); 07 Oct 2011 14:30:37 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp064) with SMTP; 07 Oct 2011 16:30:37 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18WcwpfEO4WH5h9s4dReBxAOm/7ap8QpBf1zTQuJ5 AKJagtChQyYO81 Message-ID: <4E8F0D09.3020601@gmx.de> Date: Fri, 07 Oct 2011 16:30:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E8EC720.8030909@gmx.de> <255B9BB34FB7D647A506DC292726F6E112904F03C7@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112904F03C7@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 14:27:26 -0000 On 2011-10-07 16:15, Manger, James H wrote: >> Option 3 has a serious flaw in that it requires escaping the "\" in >> "\uNNNN", because it is the escape character in quoted-string. I think >> it's certain that people will be confused by that, and interop problems >> will happen (unless you have a strong test suite). > > No, the "\" in "\uNNNN" would not be escaped. > The intention with adopting json-string would be to *replace* quoted-string. You can't "replace" quoted-string. A recipient will have to be able to parse multiple challenges in a single header field value. To do so, it has to understand the syntax of params using double quotes. It can't special-case the parsing based on what part of the set of challenges it currently is looking at (because to do so, it needs to have parsed them first). > I suggested this was ok as json-string is backward compatible > with quoted-string. That is not strictly true. > While json-string decodes "\u00E8" to a single char "è", > quoted-string decodes it to the 5 chars "u00E8". Indeed. > This clash, however, may only be theoretical. > It is totally pointless to escape "u" as "\u" in a > quoted-string. I can confidently say it will never > have been done legitimately. If it does occurs in the wild, > 99% of cases will be because the sender forgot to escape > the slash; and 99% of the remaining 1% will be because > a malicious sender is trying to bypass a security check by > escaping a char that the software never anticipated would > be escaped. But that's how quoted-string is defined, and what a conforming parser will do. If your suggestion is to change that, you will have to bring that up in the HTTPbis WG, not here. > Quoted-string allows 93 ASCII chars to be used as themselves, > and defines an escaping mechanism to add 2 more chars: > double-quote and backslash (the escape char itself). > An escape mechanism to support the last ASCII visible char > might have been useful in an ASCII world, but it is pointless > today if it doesn't allow the other 100,000 Unicode chars. But that argument doesn't change the fact how it is defined. If we were free to change things, we'd simply state that everything is UTF-8. > If we specify json-string for a field specified elsewhere as > quoted-string I suspect we will get lucky and solve our Unicode > issue without causing any actual problems. That is partly > because I don't think most/many OAuth HTTP clients use > frameworks that automatically decode quoted-string values > in their bowels. Do others who write HTTP clients have > experience to the contrary? As I said above: a recipient needs to parse header field values that contain multiple challenges, and changing the syntax for "quoted-string" based on where the param appears is simply a non-starter. > I prefer option 3 (of the 3), perhaps with a note in the > spec saying: "Specifying json-string is a wilful violation > of RFC 2617 that uses quoted-string. It is done to > add support for Unicode values while supporting all valid > quoted-string values that occur in practise." Yes, it would be a willful intentional violation, without - IMHO - a strong technical argument to do so. I sure hope the IESG wouldn't accept that. Best regards, Julian From wmills@yahoo-inc.com Fri Oct 7 09:31:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AB921F8C6F for ; Fri, 7 Oct 2011 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.421 X-Spam-Level: X-Spam-Status: No, score=-17.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca3TQiCKB4Wn for ; Fri, 7 Oct 2011 09:31:27 -0700 (PDT) Received: from nm28.bullet.mail.ac4.yahoo.com (nm28.bullet.mail.ac4.yahoo.com [98.139.52.225]) by ietfa.amsl.com (Postfix) with SMTP id D6FF521F8C6C for ; Fri, 7 Oct 2011 09:31:26 -0700 (PDT) Received: from [98.139.52.191] by nm28.bullet.mail.ac4.yahoo.com with NNFMP; 07 Oct 2011 16:34:34 -0000 Received: from [98.139.52.165] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 07 Oct 2011 16:34:34 -0000 Received: from [127.0.0.1] by omp1048.mail.ac4.yahoo.com with NNFMP; 07 Oct 2011 16:34:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 836862.3891.bm@omp1048.mail.ac4.yahoo.com Received: (qmail 87311 invoked by uid 60001); 7 Oct 2011 16:34:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1318005274; bh=vf0VczMGeKOhjqthyR6JVaJ1n2MQLW8Bjg33r38bZ8g=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=lgcr0f7ZT6Qq4p1jEUooNaG5AYwK+DYyO3KqKTNOSTyAPqZvDCZxU13te8QzZz3OkkSInNooLK493KQUL8l3ZysGvAtfCxrmmlTINbgbg9COANUpDdN2yqkc8NN3SnY87WX5UkI3TgEx03XRA8D9yhSAYBmFiJd03bUM5RvbIQM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CNB/jaiibAnO+2h9zLla7YmjYtftMZuPzPFBB0LSdOyKcdFj8UX05YjOW22ZkzObpJzlBcSTUqPifjM8lg8IO8krjhadsoZHd6kZTd/AdFcjkhY9NDdTbb6lmeCdIE6iLpw+w6aOu/fEKeH9qxkGizImI/j4q7Xu7iDbBwSAzt0=; X-YMail-OSG: yr_t_k0VM1la8Au9agU5yLiLl8JQtcoBAIeewQmTEluWVez Q6FvaqSn5 Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Fri, 07 Oct 2011 09:34:33 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1318005273.69279.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Fri, 7 Oct 2011 09:34:33 -0700 (PDT) From: William Mills To: Mike Jones , "oauth@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1064058800-1318005273=:69279" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:31:28 -0000 --0-1064058800-1318005273=:69279 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable after re-reading I'm for #2=0A=0A=0A=0A________________________________=0AF= rom: Mike Jones =0ATo: "oauth@ietf.org" =0ASent: Friday, October 7, 2011 2:17 AM=0ASubject: Re: [OAUTH-WG= ] Possible alternative resolution to issue 26=0A=0A=0A =0AThus far, I belie= ve those who have expressed opinions have been pretty evenly split between = 2 and 3 on the scope issue.=C2=A0 I=E2=80=99ve seen no support for 1 since = I sent my request for opinions.=0A=C2=A0=0AFor the error_description issue,= I=E2=80=99ve seen support for C, whereas I=E2=80=99ve heard criticisms voi= ced against A and B, and have heard no support for either of them.=0A=C2=A0= =0AIn the interest of resolving these issues, I=E2=80=99d appreciate it if = others would weigh in soon.=0A=C2=A0=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Thanks,=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike=0A=C2=A0=0AFrom:oauth-bounces@ietf.org [mailto:oauth-boun= ces@ietf.org] On Behalf Of Mike Jones=0ASent: Monday, October 03, 2011 6:55= PM=0ATo: oauth@ietf.org=0ASubject: Re: [OAUTH-WG] Possible alternative res= olution to issue 26=0A=C2=A0=0AAs editor, based upon James=E2=80=99 input, = I=E2=80=99d like to expand the set of choices for the working group to cons= ider by adding the possibility of using JSON string encodings for scope and= error_description where the characters used for the encoding are restricte= d to the set of 7-bit ASCII characters compatible with the HTTPbis and RFC = 2617 parameter syntaxes.=0A=C2=A0=0A1.=C2=A0 Using RFC 5987 encoding for th= e scope parameter.=0A2.=C2=A0 Continuing to specify no non-ASCII encoding f= or scope parameter values.=0A3.=C2=A0 Using JSON string encoding for the sc= ope parameter.=0A=C2=A0=0AA.=C2=A0 Using RFC 5987 encoding for the error_de= scription parameter.=0AB.=C2=A0 Continuing to specify UTF-8 encoding for th= e error_description parameter.=0AC.=C2=A0 Using JSON string encoding for th= e error_description parameter.=0A=C2=A0=0AAs an individual, I=E2=80=99m sym= pathetic to the argument that RFC 5987 (with =E2=80=9Cscope*=E2=80=9D and l= anguage tags etc.) is overkill for OAuth implementations, where neither of = the sets of strings is intended to be presented to end-users.=C2=A0 Hence, = the possible attractiveness of options 3 and C.=0A=C2=A0=0AThoughts from ot= hers?=0A=C2=A0=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -- Mike=0A=C2=A0=0AFrom:William Mills [mailto:wmills@= yahoo-inc.com] =0ASent: Sunday, October 02, 2011 11:01 PM=0ATo: Manger, Jam= es H; Mike Jones; oauth@ietf.org=0ASubject: Re: [OAUTH-WG] Possible alterna= tive resolution to issue 26=0A=C2=A0=0AI don't like dropping scope from the= WWW-Authenticate responses, because my current discovery usage requires sc= ope to be returned so that it can be passed to the auth server if the user = is forced to re-authenticate.=0A=C2=A0=0A+1 for "explicitly restrict scope = values to some subset of printable ASCII in OAuth2 Core. Not being able to = support Unicode in a new protocol is slightly disappointing, but I can live= with it."=0A=0A________________________________=0A =0AFrom:"Manger, James = H" =0ATo: Mike Jones ; "oauth@ietf.org" =0ASent: Sunday, October 2, 2011= 5:50 AM=0ASubject: Re: [OAUTH-WG] Possible alternative resolution to issue= 26=0AThe best solution is to drop the =E2=80=9Cscope=E2=80=9D field from t= he =E2=80=9CWWW-Authenticate: Bearer ...=E2=80=9D response header. =E2=80= =9Cscope=E2=80=9D is relevant to an OAuth2-core flow, not to presenting a b= earer token. =E2=80=9Cscope=E2=80=9D could make sense in a =E2=80=9CWWW-Aut= henticate: OAuth2 ...=E2=80=9D response header as long as other necessary d= etails such as an authorization URI were also provided. Dropping =E2=80=9Cs= cope=E2=80=9D and =E2=80=9Cerror_description=E2=80=9D (as the error should = be described in the response body) would eliminate these encoding problems.= =0A=C2=A0=0A=C2=A0=0AIf the group really wants to keep =E2=80=9Cscope=E2=80= =9D, I don=E2=80=99t think RFC 5987 is a good solution. RFC 5987 might have= been ok for adding internationalization support to long-standing ASCII-onl= y fields in a world of multiple character sets =E2=80=93 but none of that a= pplies here. Having to change the field name from =E2=80=9Cscope=E2=80=9D t= o =E2=80=9Cscope*=E2=80=9D when you have a non-ASCII value is the biggest f= law.=0A=C2=A0=0AThe simplest solution is to explicitly restrict scope value= s to some subset of printable ASCII in OAuth2 Core. Not being able to suppo= rt Unicode in a new protocol is slightly disappointing, but I can live with= it.=0A=C2=A0=0AMy preferred escaping solution would be a JSON string, UTF-= 8 encoded: json.org, RFC 4627; value in double-quotes; slash is the escape = char; supports Unicode; eg scope=3D"coll\u00E8gues". This is backward-compa= tible with HTTP=E2=80=99s quoted-string syntax. It is forward-compatible wi= th UTF-8 HTTP headers (if that occurs). JSON is well-supported (and require= d for other OAuth2 exchanges). [I might suggest json-string to the httpbis = group as a global replacement for quoted-string (or at least as a recommend= ation for new fields).]=0A=C2=A0=0A--=0AJames Manger=0A=C2=A0=0AFrom:oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones=0A= Sent: Friday, 30 September 2011 4:53 AM=0ATo: oauth@ietf.org=0ASubject: [OA= UTH-WG] Possible alternative resolution to issue 26=0A=C2=A0=0AThere seems = to now be more working group interest in representing non-ASCII characters = in scope strings than had previously been in evidence.=C2=A0 If we decide t= o define a standard representation for doing so, using RFC 5987 (Character = Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Fie= ld Parameters) seems to be the clear choice.=C2=A0 I=E2=80=99d be intereste= d in knowing how many working group members are in favor of either:=0A=C2= =A0=0A1.=C2=A0 Using RFC 5987 encoding for the scope parameter.=0A2.=C2=A0 = Continuing to specify no non-ASCII encoding for scope parameter values.=0A= =C2=A0=0AAs a related issue, some working group members have objected to sp= ecifying UTF-8 encoding of the error_description value, requesting the use = of RFC 5987 encoding instead.=C2=A0 I=E2=80=99d also be interested in knowi= ng how many working group members are in favor of either:=0A=C2=A0=0AA.=C2= =A0 Using RFC 5987 encoding for the error_description parameter.=0AB.=C2=A0= Continuing to specify UTF-8 encoding for the error_description parameter.= =0A=C2=A0=0A(As editor, I would make the observation that if we choose RFC = 5987 encoding for either of these parameters, it would be logical to do so = for the other one as well.)=0A=C2=A0=0AIn the interest of finishing the spe= cification in a way that meets everyone=E2=80=99s needs,=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A=C2=A0=0A=0A_____________= __________________________________=0AOAuth mailing list=0AOAuth@ietf.org=0A= https://www.ietf.org/mailman/listinfo/oauth=0A_____________________________= __________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf= .org/mailman/listinfo/oauth --0-1064058800-1318005273=:69279 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
after re-reading I'm for #2

From: Mike Jones <Michael.Jones@= microsoft.com>
To: "= oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, October 7, 2011 2:17 AM
Subject: Re: [OAUTH-WG] Possible alternative= resolution to issue 26

=0A
=0A=0A = =0A =0A=0A= =0A
=0A
=0A
Thus far,= I believe those who have expressed opinions have been pretty evenly split = between 2 and 3 on the scope issue.  I=E2=80=99ve seen no support for = 1 since I=0A sent my request for opinions.
=0A
&nbs= p;
=0A
For the error_description issue, I=E2=80=99ve= seen support for C, whereas I=E2=80=99ve heard criticisms voiced against A= and B, and have heard no support for either of them.
=0A
 
=0A
In the interest of resolving these= issues, I=E2=80=99d appreciate it if others would weigh in soon. =0A
 
=0A
   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Thanks,
=0A
 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike
=0A  
=0A
=0A
=0A
From: oauth-bounces@ietf.org [mailto:oauth-bounces@i= etf.org]=0AOn Behalf Of Mike Jones
=0ASent: Monday, Octobe= r 03, 2011 6:55 PM
=0ATo: oauth@ietf.org
=0ASubject: Re= : [OAUTH-WG] Possible alternative resolution to issue 26
=0A=0A
=0A
 
=0AAs editor, based upon James=E2=80=99 input, I=E2=80=99d like to expa= nd the set of choices for the working group to consider by adding the possi= bility of using JSON string encodings=0A for scope and error_description wh= ere the characters used for the encoding are restricted to the set of 7-bit= ASCII characters compatible with the HTTPbis and RFC 2617 parameter syntax= es.
=0A
 
=0A
= 1.  Using RFC 5987 encoding for the scope parameter.
=0A<= div class=3D"yiv1694330989MsoNormal" style=3D"background:white;">2.  Continuing to specify no non-ASCII encoding for= scope parameter values.
=0A
3.  Using= JSON string encoding for the scope parameter.
=0A
 
=0A
A.  Using RFC 598= 7 encoding for the error_description parameter.
=0A
B.  Continuing to specify UTF-8 encoding for the error_descr= iption parameter.
=0A
C.  Using JSON s= tring encoding for the error_description parameter.
=0A
 
=0A
As an individual, I=E2=80=99m sympat= hetic to the argument that RFC 5987 (with =E2=80=9Cscope*=E2=80=9D and lang= uage tags etc.) is overkill for OAuth implementations, where neither=0A of = the sets of strings is intended to be presented to end-users.  Hence, = the possible attractiveness of options 3 and C.
=0A
 
=0A
Thoughts from others?
=0A=
 
=0A
     = ;            &n= bsp;            = ;            &n= bsp;            = ;         -- Mike
=0A<= div class=3D"yiv1694330989MsoNormal">  
=0A
=0A
=0A
From: William Mills [mailto:wmills@yahoo-inc.com]= =0A
=0ASent: Sunday, October 02, 2011 11:01 PM
=0ATo: M= anger, James H; Mike Jones; oauth@ietf.org
=0ASubject: Re: [OAUTH= -WG] Possible alternative resolution to issue 26
=0A
=0A<= /div>=0A
 
=0A
=0A=0A
I don't like dropping scope from the WWW-Authentica= te responses, because my current discovery usage requires scope to be retur= ned so that it can be passed to the=0A auth server if the user is forced to= re-authenticate.
=0A
=0A
=0A
&nb= sp;
=0A
=0A
+1 fo= r "explicitly restrict scope values t= o some subset of printable ASCII in=0A OAuth2 Core. Not being able to suppo= rt Unicode in a new protocol is slightly disappointing, but I can live with= it."
=0A
=0A
=0A<= div class=3D"yiv1694330989MsoNormal" style=3D"text-align:center;background:= white;" align=3D"center">=0A= =0A
=0A
=0A
From: "Manger, James H"=0A <James.H.Manger@team= .telstra.com>
=0ATo: Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.org" <oauth@ietf.org>
=0ASent: Sunday, October 2, 2011 5:50 AM<= br>=0ASubject: Re: [OAUTH-WG] Possible alternative resolution to iss= ue 26
=0A
=0A
=0A
=0A
=0A
The best solution= is to drop the =E2=80=9Cscope=E2=80=9D field from the =E2=80=9CWWW-Authent= icate: Bearer ...=E2=80=9D response header. =E2=80=9Cscope=E2=80=9D is rele= vant to an OAuth2-core flow, not to presenting a bearer token. =E2=80=9Csco= pe=E2=80=9D=0A could make sense in a =E2=80=9CWWW-Authenticate: OAuth2 ...= =E2=80=9D response header as long as other necessary details such as an aut= horization URI were also provided. Dropping =E2=80=9Cscope=E2=80=9D and =E2= =80=9Cerror_description=E2=80=9D (as the error should be described in the r= esponse body) would=0A eliminate these encoding problems.
=0A
=0A
=0A
&= nbsp;
=0A
=0A
=0A=
  =0A
=0A
=0A
If the group really wants to k= eep =E2=80=9Cscope=E2=80=9D, I don=E2=80=99t think RFC 5987 is a good solut= ion. RFC 5987 might have been ok for adding internationalization support to= long-standing ASCII-only fields=0A in a world of multiple character sets = =E2=80=93 but none of that applies here. Having to change the field name fr= om =E2=80=9Cscope=E2=80=9D to =E2=80=9Cscope*=E2=80=9D when you have a non-= ASCII value is the biggest flaw.=
=0A
=0A
=0A
 
=0A
=0A
=0A
T= he simplest solution is to explicitly restrict scope values to some subset = of printable ASCII in OAuth2 Core. Not being able to support Unicode in a n= ew protocol is slightly disappointing,=0A but I can live with it.
=0A
=0A
=0A
 
=0A
=0A=
=0A
<= span style=3D"color:#1F497D;">My preferred escaping solution would be a JSO= N string, UTF-8 encoded:=0Ajson.org, RFC 4627; value in double-quotes; slash is the= escape char; supports Unicode; eg scope=3D"coll\u00E8gues". This is backwa= rd-compatible with HTTP=E2=80=99s quoted-string syntax. It is forward-compa= tible with UTF-8=0A HTTP headers (if that occurs). JSON is well-supported (= and required for other OAuth2 exchanges). [I might suggest json-string to t= he httpbis group as a global replacement for quoted-string (or at least as = a recommendation for new fields).]
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
--
=0A
=0A=0A
James Manger<= /span>
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
= =0A
=0A
From:=0Aoauth-bounces@ietf.org =0A[mailto:oauth-bounces@ietf.org] On Behalf= Of Mike Jones
=0ASent: Friday, 30 September 2011 4:53 AM
= =0ATo: oauth@ietf.org
=0ASubj= ect: [OAUTH-WG] Possible alternative resolution to issue 26
=0A
=0A
=0A
=0A
= =0A
 
=0A
=0A
=0A
There seems to now be more working group interest in representing= non-ASCII characters in scope strings than had previously been in evidence= .  If we decide to define a standard representation=0A for doing so, u= sing =0ARFC 5987 (Character Set and Language Encoding for Hypert= ext Transfer Protocol (HTTP) Header Field Parameters) seems to be the clear= choice.  I=E2=80=99d be interested in knowing how many working group = members are in favor of either:
=0A
=0A
=0A
 
=0A
=0A
=0A
1.&nb= sp; Using RFC 5987 encoding for the scope parameter.
=0A
= =0A
=0A
2.  Continuing to specify no non-ASCII = encoding for scope parameter values.
=0A
=0A
=0A
 
=0A
=0A
=0A
= As a related issue, some working group members have objected to specifying = UTF-8 encoding of the error_description value, requesting the use of RFC 59= 87 encoding instead.  I=E2=80=99d also be interested=0A in knowing how= many working group members are in favor of either:
=0A
= =0A
=0A
 
=0A
=0A
=0AA.  Using RFC 5987 encoding for the error_descriptio= n parameter.
=0A
=0A
=0A
B.  = Continuing to specify UTF-8 encoding for the error_description parameter.
=0A
=0A
=0A
 
=0A=
=0A
=0A
(As editor, I would make the observati= on that if we choose RFC 5987 encoding for either of these parameters, it w= ould be logical to do so for the other one as well.)
=0A
= =0A
=0A
 
=0A
=0A
=0AIn the interest of finishing the specification in a way t= hat meets everyone=E2=80=99s needs,
=0A
=0A
=0A
          &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            -- Mik= e
=0A
=0A
=0A
 
= =0A
=0A
=0A
=0A
=0A

=0A_______________________________________________
=0AOAuth mai= ling list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A<= /div>=0A
=0A
=0A
=0A
=0A=0A

__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/oauth


--0-1064058800-1318005273=:69279-- From James.H.Manger@team.telstra.com Sun Oct 9 16:09:06 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1BA21F8A6C for ; Sun, 9 Oct 2011 16:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ8XhVgm5QVH for ; Sun, 9 Oct 2011 16:09:06 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id DE4F721F889A for ; Sun, 9 Oct 2011 16:09:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,514,1312120800"; d="scan'208";a="48368749" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 10 Oct 2011 10:09:01 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6494"; a="38966028" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 10 Oct 2011 10:08:59 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Mon, 10 Oct 2011 10:09:00 +1100 From: "Manger, James H" To: Julian Reschke Date: Mon, 10 Oct 2011 10:08:59 +1100 Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26 Thread-Index: AcyE/bLVoTGOLQBCQWeLaqbQVFBTkQB07hFw Message-ID: <255B9BB34FB7D647A506DC292726F6E1129060277B@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E8EC720.8030909@gmx.de> <255B9BB34FB7D647A506DC292726F6E112904F03C7@WSMSG3153V.srv.dir.telstra.com> <4E8F0D09.3020601@gmx.de> In-Reply-To: <4E8F0D09.3020601@gmx.de> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 23:09:06 -0000 > You can't "replace" quoted-string. > > A recipient will have to be able to parse multiple challenges in a=20 > single header field value. To do so, it has to understand the syntax of=20 > params using double quotes. It can't special-case the parsing based on=20 > what part of the set of challenges it currently is looking at (because=20 > to do so, it needs to have parsed them first). Parsing is not affected. Only un-escaping after parsing. Even if you did generic un-escaping before reaching code that understood a specific parameter (and I'm not sure that is likely), you still don't need to special-case the un-escaping. You can interpret it all like JSON as no quoted-string value in practise will escape an alphabetic letter (a-z). Not only would it be pointless for the sender to do so, they would also be violating a "SHOULD NOT" in the spec. Senders SHOULD NOT escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet). [draft-ietf-httpbis-p1-messaging-16#section-3.2.3] > If we were free to change things, we'd simply state that everything is=20 > UTF-8. But that would break things. I am only suggesting changing the interpretation of \u because I don't believe it will break any existing values. > But that argument doesn't change the fact how it is defined. Changing defined behaviour is not great. Changing defined behaviour that is *never used* (eg "\u" as an escape sequence for "u") doesn't sound so unreasonable. -- James Manger From julian.reschke@gmx.de Sun Oct 9 23:30:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E73121F8472 for ; Sun, 9 Oct 2011 23:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ3NxF-5JKUP for ; Sun, 9 Oct 2011 23:30:13 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3563821F8557 for ; Sun, 9 Oct 2011 23:30:12 -0700 (PDT) Received: (qmail invoked by alias); 10 Oct 2011 06:30:11 -0000 Received: from p5DCC9826.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.152.38] by mail.gmx.net (mp021) with SMTP; 10 Oct 2011 08:30:11 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1++xTM4rhe+HRGabamTCp0OZmYt6eV+5nKHVrNjtN TRD6UyQnID5EmA Message-ID: <4E9290ED.6070403@gmx.de> Date: Mon, 10 Oct 2011 08:30:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E8EC720.8030909@gmx.de> <255B9BB34FB7D647A506DC292726F6E112904F03C7@WSMSG3153V.srv.dir.telstra.com> <4E8F0D09.3020601@gmx.de> <255B9BB34FB7D647A506DC292726F6E1129060277B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1129060277B@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 06:30:14 -0000 On 2011-10-10 01:08, Manger, James H wrote: >> You can't "replace" quoted-string. >> >> A recipient will have to be able to parse multiple challenges in a >> single header field value. To do so, it has to understand the syntax of >> params using double quotes. It can't special-case the parsing based on >> what part of the set of challenges it currently is looking at (because >> to do so, it needs to have parsed them first). > > Parsing is not affected. Only un-escaping after parsing. > > Even if you did generic un-escaping before reaching code that > understood a specific parameter (and I'm not sure that is likely), It is possible. There is code out there that does it. > you still don't need to special-case the un-escaping. You can interpret it > all like JSON as no quoted-string value in practise will escape an > alphabetic letter (a-z). Not only would it be pointless for the sender to > do so, they would also be violating a "SHOULD NOT" in the spec. > > Senders SHOULD NOT escape octets in quoted-strings that do not > require escaping (i.e., other than DQUOTE and the backslash octet). > [draft-ietf-httpbis-p1-messaging-16#section-3.2.3] It still is a violation of the spec if you do so. >> If we were free to change things, we'd simply state that everything is >> UTF-8. > > But that would break things. > I am only suggesting changing the interpretation of \u because > I don't believe it will break any existing values. > > >> But that argument doesn't change the fact how it is defined. > > Changing defined behaviour is not great. > Changing defined behaviour that is *never used* (eg "\u" as an > escape sequence for "u") doesn't sound so unreasonable. Again, if you believe this is a good idea, the place to argue this is the HTTPbis WG, and not inventing something specific for OAuth. Best regards, Julian From stephen.farrell@cs.tcd.ie Tue Oct 11 05:59:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DCA21F8CF9 for ; Tue, 11 Oct 2011 05:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0eFnL-138Vi for ; Tue, 11 Oct 2011 05:59:23 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9259C21F8C00 for ; Tue, 11 Oct 2011 05:59:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 830CE171CF9 for ; Tue, 11 Oct 2011 13:59:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1318337956; bh=LbOkYMlLGFHnjh eBOFHPWRRDBsDMX2VxJVf+WcN4He4=; b=I0IBnyF4xykpV0NI++O6rvf3qMKGnU NMSxY3IbNkvMQHTb4bO29skwpajQnRrdG7/Tz+G0V4gzqYUYOYa/zHSr1n6P9GMF 70IIka/pPk3vlFzyEkb4ozR4mNOgK/yL+cjN+yz2Uoa2jZ+3WbUs/+3Yybo93dZp hlc2SenbkCxYw8d0srWrZBPiDUIPiznTcrnyiuvNPKEvWVKeNWwFEEr0Wa3AUCEm wZtYf2kxQ22OxxplIQiP6SnFM+emgmpyObL9/zU3ii7+kTpOqcj3FSoNGAgLhDxI vR5tpYkv5J9caybvmO5q/EOGbT8VY8SNY4L1qtVg4qMvkRWWf6tax2Lg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id n4Kycb9KOp1N for ; Tue, 11 Oct 2011 13:59:16 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 63436171C3F for ; Tue, 11 Oct 2011 13:59:16 +0100 (IST) Message-ID: <4E943D9A.8020104@cs.tcd.ie> Date: Tue, 11 Oct 2011 13:59:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "oauth@ietf.org" References: <38F4FD49-01F1-4ACF-B4B0-42C878B18E3A@cisco.com> In-Reply-To: <38F4FD49-01F1-4ACF-B4B0-42C878B18E3A@cisco.com> X-Forwarded-Message-Id: <38F4FD49-01F1-4ACF-B4B0-42C878B18E3A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Fwd: [Cfrg] Universally Composable Security Analysis of OAuth v2.0 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:59:24 -0000 FYI S. -------- Original Message -------- Subject: [Cfrg] Universally Composable Security Analysis of OAuth v2.0 Date: Tue, 11 Oct 2011 04:36:48 -0700 From: David McGrew To: cfrg@irtf.org Of possible interest: a security analysis of draft-ietf-oauth-v2-20 http://eprint.iacr.org/2011/526 _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From wmills@yahoo-inc.com Tue Oct 11 09:20:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFF421F858C for ; Tue, 11 Oct 2011 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.998 X-Spam-Level: X-Spam-Status: No, score=-14.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqjICJ6YSCsy for ; Tue, 11 Oct 2011 09:20:45 -0700 (PDT) Received: from nm27-vm0.bullet.mail.sp2.yahoo.com (nm27-vm0.bullet.mail.sp2.yahoo.com [98.139.91.232]) by ietfa.amsl.com (Postfix) with SMTP id 1FD8321F85AA for ; Tue, 11 Oct 2011 09:20:43 -0700 (PDT) Received: from [98.139.91.66] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 11 Oct 2011 16:20:42 -0000 Received: from [98.139.91.47] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 11 Oct 2011 16:20:42 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 11 Oct 2011 16:20:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 782480.34206.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 95851 invoked by uid 60001); 11 Oct 2011 16:20:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1318350042; bh=1b9rBmAyjFLOnGCTrVgldcz0pw3nEgZEP9Ql6tIDheM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=VV8/eHv+WNM0lnu1+1f3wIOFoPqP/WgzvQdcpeFmxa7mVK8mAxQuOxuxxVU+RsW0cUuJOSth/uG/1rJpCe06CVfe0GL5Ue1MC1RaQhhDqlNIzOdEjT8ef7Cq80EeMzzU/xZm6PyPge/rsjKXsAAHORtfF0MOf9de8Z3GsReLXq8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=AdQuYnIgKLbU1cUFDW5bl8VyDZr4DvoQdhbe/9B2HLfihviQeUKvAkPKxDKVWG5+UcdApmBXDCZZ9yXz8rXNSCWVxFHH5LGpW11MOCx5gTTldCJNFcFipiSBaJbFphYbKZ8LExZ8jHxTkSoeK/TUoSYQ4bUbeJAKma1I6kyBjsc=; X-YMail-OSG: rbOIYqEVM1mN_3LdzymRYCUUW4kBBiAeQnNm6apDqH9JTIH pvDll7S4.xuVikOo1Pc4DpuWu3kO8QNUd9t33DnP8tU_YTcwPn8Y5B7MVvU7 WW2oZETgkqDuEqjCRcRoeF.JMXzEtiBbPRiWDhaLw0Dq4.QDkpYnGzFPNFF1 B.sUtr131n43NItz1vHx9.o1CJ0ee1H2Z5LUZO0Mgl3LXfLnEEgw7DqisHux vK_yq95t03j4GoSbsheeI0TdD6WBa3a7I13xYatLvr8S2IbbAjRID78J4vKS 571DMRmEobgP.lI39KQjLO.FO9FyaXYEGOTsQivfi3RBWt_Z4pCvPzM3pvfD RBJzQ89jg8P5ZJYIIeCSw8f04t8_v6U9WSWNunma0x1lchPbsZbQYL6lq6BM qn083cp_tuncLer8o5C547cboE47bOxH2MyFTe1dOy3wRE2Il_.2s3ggjeLU 3GMwL Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Tue, 11 Oct 2011 09:20:42 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> Message-ID: <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 11 Oct 2011 09:20:42 -0700 (PDT) From: William Mills To: "Manger, James H" , "oauth@ietf.org" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-375954011-1318350042=:89721" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:20:46 -0000 --0-375954011-1318350042=:89721 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So where are we on this?=C2=A0 Any progress?=0A=0A=0A=0A___________________= _____________=0AFrom: "Manger, James H" = =0ATo: William J. Mills ; "oauth@ietf.org" =0ASent: Tuesday, August 30, 2011 11:39 PM=0ASubject: RE: [OAUTH-WG] = draft-ietf-oauth-v2-bearer-08.txt WGLC comments=0A=0A=0AWilliam J. Mills sa= id:=0A>Did item #2 below get resolved?=C2=A0 I haven't seen any more traffi= c about it and it seems pretty significant.=0A=C2=A0=0A=C2=A0=0ANo, I haven= =E2=80=99t seen any resolution for #2 (or any of these comments).=0AThe lat= est HTTPbis draft (http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16= ) has updated ABNF for and that supports the base= 64-blobs used by BASIC and NTLM. It does not allow what BEARER tries to do.= =0A=C2=A0=0A--=0AJames Manger=0A=C2=A0=0A=C2=A0=0A=0A______________________= __________=0A=0AFrom:"Manger, James H" =0A= To: "oauth@ietf.org" =0ASent: Thursday, July 28, 2011 8:51 = PM=0ASubject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments=0A= =0AMy working group last call comments on draft-ietf-oauth-v2-bearer-08.txt= :=0A=0A=0A1. Mentioning that this is an HTTP authentication mechanism in th= e title and/or abstract would be useful to the wider IETF (& beyond) audien= ce.=0ATitle:=0A=C2=A0 "The BEARER HTTP authentication mechanism for use wit= h OAuth 2"=0AAbstract:=0A=C2=A0 "This specification describes how to use be= arer tokens in=0A=C2=A0 HTTP requests to access OAuth 2 protected resources= ."=0A=0A[Personally, I wouldn't bother mentioning OAuth at all here, but ot= hers seem to want this context restriction.]=0A=0A=0A2. The ABNF for does not comply with RFC 2617 "HTTP Authentication". And even thoug= h RFC 2617 is broken is this aspect, the BEARER spec doesn't comply with th= e errata (still broken) or the more likely fixes proposed for HTTPbis [draf= t-ietf-httpbis-p7-auth].=0AI expect HTTPbis to allow a base64-like-blob con= sistently in Authorization and WWW-Authenticate headers (to accommodate BAS= IC and NTLM). Multiple WWW-Authenticate headers can have their values combi= ned, separated by commas. They can also have quoted-string parameters. To b= e able to parse this, requires disallowing commas and double-quotes from th= e base64-like-blob (and hence from ) at a minimum; only allow= ing equals at the end also helps.=0AThe current approach in the bearer spec= disallows all but 94 chars/bytes. I suggest reducing this to 69. Something= in between (eg 91 chars, dropping comma, quote, and slash) might work. Non= e of these options are materially easier than the others for a token issuer= ; and less symbols just means less risk of escaping problems elsewhere (eg = allowing "<" in an access token will wreck someone's XML somewhere, for no = benefit).=0A=0ASuggestion: =0A=C2=A0 access-token =3D 1*( ALPHA / DIGIT / "= -" / "." / "_" / "~" / "+" / "/" ) *"=3D"=0A=0A=C2=A0 includ= es the 66 unreserved URI characters plus a few others.=0A=C2=A0 It can hold= a base64, base64url (URL and filename safe alphabet),=0A=C2=A0 base32, or = base16 (hex) encoding, with or without padding, but=0A=C2=A0 excluding whit= espace [RFC4648].=0A=0A2b. If 2 is not accepted (and assuming HTTPbis will = allow any content after the scheme name in a Authorization header) can we p= lease not misuse the label when no quoting is going on. The f= ollowing is a better equivalent:=0A=0A=C2=A0 access-token =3D 1*(%x21-7E) ;= ASCII, except controls, space, or delete=0A=0A=0A3. Drop '\' from the allo= wed chars in a scope value, to avoid clashing with the HTTP quoted-string e= scaping mechanism (and don't use the label when no quoting is= going on).=0A=C2=A0 scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes spa= ce and " and \=0A=0A=0A4. Section 3.3 "Summary of Recommendations" sensibly= says clients "MUST ensure that bearer tokens are not leaked to *unintended= parties*" and correctly notes that this is "the primary security considera= tion" that underlies all the others. So it is a glaring hole that OAuth2 fa= ils to tell the client who the intended parties are when issuing a bearer t= oken.=0A=0A=0A--=0AJames Manger=0A_________________________________________= ______=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman= /listinfo/oauth --0-375954011-1318350042=:89721 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
So where are we on this?  Any progress?

From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: William J. Mills <wmills@= yahoo-inc.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, August 30, 2011 11:39 PM=
Subject: RE: [OAUTH-WG= ] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

=0A
William J. Mills said:
>Did item #2 below get resolved?  I haven't seen any= more traffic about it and it seems pretty significant.
<= div>
 
&n= bsp;
No, I haven=E2=80=99t seen any res= olution for #2 (or any of these comments).
The latest HTTPbis dra= ft (http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16) has updated A= BNF for <challenge> and <credentials> that supports the base64-= blobs used by BASIC and NTLM. It does not allow what BEARER tries to do.
=  
--
James Manger
 <= /div>
 
= From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "oauth@ietf= .org" <oauth@ietf.org>
Sent: Thursday, July 28, 2011 8:51 P= M
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comm= ents

My working group last call = comments on draft-ietf-oauth-v2-bearer-08.txt:


1. Mentioning tha= t this is an HTTP authentication mechanism in the title and/or abstract wou= ld be useful to the wider IETF (& beyond) audience.
Title:
 = "The BEARER HTTP authentication mechanism for use with OAuth 2"
Abstrac= t:
  "This specification describes how to use bearer tokens in
&= nbsp; HTTP requests to access OAuth 2 protected resources."

[Persona= lly, I wouldn't bother mentioning OAuth at all here, but others seem to wan= t this context restriction.]


2. The ABNF for <credentials>= does not comply with RFC 2617 "HTTP Authentication". And even though RFC 2617 is broken is this aspect, the BEARER spec doesn't comply with the= errata (still broken) or the more likely fixes proposed for HTTPbis [draft= -ietf-httpbis-p7-auth].
I expect HTTPbis to allow a base64-like-blob con= sistently in Authorization and WWW-Authenticate headers (to accommodate BAS= IC and NTLM). Multiple WWW-Authenticate headers can have their values combi= ned, separated by commas. They can also have quoted-string parameters. To b= e able to parse this, requires disallowing commas and double-quotes from th= e base64-like-blob (and hence from <access-token>) at a minimum; only= allowing equals at the end also helps.
The current approach in the bear= er spec disallows all but 94 chars/bytes. I suggest reducing this to 69. So= mething in between (eg 91 chars, dropping comma, quote, and slash) might wo= rk. None of these options are materially easier than the others for a token= issuer; and less symbols just means less risk of escaping problems elsewhere (eg allowing "<" in an access token will wreck someone's XML = somewhere, for no benefit).

Suggestion:
  access-token =3D = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=3D"

 = ; <access-token> includes the 66 unreserved URI characters plus a few= others.
  It can hold a base64, base64url (URL and filename safe a= lphabet),
  base32, or base16 (hex) encoding, with or without paddi= ng, but
  excluding whitespace [RFC4648].

2b. If 2 is not ac= cepted (and assuming HTTPbis will allow any content after the scheme name i= n a Authorization header) can we please not misuse the <quoted-char> = label when no quoting is going on. The following is a better equivalent:
  access-token =3D 1*(%x21-7E) ; ASCII, except controls, space, o= r delete


3. Drop '\' from the allowed chars in a scope value, to= avoid clashing with the HTTP quoted-string escaping mechanism (and don't use the <quoted-char> label when no quoting is going on).
  = scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " and \

4. Section 3.3 "Summary of Recommendations" sensibly says clients "MUS= T ensure that bearer tokens are not leaked to *unintended parties*" and cor= rectly notes that this is "the primary security consideration" that underli= es all the others. So it is a glaring hole that OAuth2 fails to tell the cl= ient who the intended parties are when issuing a bearer token.


-= -
James Manger
_______________________________________________
OAu= th mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--0-375954011-1318350042=:89721-- From James.H.Manger@team.telstra.com Tue Oct 11 17:07:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DEC21F8CCE for ; Tue, 11 Oct 2011 17:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=-0.256, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7w8LG8jJqsQ for ; Tue, 11 Oct 2011 17:07:02 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7741421F8C0C for ; Tue, 11 Oct 2011 17:07:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,526,1312120800"; d="scan'208,217";a="48282630" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Oct 2011 11:06:59 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6496"; a="39792852" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcani.tcif.telstra.com.au with ESMTP; 12 Oct 2011 11:06:59 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 12 Oct 2011 11:06:58 +1100 From: "Manger, James H" To: William Mills , "oauth@ietf.org" Date: Wed, 12 Oct 2011 11:06:57 +1100 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AcyIMbz/pD1K/+xISKG9vIYfi9i0rQAOTx5A Message-ID: <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> In-Reply-To: <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.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_255B9BB34FB7D647A506DC292726F6E1129072392AWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 00:07:03 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1129072392AWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gMi4gVGhlIEFCTkYgZm9yIDxjcmVkZW50aWFscz4gZG9lcyBub3QgY29tcGx5IHdpdGggUkZD IDI2MTcgIkhUVFAgQXV0aGVudGljYXRpb24iLg0KDQo+IFNvIHdoZXJlIGFyZSB3ZSBvbiB0aGlz PyAgQW55IHByb2dyZXNzPw0KDQpTb21lIHByb2dyZXNzLg0KZHJhZnQtaWV0Zi1vYXV0aC12Mi1i ZWFyZXItMDkgZGVmaW5lcyB0aGUg4oCcQXV0aG9yaXphdGlvbjogQmVhcmVyIC4uLuKAnSByZXF1 ZXN0IGhlYWRlciB0byBtYXRjaCBkcmFmdC1pZXRmLWh0dHBiaXMtcDctYXV0aC4gSXQgdXNlcyA8 YjY0dG9rZW4+IGZvciB0aGUgYWNjZXNzIHRva2VuLg0KVGhlIHNwZWMgaXMgbm90IHF1aXRlIHJp Z2h0IGFzIGl0IGFsc28gaW5jbHVkZXMgYSBjb21tYS1zZXBhcmF0ZWQgbGlzdCBvZiBuYW1lPXZh bHVlIHBhaXJzIDwjYXV0aC1wYXJhbT4gYXMgYW5vdGhlciBvcHRpb24gZm9yIHRoZSBoZWFkZXIs IHdpdGhvdXQgYW55IGhpbnQgYWJvdXQgaG93IHRoaXMgd29ya3MgZm9yIHRoZSBCZWFyZXIgc2No ZW1lLg0KDQpTdGlsbCB0byBkbzoNCkNoYW5nZQ0KY3JlZGVudGlhbHMgPSAiQmVhcmVyIiAxKlNQ ICggYjY0dG9rZW4gLyAjYXV0aC1wYXJhbSApDQp0bw0KY3JlZGVudGlhbHMgPSAiQmVhcmVyIiAx KlNQIGI2NHRva2VuDQpJdCB3b3VsZCBhbHNvIGJlIHdvcnRoIGV4cGxpY2l0bHkgc3RhdGluZyB0 aGUgcmVzdHJpY3Rpb25zIG9uIGFjY2VzcyB0b2tlbnMgdGhhdCB0aGUgQmVhcmVyIHNjaGVtZSBh cHBsaWVzIG92ZXIgd2hhdCBPQXV0aCBjb3JlIGFsbG93cywgd2hpY2ggaXMgYW55IFVuaWNvZGUg c3RyaW5nLiBUaGUgQmVhcmVyIHNwZWMgcmVxdWlyZXMgYW4gYWNjZXNzIHRva2VuIHRvIG1hdGNo IDxiNjR0b2tlbj4uIFRoaXMgZG9lcyBub3QgaGF2ZSB0byBiZSBiYXNlNjQgKG9yIGJhc2U2NHVy bCksIGJ1dCBpdCBjYW4gb25seSB1c2UgNjggQVNDSUkgY2hhcnMgKHBsdXMg4oCcPeKAneKAmXMg YXQgdGhlIGVuZCkuIFNlY3Rpb24gNC4xLjEg4oCcVGhlIOKAnEJlYXJlcuKAnSBPQXV0aCBBY2Nl c3MgVG9rZW4gVHlwZeKAnSBpcyBwcm9iYWJseSB0aGUgcGxhY2UgdG8gbWVudGlvbiB0aGUgcmVz dHJpY3Rpb25zLiBTdWdnZXN0ZWQgdGV4dDoNCg0KICDigJxXaGVuIHRoZSB0eXBlIGlzIOKAnGJl YXJlcuKAnSB0aGUg4oCcYWNjZXNzX3Rva2Vu4oCdIHZhbHVlIE1VU1QgbWF0Y2ggdGhlIDxiNjR0 b2tlbj4gQUJORiBbZHJhZnQtaWV0Zi1odHRwYmlzLXA3LWF1dGhdLCB3aGljaCBhbGxvd3MgdGhl IDY2IHVucmVzZXJ2ZWQgVVJJIGNoYXJhY3RlcnMgcGx1cyBhIGZldyBvdGhlcnMgc28gaXQgY2Fu IGhvbGQgYSBiYXNlNjQgb3IgYmFzZTY0dXJsIGVuY29kaW5nIFtSRkM0NjQ4XS4gVXNpbmcgYSBi YXNlNjR1cmwgZW5jb2Rpbmcgd2l0aG91dCBwYWRkaW5nIChvciBhIGZldyBiYXNlNjR1cmwgZW5j b2RlZCBpdGVtcyBzZXBhcmF0ZWQgYnkgZG90cykgaXMgUkVDT01NRU5ERUQgYXMgaXQgYXZvaWRz IHRoZSBuZWVkIGZvciBhbnkgZXNjYXBpbmcgaW4gbW9zdCBzaXR1YXRpb25zLuKAnQ0KDQpQcm9i YWJseSBuZWVkIHRvIGFkZCBSRkMgNDY0OCDigJxUaGUgQmFzZTE2LCBCYXNlMzIsIGFuZCBCYXNl NjQgRGF0YSBFbmNvZGluZ3PigJ0gYXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIGlmIGluY2x1 ZGluZyB0aGlzIHN1Z2dlc3RlZCB0ZXh0Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= --_000_255B9BB34FB7D647A506DC292726F6E1129072392AWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29u c29sYXMiLCJzZXJpZiI7fQ0KcC55aXYyNjc2MTQ1Mjltc29ub3JtYWwsIGxpLnlpdjI2NzYxNDUy OW1zb25vcm1hbCwgZGl2LnlpdjI2NzYxNDUyOW1zb25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5 aXYyNjc2MTQ1Mjltc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnAueWl2MjY3NjE0NTI5bXNvY2hwZGVmYXVsdCwgbGkueWl2MjY3NjE0NTI5bXNv Y2hwZGVmYXVsdCwgZGl2LnlpdjI2NzYxNDUyOW1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5h bWU6eWl2MjY3NjE0NTI5bXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYyNjc2MTQ1Mjltc29oeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLW5hbWU6eWl2MjY3NjE0NTI5bXNvaHlwZXJsaW5rO30NCnNwYW4ueWl2MjY3NjE0NTI5bXNv aHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY3NjE0NTI5bXNvaHlwZXJs aW5rZm9sbG93ZWQ7fQ0Kc3Bhbi55aXYyNjc2MTQ1MjllbWFpbHN0eWxlMTcNCgl7bXNvLXN0eWxl LW5hbWU6eWl2MjY3NjE0NTI5ZW1haWxzdHlsZTE3O30NCnNwYW4ueWl2MjY3NjE0NTI5aHRtbHBy ZWZvcm1hdHRlZGNoYXINCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjY3NjE0NTI5aHRtbHByZWZvcm1h dHRlZGNoYXI7fQ0KcC55aXYyNjc2MTQ1Mjltc29ub3JtYWwxLCBsaS55aXYyNjc2MTQ1Mjltc29u b3JtYWwxLCBkaXYueWl2MjY3NjE0NTI5bXNvbm9ybWFsMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYy Njc2MTQ1Mjltc29ub3JtYWwxOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLnlpdjI2NzYxNDUyOW1zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MjY3NjE0NTI5bXNvaHlwZXJsaW5rMTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYyNjc2MTQ1Mjltc29oeXBlcmxpbmtmb2xsb3dlZDENCgl7 bXNvLXN0eWxlLW5hbWU6eWl2MjY3NjE0NTI5bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueWl2MjY3NjE0NTI5 ZW1haWxzdHlsZTE3MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyNjc2MTQ1MjllbWFpbHN0eWxlMTcx Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi55aXYyNjc2MTQ1MjlodG1scHJlZm9ybWF0dGVkY2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6 eWl2MjY3NjE0NTI5aHRtbHByZWZvcm1hdHRlZGNoYXIxOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KcC55aXYyNjc2MTQ1Mjltc29jaHBkZWZhdWx0MSwgbGkueWl2MjY3NjE0NTI5bXNv Y2hwZGVmYXVsdDEsIGRpdi55aXYyNjc2MTQ1Mjltc29jaHBkZWZhdWx0MQ0KCXttc28tc3R5bGUt bmFtZTp5aXYyNjc2MTQ1Mjltc29jaHBkZWZhdWx0MTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjU1ODY3ODU5Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQ5Njk0MjM3MCAzMDAwNDg5ODAgMjAx OTE2NDE5IDIwMTkxNjQyMSAyMDE5MTY0MTcgMjAxOTE2NDE5IDIwMTkxNjQyMSAyMDE5MTY0MTcg MjAxOTE2NDE5IDIwMTkxNjQyMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZs aW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7Jmd0OyAyLiBUaGUgQUJORiBmb3IgJmx0 O2NyZWRlbnRpYWxzJmd0OyBkb2VzIG5vdCBjb21wbHkgd2l0aCBSRkMgMjYxNyAmcXVvdDtIVFRQ IEF1dGhlbnRpY2F0aW9uJnF1b3Q7Ljwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDoz Ni4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6YmxhY2snPiZndDsgU28gd2hlcmUgYXJlIHdlIG9uIHRoaXM/Jm5ic3A7IEFu eSBwcm9ncmVzcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvbWUgcHJvZ3Jlc3MuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPmRyYWZ0 LWlldGYtb2F1dGgtdjItYmVhcmVyLTA5IGRlZmluZXMgdGhlIOKAnEF1dGhvcml6YXRpb246IEJl YXJlciAuLi7igJ0gcmVxdWVzdCBoZWFkZXIgdG8gbWF0Y2ggZHJhZnQtaWV0Zi1odHRwYmlzLXA3 LWF1dGguIEl0IHVzZXMgJmx0O2I2NHRva2VuJmd0OyBmb3IgdGhlIGFjY2VzcyB0b2tlbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+VGhlIHNwZWMgaXMgbm90IHF1aXRlIHJpZ2h0IGFzIGl0IGFsc28gaW5jbHVkZXMgYSBjb21t YS1zZXBhcmF0ZWQgbGlzdCBvZiBuYW1lPXZhbHVlIHBhaXJzICZsdDsjYXV0aC1wYXJhbSZndDsg YXMgYW5vdGhlciBvcHRpb24gZm9yIHRoZSBoZWFkZXIsIHdpdGhvdXQgYW55IGhpbnQgYWJvdXQg aG93IHRoaXMgd29ya3MgZm9yIHRoZSBCZWFyZXIgc2NoZW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ U3RpbGwgdG8gZG86PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkNoYW5nZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPmNyZWRlbnRpYWxzID0gJnF1b3Q7 QmVhcmVyJnF1b3Q7IDEqU1AgKCBiNjR0b2tlbiAvICNhdXRoLXBhcmFtICk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+dG88bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y OmJsYWNrJz5jcmVkZW50aWFscyA9ICZxdW90O0JlYXJlciZxdW90OyAxKlNQIGI2NHRva2VuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SXQgd291bGQgYWxzbyBiZSB3b3J0aCBleHBsaWNpdGx5IHN0YXRpbmcgdGhl IHJlc3RyaWN0aW9ucyBvbiBhY2Nlc3MgdG9rZW5zIHRoYXQgdGhlIEJlYXJlciBzY2hlbWUgYXBw bGllcyBvdmVyIHdoYXQgT0F1dGggY29yZSBhbGxvd3MsIHdoaWNoIGlzIGFueSBVbmljb2RlIHN0 cmluZy4gVGhlIEJlYXJlciBzcGVjIHJlcXVpcmVzIGFuIGFjY2VzcyB0b2tlbiB0byBtYXRjaCAm bHQ7YjY0dG9rZW4mZ3Q7LiBUaGlzIGRvZXMgbm90IGhhdmUgdG8gYmUgYmFzZTY0IChvciBiYXNl NjR1cmwpLCBidXQgaXQgY2FuIG9ubHkgdXNlIDY4IEFTQ0lJIGNoYXJzIChwbHVzIOKAnD3igJ3i gJlzIGF0IHRoZSBlbmQpLiBTZWN0aW9uIDQuMS4xIOKAnFRoZSDigJxCZWFyZXLigJ0gT0F1dGgg QWNjZXNzIFRva2VuIFR5cGXigJ0gaXMgcHJvYmFibHkgdGhlIHBsYWNlIHRvIG1lbnRpb24gdGhl IHJlc3RyaWN0aW9ucy4gU3VnZ2VzdGVkIHRleHQ6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoCDigJxX aGVuIHRoZSB0eXBlIGlzIOKAnGJlYXJlcuKAnSB0aGUg4oCcYWNjZXNzX3Rva2Vu4oCdIHZhbHVl IE1VU1QgbWF0Y2ggdGhlICZsdDtiNjR0b2tlbiZndDsgQUJORiBbZHJhZnQtaWV0Zi1odHRwYmlz LXA3LWF1dGhdLCB3aGljaCBhbGxvd3MgdGhlIDY2IHVucmVzZXJ2ZWQgVVJJIGNoYXJhY3RlcnMg cGx1cyBhIGZldyBvdGhlcnMgc28gaXQgY2FuIGhvbGQgYSBiYXNlNjQgb3IgYmFzZTY0dXJsIGVu Y29kaW5nIFtSRkM0NjQ4XS4gVXNpbmcgYSBiYXNlNjR1cmwgZW5jb2Rpbmcgd2l0aG91dCBwYWRk aW5nIChvciBhIGZldyBiYXNlNjR1cmwgZW5jb2RlZCBpdGVtcyBzZXBhcmF0ZWQgYnkgZG90cykg aXMgUkVDT01NRU5ERUQgYXMgaXQgYXZvaWRzIHRoZSBuZWVkIGZvciBhbnkgZXNjYXBpbmcgaW4g bW9zdCBzaXR1YXRpb25zLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UHJvYmFibHkgbmVlZCB0byBh ZGQgUkZDIDQ2NDgg4oCcVGhlIEJhc2UxNiwgQmFzZTMyLCBhbmQgQmFzZTY0IERhdGEgRW5jb2Rp bmdz4oCdIGFzIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSBpZiBpbmNsdWRpbmcgdGhpcyBzdWdn ZXN0ZWQgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2Vy PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E1129072392AWSMSG3153Vsrv_-- From julian.reschke@gmx.de Wed Oct 12 02:21:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FA321F8C2D for ; Wed, 12 Oct 2011 02:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCZqxJaJs6iM for ; Wed, 12 Oct 2011 02:21:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D65CF21F8C14 for ; Wed, 12 Oct 2011 02:21:19 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2011 09:21:17 -0000 Received: from p5DCCADB0.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.173.176] by mail.gmx.net (mp056) with SMTP; 12 Oct 2011 11:21:17 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Q4CprEMmQWPwcaNwq+tXWCGnqaRhnN2DW5HjVEe k29jnWr9GI1gA8 Message-ID: <4E955C01.40603@gmx.de> Date: Wed, 12 Oct 2011 11:21:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 09:21:20 -0000 On 2011-10-12 02:06, Manger, James H wrote: >> > 2. The ABNF for does not comply with RFC 2617 "HTTP > Authentication". > >> So where are we on this? Any progress? > > Some progress. > > draft-ietf-oauth-v2-bearer-09 defines the “Authorization: Bearer ...” > request header to match draft-ietf-httpbis-p7-auth. It uses > for the access token. > > The spec is not quite right as it also includes a comma-separated list > of name=value pairs <#auth-param> as another option for the header, > without any hint about how this works for the Bearer scheme. > > Still to do: > > Change > > credentials = "Bearer" 1*SP ( b64token / #auth-param ) > > to > > credentials = "Bearer" 1*SP b64token > ... I'd like to point out that we added b64token in HTTPbis in order to grandfather Basic and Digest; it's really not designed for new schemes. says: "The "b64token" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge/credentials. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions will be impossible." So be aware that by choosing b64token, you are closing the door for any kind of extensibility here. (Note that this isn't a matter of taste, but directly follows from syntax requirements for parsing the header field) Best regards, Julian From Michael.Jones@microsoft.com Wed Oct 12 07:32:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA56C21F8B8B for ; Wed, 12 Oct 2011 07:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orc2Q0n7svpg for ; Wed, 12 Oct 2011 07:32:31 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCD021F8B91 for ; Wed, 12 Oct 2011 07:32:31 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Oct 2011 07:32:25 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Wed, 12 Oct 2011 07:32:25 -0700 From: Mike Jones To: Julian Reschke , "Manger, James H" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AQHMTaLJnWCrafb4ZE+NLLSMK5FwXJU3E+0AgAAXvQCAQRHaAIAAgkWAgACa04D//+FBcA== Date: Wed, 12 Oct 2011 14:32:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> In-Reply-To: <4E955C01.40603@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:32:31 -0000 Draft 09 allows either b64token or auth-params. Unless there's a working g= roup consensus that this must change, both syntax options will be supported= . -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Wednesday, October 12, 2011 2:21 AM To: Manger, James H Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments On 2011-10-12 02:06, Manger, James H wrote: >> > 2. The ABNF for does not comply with RFC 2617 "HTTP > Authentication". > >> So where are we on this? Any progress? > > Some progress. > > draft-ietf-oauth-v2-bearer-09 defines the "Authorization: Bearer ..." > request header to match draft-ietf-httpbis-p7-auth. It uses =20 > for the access token. > > The spec is not quite right as it also includes a comma-separated list=20 > of name=3Dvalue pairs <#auth-param> as another option for the header,=20 > without any hint about how this works for the Bearer scheme. > > Still to do: > > Change > > credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) > > to > > credentials =3D "Bearer" 1*SP b64token > ... I'd like to point out that we added b64token in HTTPbis in order to grandfa= ther Basic and Digest; it's really not designed for new schemes. says: "The "b64token" notation was introduced for compatibility with existing aut= hentication schemes and can only be used once per challenge/credentials. Ne= w schemes thus ought to use the "auth-param"=20 syntax instead, because otherwise future extensions will be impossible." So be aware that by choosing b64token, you are closing the door for any kin= d of extensibility here. (Note that this isn't a matter of taste, but direc= tly follows from syntax requirements for parsing the header field) Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Wed Oct 12 07:52:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399C421F8BC5 for ; Wed, 12 Oct 2011 07:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKvOMZCEltmE for ; Wed, 12 Oct 2011 07:52:00 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4638F21F8BC4 for ; Wed, 12 Oct 2011 07:51:59 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2011 14:51:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp047) with SMTP; 12 Oct 2011 16:51:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+vaWwTRVGv6Q4sp14WWW7sfKlzBr85DoHLubrei8 2H3Cg3l1NEIbpC Message-ID: <4E95A987.1000203@gmx.de> Date: Wed, 12 Oct 2011 16:51:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:52:01 -0000 On 2011-10-12 16:32, Mike Jones wrote: > Draft 09 allows either b64token or auth-params. Unless there's a working group consensus that this must change, both syntax options will be supported. > > -- Mike > ... Mike, that doesn't work. The restriction in HTTPbis is there because it's necessary so a recipient can parse a header field that contains multiple, comma-separated challenges. If you think that HTTPbis is wrong here please come over to the HTTPbis mailing list and argue your point. Best regards, Julian From Michael.Jones@microsoft.com Wed Oct 12 11:02:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6178F21F8BEF for ; Wed, 12 Oct 2011 11:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64fMahsHvcYP for ; Wed, 12 Oct 2011 11:02:13 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id E85E721F8BDE for ; Wed, 12 Oct 2011 11:02:12 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Oct 2011 11:02:12 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0339.002; Wed, 12 Oct 2011 11:02:11 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AQHMTaLJnWCrafb4ZE+NLLSMK5FwXJU3E+0AgAAXvQCAQRHaAIAAgkWAgACa04D//+FBcIAAeymA//+/OLA= Date: Wed, 12 Oct 2011 18:02:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> In-Reply-To: <4E95A987.1000203@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:02:13 -0000 The syntax in HTTPbis is: credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ] The syntax in Bearer 09 is: credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) As this conforms to HTTPbis, I don't see a problem. I think HTTPbis and Be= arer are both fine as-is. -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Wednesday, October 12, 2011 7:52 AM To: Mike Jones Cc: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments On 2011-10-12 16:32, Mike Jones wrote: > Draft 09 allows either b64token or auth-params. Unless there's a working= group consensus that this must change, both syntax options will be support= ed. > > -- Mike > ... Mike, that doesn't work. The restriction in HTTPbis is there because it's necessa= ry so a recipient can parse a header field that contains multiple, comma-se= parated challenges. If you think that HTTPbis is wrong here please come over to the HTTPbis mai= ling list and argue your point. Best regards, Julian From julian.reschke@gmx.de Wed Oct 12 11:24:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1CA21F8CA0 for ; Wed, 12 Oct 2011 11:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.849 X-Spam-Level: X-Spam-Status: No, score=-104.849 tagged_above=-999 required=5 tests=[AWL=-2.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyjlvbW-pcD1 for ; Wed, 12 Oct 2011 11:24:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id F158921F8C9F for ; Wed, 12 Oct 2011 11:24:03 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2011 18:24:00 -0000 Received: from p5DCC9E25.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.158.37] by mail.gmx.net (mp046) with SMTP; 12 Oct 2011 20:24:00 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1873s4hHyw7Up+UKjA+mHcERAC0exITTZ7QbPW3RL ACnJyc/42VgJCz Message-ID: <4E95DB3B.2040802@gmx.de> Date: Wed, 12 Oct 2011 20:23:55 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:24:05 -0000 On 2011-10-12 20:02, Mike Jones wrote: > The syntax in HTTPbis is: > credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ] > > The syntax in Bearer 09 is: > credentials = "Bearer" 1*SP ( b64token / #auth-param ) > > As this conforms to HTTPbis, I don't see a problem. I think HTTPbis and Bearer are both fine as-is. The intent is that a scheme uses one of the two constructs, not both. Bearer can't use auth-params and b64tokens in the same challenge, so it's unclear to me how this is supposed to work. If you have a notation where you can express the bearer token as auth-param then why don't you *always* use it and get rid of the b64token construct? Best regards, Julian From Michael.Jones@microsoft.com Wed Oct 12 11:26:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C333D21F8B58 for ; Wed, 12 Oct 2011 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJrNh7kTA9of for ; Wed, 12 Oct 2011 11:26:39 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 503CE21F8AD2 for ; Wed, 12 Oct 2011 11:26:39 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Oct 2011 11:26:39 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Wed, 12 Oct 2011 11:26:38 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AQHMTaLJnWCrafb4ZE+NLLSMK5FwXJU3E+0AgAAXvQCAQRHaAIAAgkWAgACa04D//+FBcIAAeymA//+/OLCAAHwIgP//izlw Date: Wed, 12 Oct 2011 18:26:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> In-Reply-To: <4E95DB3B.2040802@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:26:39 -0000 Because b64token is existing practice -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Wednesday, October 12, 2011 11:24 AM To: Mike Jones Cc: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments On 2011-10-12 20:02, Mike Jones wrote: > The syntax in HTTPbis is: > credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ] > > The syntax in Bearer 09 is: > credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) > > As this conforms to HTTPbis, I don't see a problem. I think HTTPbis and = Bearer are both fine as-is. The intent is that a scheme uses one of the two constructs, not both. Bearer can't use auth-params and b64tokens in the same challenge, so it's u= nclear to me how this is supposed to work. If you have a notation where you can express the bearer token as auth-param= then why don't you *always* use it and get rid of the b64token construct? Best regards, Julian From julian.reschke@gmx.de Wed Oct 12 11:35:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16CC21F8B6C for ; Wed, 12 Oct 2011 11:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.399 X-Spam-Level: X-Spam-Status: No, score=-104.399 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm+iGdZB-Tvy for ; Wed, 12 Oct 2011 11:35:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0427121F8B1A for ; Wed, 12 Oct 2011 11:35:22 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2011 18:35:21 -0000 Received: from p5DCC9E25.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.158.37] by mail.gmx.net (mp065) with SMTP; 12 Oct 2011 20:35:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+2ECkqnCm2IF+M+dsSs8TYBTUr8yHIMVIr/fGB+o urOieb2qB2C8xJ Message-ID: <4E95DDE6.3080502@gmx.de> Date: Wed, 12 Oct 2011 20:35:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:35:24 -0000 On 2011-10-12 20:26, Mike Jones wrote: > Because b64token is existing practice > ... Anyway, how do you then send credentials that include the bearer token plus additional parameters? Example, please. Best regards, Julian From Michael.Jones@microsoft.com Wed Oct 12 11:39:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D470621F8CEC for ; Wed, 12 Oct 2011 11:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbsqixNIgLLN for ; Wed, 12 Oct 2011 11:39:07 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id E6B6A21F8CBD for ; Wed, 12 Oct 2011 11:39:06 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Oct 2011 11:39:06 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0339.002; Wed, 12 Oct 2011 11:39:06 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AQHMTaLJnWCrafb4ZE+NLLSMK5FwXJU3E+0AgAAXvQCAQRHaAIAAgkWAgACa04D//+FBcIAAeymA//+/OLCAAHwIgP//izlwAA7+tgAADp6n8A== Date: Wed, 12 Oct 2011 18:39:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DDE6.3080502@gmx.de> In-Reply-To: <4E95DDE6.3080502@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:39:07 -0000 One possible syntax is: Bearer access_token=3Dxyz_-123,more_info=3Dpdq Ultimately though, the format of the bearer token is outside of the scope o= f the spec, and up to the participants to determine, including whether to u= se b64token syntax or params syntax. -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Wednesday, October 12, 2011 11:35 AM To: Mike Jones Cc: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments On 2011-10-12 20:26, Mike Jones wrote: > Because b64token is existing practice > ... Anyway, how do you then send credentials that include the bearer token plus= additional parameters? Example, please. Best regards, Julian From eran@hueniverse.com Wed Oct 12 11:48:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38EE21F8B81 for ; Wed, 12 Oct 2011 11:48:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZNIgz3tI2ps for ; Wed, 12 Oct 2011 11:48:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 4133621F8B73 for ; Wed, 12 Oct 2011 11:48:37 -0700 (PDT) Received: (qmail 29718 invoked from network); 12 Oct 2011 18:48:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Oct 2011 18:48:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 12 Oct 2011 11:48:21 -0700 From: Eran Hammer-Lahav To: Mike Jones , Julian Reschke Date: Wed, 12 Oct 2011 11:48:00 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AQHMTaLJnWCrafb4ZE+NLLSMK5FwXJU3E+0AgAAXvQCAQRHaAIAAgkWAgACa04D//+FBcIAAeymA//+/OLCAAHwIgP//izlwAA7+tgAADp6n8AAc3x3g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452604B8BEE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DDE6.3080502@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond.corp.microsoft.com> 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@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:48:37 -0000 Not that I will ever use this, but this is really broken way to create a pr= otocol. Now is the time to make hard choices and pick one format. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Wednesday, October 12, 2011 11:39 AM > To: Julian Reschke > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC > comments >=20 > One possible syntax is: >=20 > Bearer access_token=3Dxyz_-123,more_info=3Dpdq >=20 > Ultimately though, the format of the bearer token is outside of the scope= of > the spec, and up to the participants to determine, including whether to u= se > b64token syntax or params syntax. >=20 > -- Mike >=20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, October 12, 2011 11:35 AM > To: Mike Jones > Cc: Manger, James H; oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC > comments >=20 > On 2011-10-12 20:26, Mike Jones wrote: > > Because b64token is existing practice > > ... >=20 > >=20 > Anyway, how do you then send credentials that include the bearer token > plus additional parameters? Example, please. >=20 > Best regards, Julian >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Wed Oct 12 12:56:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD3A21F8B04 for ; Wed, 12 Oct 2011 12:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.298 X-Spam-Level: X-Spam-Status: No, score=-16.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaFtyhYMcz6X for ; Wed, 12 Oct 2011 12:56:25 -0700 (PDT) Received: from nm30-vm3.bullet.mail.ne1.yahoo.com (nm30-vm3.bullet.mail.ne1.yahoo.com [98.138.91.160]) by ietfa.amsl.com (Postfix) with SMTP id 6B51F21F86EE for ; Wed, 12 Oct 2011 12:56:25 -0700 (PDT) Received: from [98.138.90.53] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 12 Oct 2011 19:56:22 -0000 Received: from [98.138.89.170] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 12 Oct 2011 19:56:22 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 12 Oct 2011 19:56:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 160528.24980.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 89580 invoked by uid 60001); 12 Oct 2011 19:56:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1318449381; bh=B0wBt7XwN/EORz7OzxDc1RGHq5h8S0snji1e0ILqy+o=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DYbpvknAzoej2W+RxDUrL4l/ZaMi8LbwLh6jgcK4hIuh8ztqDbfJSZvxb2BlkuuEi3+kzkpIT1cL2uhbOZZUUU/UrqN+cDRz5CHPCjgYzNpNleDX4uLOQmA39unB4LwSBsnWuF+CZFJLdOGVUDiLjdox4qxJu4b2gPXHlL+IkCs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ftOOyEaby0CPTC0d1IRv0x4EAvG5ulM8rsTaDsWzH4+uwjvh1eYzleQ8g+3PdYVUyrwFx0bIEj8VfnpVjMkSHEMgybhsoOZzwfS1Emjn49YEaAan7QDbp12NC48VtnmCC2zxclUUXE6cK4YohWchg43rB50M+ykbvIfh+iJ83kM=; X-YMail-OSG: OgqgehYVM1kpqTIvXag9q8PPNlVXXcWa05.OamR64PkcDMZ O6j8ZYEq0RCl7TrgzAJGdLxv7c4epRqz_7Yq_xUEcwFbZBxSuu0IdZBOMPVJ gO28ZaoK0kX4tm6h7zSt8e_AzOj54pvpqoV5.yQMVBN2PNELgOg9zYRgPERI 2Q8Rd_nuka6pSOVmQt_D3WqC8ZmEeLhpc7NtyFxLnCKpvRZ.sZtAia125tpi sY0B1Z7CDg_F3NdEpqXLbe7VrirryfIh9b6YMYT8YJe_su7uw2WxrT.x5BP9 EXFcI5.GKQNSLr47ubM2NsZ39a4L6xv7.5LJ0pjNr9fhVn0Mx6VBlEyiWEdR ayA5aw6sP_TD5YpDFS7f0lEHJ932cs5WB_59Red46oXcMSj.5xf9Ym5wwClx 5W5oJmJRDsukYyzuF8C3M00VEkwq1.Y4A Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Wed, 12 Oct 2011 12:56:21 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DDE6.3080502@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond. corp.microsoft.com> Message-ID: <1318449381.27454.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Wed, 12 Oct 2011 12:56:21 -0700 (PDT) From: William Mills To: Mike Jones , Julian Reschke In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-535856729-1318449381=:27454" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 19:56:26 -0000 --0-535856729-1318449381=:27454 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have suggested before, and I will reiterate that we should define explici= tly how to transport the token in an extensible way if extensions are desir= ed.=A0 I think we shoudl allow both of:=0A=0A=A0=A0=A0 Bearer b64token=0A= =0Aand =0A=0A=0A=A0=A0=A0 Bearer token=3D=0A=0A=0AThe first = ensures compatibility with extant implementation, and the second provides d= efinition for the basics where people want to extend it.=0A=0A-bill=0A=0A= =0A=0A________________________________=0AFrom: Mike Jones =0ATo: Julian Reschke =0ACc: "oauth@ietf= .org" =0ASent: Wednesday, October 12, 2011 11:39 AM=0ASubje= ct: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments=0A=0AOne= possible syntax is:=0A=0ABearer access_token=3Dxyz_-123,more_info=3Dpdq=0A= =0AUltimately though, the format of the bearer token is outside of the scop= e of the spec, and up to the participants to determine, including whether t= o use b64token syntax or params syntax.=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 -- Mike=0A=0A-----Original Message-----=0AFrom: Julian Reschke [m= ailto:julian.reschke@gmx.de] =0ASent: Wednesday, October 12, 2011 11:35 AM= =0ATo: Mike Jones=0ACc: Manger, James H; oauth@ietf.org=0ASubject: Re: [OAU= TH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments=0A=0AOn 2011-10-12 2= 0:26, Mike Jones wrote:=0A> Because b64token is existing practice=0A> ...= =0A=0A=0A=0AAnyway, = how do you then send credentials that include the bearer token plus additio= nal parameters? Example, please.=0A=0ABest regards, Julian=0A=0A___________= ____________________________________=0AOAuth mailing list=0AOAuth@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-535856729-1318449381=:27454 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I have suggested before, and I will reiterate that we should define expli= citly how to transport the token in an extensible way if extensions are des= ired.  I think we shoudl allow both of:

    Bearer b64token
<= br>
and

    Bearer token=3D<quoted string>

The first ensures compatibility with extant im= plementation, and the second provides definition for the basics where peopl= e want to extend it.

-bill

From: Mike Jones <Mich= ael.Jones@microsoft.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "oauth@ietf.org" <oauth@ietf.org><= br>Sent: Wednesday, Octobe= r 12, 2011 11:39 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

=0AOne possible syntax is:

Bearer access_token=3Dxyz_-123,mo= re_info=3Dpdq

Ultimately though, the format of the bearer token is o= utside of the scope of the spec, and up to the participants to determine, i= ncluding whether to use b64token syntax or params syntax.

 &nbs= p;              -- Mike
-----Original Message-----
From: Julian Reschke [mailto:jul= ian.reschke@gmx.de]
Sent: Wednesday, October 12, 2011 11:35 AM
T= o: Mike Jones
Cc: Manger, James H; oauth@ietf.org
Subject: Re: [OAUTH-WG= ] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

On 2011-10-12 20:2= 6, Mike Jones wrote:
> Because b64token is existing practice
>= ...

<include-disclaimer-about-maturity-of-internet-drafts/>
Anyway, how do you then send credentials that include the bearer token plus additi= onal parameters? Example, please.

Best regards, Julian

______= _________________________________________
OAuth mailing list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/oauth


--0-535856729-1318449381=:27454-- From James.H.Manger@team.telstra.com Wed Oct 12 17:38:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9CE21F8ACA for ; Wed, 12 Oct 2011 17:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.029 X-Spam-Level: X-Spam-Status: No, score=-1.029 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raOcXRvJdpV0 for ; Wed, 12 Oct 2011 17:38:23 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 874CB21F8A71 for ; Wed, 12 Oct 2011 17:38:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,337,1315144800"; d="scan'208";a="48771770" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 13 Oct 2011 11:38:19 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6497"; a="39036365" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 13 Oct 2011 11:38:19 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 13 Oct 2011 11:38:19 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Thu, 13 Oct 2011 11:38:17 +1100 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AQHMTaLJnWCrafb4ZE+NLLSMK5FwXJU3E+0AgAAXvQCAQRHaAIAAgkWAgACa04D//+FBcIAAeymA//+/OLCAAHwIgP//izlwAA7+tgAADp6n8AAU1rog Message-ID: <255B9BB34FB7D647A506DC292726F6E112907A695F@WSMSG3153V.srv.dir.telstra.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DDE6.3080502@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond.corp.microsoft.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 00:38:24 -0000 > One possible syntax is: > > Bearer access_token=3Dxyz_-123,more_info=3Dpdq > > Ultimately though, the format of the bearer token is outside of the scope= of the spec, and up to the participants to determine, including whether to= use b64token syntax or params syntax. It is great to see an example explaining the intention of the "b64token / #= auth-param" part of the draft. These details need to be in the spec. Draft = 9 makes no mention of an "access_token" parameter for the HTTP header -- in= sharp contrast to mentioning such a parameter for the URI query string and= POST body mechanisms. Can the "access_token" value be a (as in the= above example)? Can it be a ? Can it use RFC5987 (eg access= _token*=3DUTF-8''...)? Can a client choose the b64token or auth-param option, implying servers MUS= T support both? Or is it the other way around: servers only have to support= b64token so existing servers are compliant without requiring any changes? I thought the consensus was that bearer tokens were so simple that "Bearer = " was sufficient. In the unlikely event that more parameters were= required in future, a new scheme (eg Bearer2) could be defined. If this is= no longer the consensus then lets: 1. Define a single syntax that servers MUST support. Authorization: Bearer a=3D"" 2. Use a short parameter name, such as "a", saving 10-bytes per request ove= r "access_token". The long name is needed in a URI query string or POST bod= y so the parameter is unambiguous amongst any number of other application-s= pecific parameters. In a Bearer HTTP header there is no such possibility of= confusion. 3. Don't allow the value to be either a or -- just = pick one (I suggest ). It doesn't help developers or interop= to offer a pointless choice. 4. Allow future comma-separated parameters, and state that unrecognized par= ameters MUST be ignored. 5. Add an informative note that some servers might also accept a header of = the form "Bearer ", but clients using this form are not compl= iant to this spec. 6. Explicitly state that when the type is "bearer" in an OAuth2 token respo= nse, the "access_token" MUST only consist of characters that can be represe= nted in a , ie %x20-7E (assuming was picked = at #3). 7. Recommend that a base64url encoding without padding (of binary data or o= f UTF-8 encoded text) is a good choice for an "access_token" value (or a fe= w base64url encoded segments separated by dots) as it avoids the need to es= cape characters in most situations. -- James Manger From mscurtescu@google.com Wed Oct 12 18:38:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9232C21F8B03 for ; Wed, 12 Oct 2011 18:38:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrnnguC0Vyg7 for ; Wed, 12 Oct 2011 18:38:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B394821F8AF9 for ; Wed, 12 Oct 2011 18:38:03 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p9D1bvQM025339 for ; Wed, 12 Oct 2011 18:37:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318469877; bh=4BwZuGjX0qO8rTwZoM0enfWVGnw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=j3cteLRG7muZMlr5jl5zBDT/RscofK5r2o82h3DrfyxbuDuhelLle9IWNKNHsPb25 nMEN/kKytezy8B+PJPeUQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=sRxIQ4F1pjtDuLg4opwNlhQe0PUY+Yhpbqmwd/brOK8I3sDDoYpgZiQwvKSxs3IRU d4bUAhbqO1fM9oGSwWbGQ== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by hpaq13.eem.corp.google.com with ESMTP id p9D1VhuV007973 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 12 Oct 2011 18:37:55 -0700 Received: by gyg4 with SMTP id 4so2104261gyg.1 for ; Wed, 12 Oct 2011 18:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Pqh+AJcpdGdgvjhnRHp/1iMRK6tE88QvlXdSErESFkc=; b=RrKpx0xeWB//sDyYHZxEwQvgigePGJec/CtYNyqb5Ur8L1KIIdkUAK9EvrXzI5U4js Sz4TWDbhVDZJuymmQvVQ== Received: by 10.101.197.39 with SMTP id z39mr253533anp.167.1318469875475; Wed, 12 Oct 2011 18:37:55 -0700 (PDT) Received: by 10.101.197.39 with SMTP id z39mr253529anp.167.1318469875316; Wed, 12 Oct 2011 18:37:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.14 with HTTP; Wed, 12 Oct 2011 18:37:35 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112907A695F@WSMSG3153V.srv.dir.telstra.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DDE6.3080502@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112907A695F@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Wed, 12 Oct 2011 18:37:35 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 01:38:04 -0000 On Wed, Oct 12, 2011 at 5:38 PM, Manger, James H wrote: >> One possible syntax is: >> >> Bearer access_token=3Dxyz_-123,more_info=3Dpdq >> >> Ultimately though, the format of the bearer token is outside of the scop= e of the spec, and up to the participants to determine, including whether t= o use b64token syntax or params syntax. > > > It is great to see an example explaining the intention of the "b64token /= #auth-param" part of the draft. These details need to be in the spec. Draf= t 9 makes no mention of an "access_token" parameter for the HTTP header -- = in sharp contrast to mentioning such a parameter for the URI query string a= nd POST body mechanisms. Can the "access_token" value be a (as in t= he above example)? Can it be a ? Can it use RFC5987 (eg acce= ss_token*=3DUTF-8''...)? > > Can a client choose the b64token or auth-param option, implying servers M= UST support both? Or is it the other way around: servers only have to suppo= rt b64token so existing servers are compliant without requiring any changes= ? > > I thought the consensus was that bearer tokens were so simple that "Beare= r " was sufficient. In the unlikely event that more parameters we= re required in future, a new scheme (eg Bearer2) could be defined. If this = is no longer the consensus then lets: While I much prefer what you suggest below (and it was suggested before), I think it is too late for that. It will force existing deployments to implement ambiguous parsing code. Let's stick with "Bearer ". If this is the only option, do we have to limit the token chars to b64? If more flexibility is needed then we can define a new scheme for that. Marius > > 1. Define a single syntax that servers MUST support. > =A0Authorization: Bearer a=3D"" > > 2. Use a short parameter name, such as "a", saving 10-bytes per request o= ver "access_token". The long name is needed in a URI query string or POST b= ody so the parameter is unambiguous amongst any number of other application= -specific parameters. In a Bearer HTTP header there is no such possibility = of confusion. > > 3. Don't allow the value to be either a or -- jus= t pick one (I suggest ). It doesn't help developers or inter= op to offer a pointless choice. > > 4. Allow future comma-separated parameters, and state that unrecognized p= arameters MUST be ignored. > > 5. Add an informative note that some servers might also accept a header o= f the form "Bearer ", but clients using this form are not com= pliant to this spec. > > 6. Explicitly state that when the type is "bearer" in an OAuth2 token res= ponse, the "access_token" MUST only consist of characters that can be repre= sented in a , ie %x20-7E (assuming was picke= d at #3). > > 7. Recommend that a base64url encoding without padding (of binary data or= of UTF-8 encoded text) is a good choice for an "access_token" value (or a = few base64url encoded segments separated by dots) as it avoids the need to = escape characters in most situations. > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From david@alkaline-solutions.com Wed Oct 12 18:49:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9784121F8B0D for ; Wed, 12 Oct 2011 18:49:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrKjFJFJ70Ci for ; Wed, 12 Oct 2011 18:49:54 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 24F8D21F8B0C for ; Wed, 12 Oct 2011 18:49:54 -0700 (PDT) Received: from [192.168.3.4] (c-24-9-59-104.hsd1.co.comcast.net [24.9.59.104]) by alkaline-solutions.com (Postfix) with ESMTPSA id 7FEF531AE2; Thu, 13 Oct 2011 01:49:54 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_6921EF5C-69DB-4E45-843A-C60119D3C353"; protocol="application/pkcs7-signature"; micalg=sha1 From: David Waite In-Reply-To: Date: Wed, 12 Oct 2011 19:49:53 -0600 Message-Id: References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DDE6.3080502@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond. corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112907A695F@WSMSG3153V.srv.dir.telstra.com> To: OAuth WG X-Mailer: Apple Mail (2.1251.1) Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 01:49:54 -0000 --Apple-Mail=_6921EF5C-69DB-4E45-843A-C60119D3C353 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 12, 2011, at 7:37 PM, Marius Scurtescu wrote: > While I much prefer what you suggest below (and it was suggested > before), I think it is too late for that. It will force existing > deployments to implement ambiguous parsing code. >=20 > Let's stick with "Bearer ". If this is the only option, do > we have to limit the token chars to b64? >=20 > If more flexibility is needed then we can define a new scheme for = that. >=20 I agree. The use of "Bearer" is enough to allow for future extension if = needed, by using one of the many other character sequences allowed for = the scheme. -DW --Apple-Mail=_6921EF5C-69DB-4E45-843A-C60119D3C353 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM/jCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGwjCCBaqg AwIBAgIDAnw3MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTEwNDI5MTYwMDA1WhcNMTIwNDI5MDk0MTQ1WjBPMSAwHgYDVQQNExc0MTUzODYtOTg4TWcyb1h3 eDl2N0RpVDErMCkGCSqGSIb3DQEJARYcZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMoVPfjKn04Z9FqHOInDmpmwVy2q2Ah9fckK7EOl aav/NzExRFFm7GyrCPRnZ4wbfKXi1fwTiZhukHErRWpwE19SF7uO5/oAXzAAADwM7RFZfu03XuOg dndZx3yEaGAw5nhm2BcsQa4hCA7/bsyAFCD0J3O92V95kbQUy+aY6aERgKxplCjQ3gGj6ywDfi0t 6DSNJSd8f9op3bBPAPaQWKvVBFJiUBw9ty1DUcQbrvolCrYcJcm8UOoK3pCUIl3GXbft8DQkTS7g LThCqyqYHOGHHXKj0tQGUtu6CuybmUX6dVUsvDmKvFjFvRSpLRKHNHxwlK9kyqq8l/7B3w1BbVMC AwEAAaOCA2cwggNjMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQULDXoErIVeC/Ev5d69RG2HcZQHvYwHwYDVR0jBBgwFoAUU3Lt kpzg2ssBXHx+ljVO8tS4UYIwJwYDVR0RBCAwHoEcZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNv bTCCAdEGA1UdIASCAcgwggHEMIIBwAYLKwYBBAGBtTcBAgIwggGvMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIIBRQYIKwYBBQUHAgIwggE3MCcWIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEaggEKVGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNz dWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgcG9saWN5IGFuZCBtYXkgYmUgcmVs aWVkIHVwb24gb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgYW5kIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuIExpYWJpbGl0eSBhbmQgd2FycmFudGll cyBhcmUgbGltaXRlZCEwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20v Y3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au c3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBx/ziwxBnt5gAl0eBV Nj+1xFrXwC27uD9gUwFuJGeDjWj1ZmDGTMQ2G1f4eyVqr8+MHPADyKAdtuF/Sm6Isvt2pH8Oxjf7 IbFcGudXH92NvYoPrAC0TwVeahxk87qc6ojxJ5oe82LPkkFtwYl5xuZmUlfstqEBJvnffaxe9BY/ CxLIbNRQoeOrVHtlqcM3vQcmhEF9yhuXurqpSELVr4rSNOzbFem/ZxKK0ZmNVybh675BNwS3BGWk 56SiEaUXHYJe8GRk0Bb6P44g2rZWe7G0NRFyt8qXuia9fN4I89wpOn6S1LrPDD1QdRpTrEMM85Wh sszTXYW6fCMTlyVH+wBQMYIDbzCCA2sCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIDAnw3MAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTExMTAxMzAxNDk1M1owIwYJKoZIhvcNAQkEMRYEFGIvfBEsPanp3mHFG9krT4BSEUU+ MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAnw3MIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMCfDcwDQYJ KoZIhvcNAQEBBQAEggEAV/xGZ/wNsrWp6YPnoEiQ+N/rkHdDfDRSOMLiJsgm15kaoUWIW1tCDwzV VpUYMFgBBg8biZzbzjuxYDIJdOz74Uvvci/pwg/CJvfy7euNXLEAEfGDh2A3G1beFZa9o+w9Ny+5 hiwAgR8lF+popPl+lz1RAYHBmkX/ldLnt+2BxntCzKHCF5+0ZkL8MMKvXh9rl/wGglJ2E+7rj47R 0aQHkywmVjyPk/Lgp/o0GlfJeTlNg8EbDk+I7VkRd+VL0b7wBUALoB7l1LOyX5iJGSDWSYxtaybD NTK+WGHkrdTz/RbalXsBS+/ZvmTvJI+nPdHacLXRvhSsOf7Hz7Or4mY/vAAAAAAAAA== --Apple-Mail=_6921EF5C-69DB-4E45-843A-C60119D3C353-- From julian.reschke@gmx.de Thu Oct 13 00:13:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433E021F8AED for ; Thu, 13 Oct 2011 00:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufTO1VAx1Np7 for ; Thu, 13 Oct 2011 00:13:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0F70721F8AE6 for ; Thu, 13 Oct 2011 00:13:24 -0700 (PDT) Received: (qmail invoked by alias); 13 Oct 2011 07:13:16 -0000 Received: from p5DCC9E25.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.158.37] by mail.gmx.net (mp036) with SMTP; 13 Oct 2011 09:13:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18+PPIB23U+4ChL3rCkITVEJ7pnOo+1iMn7f0Afow PV1jW12+fTNqbi Message-ID: <4E968F88.3090303@gmx.de> Date: Thu, 13 Oct 2011 09:13:12 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> <1318350042.89721.YahooMailNeo@web31810.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1129072392A@WSMSG3153V.srv.dir.telstra.com> <4E955C01.40603@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C238C90@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95A987.1000203@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239299@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DB3B.2040802@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23936C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E95DDE6.3080502@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C239402@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E112907A695F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112907A695F@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 07:13:26 -0000 On 2011-10-13 02:38, Manger, James H wrote: >> One possible syntax is: >> >> Bearer access_token=xyz_-123,more_info=pdq >> >> Ultimately though, the format of the bearer token is outside of the scope of the spec, and up to the participants to determine, including whether to use b64token syntax or params syntax. > > > It is great to see an example explaining the intention of the "b64token / #auth-param" part of the draft. These details need to be in the spec. Draft 9 makes no mention of an "access_token" parameter for the HTTP header -- in sharp contrast to mentioning such a parameter for the URI query string and POST body mechanisms. Can the "access_token" value be a (as in the above example)? Can it be a? Can it use RFC5987 (eg access_token*=UTF-8''...)? > > Can a client choose the b64token or auth-param option, implying servers MUST support both? Or is it the other way around: servers only have to support b64token so existing servers are compliant without requiring any changes? > > I thought the consensus was that bearer tokens were so simple that "Bearer" was sufficient. In the unlikely event that more parameters were required in future, a new scheme (eg Bearer2) could be defined. If this is no longer the consensus then lets: > > 1. Define a single syntax that servers MUST support. > Authorization: Bearer a="" > > 2. Use a short parameter name, such as "a", saving 10-bytes per request over "access_token". The long name is needed in a URI query string or POST body so the parameter is unambiguous amongst any number of other application-specific parameters. In a Bearer HTTP header there is no such possibility of confusion. > > 3. Don't allow the value to be either a or -- just pick one (I suggest). It doesn't help developers or interop to offer a pointless choice. > > 4. Allow future comma-separated parameters, and state that unrecognized parameters MUST be ignored. > > 5. Add an informative note that some servers might also accept a header of the form "Bearer", but clients using this form are not compliant to this spec. > > 6. Explicitly state that when the type is "bearer" in an OAuth2 token response, the "access_token" MUST only consist of characters that can be represented in a, ie %x20-7E (assuming was picked at #3). > > 7. Recommend that a base64url encoding without padding (of binary data or of UTF-8 encoded text) is a good choice for an "access_token" value (or a few base64url encoded segments separated by dots) as it avoids the need to escape characters in most situations. +1 Except for: > 3. Don't allow the value to be either a or -- just pick one (I suggest). It doesn't help developers or interop to offer a pointless choice. ...allow both, because otherwise you'll need custom parsers to process the header field. Best regards, Julian From stephen.farrell@cs.tcd.ie Thu Oct 13 10:13:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BA721F8A64 for ; Thu, 13 Oct 2011 10:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sttIql0MGigb for ; Thu, 13 Oct 2011 10:13:33 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id BF53821F8ADE for ; Thu, 13 Oct 2011 10:13:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A3E87171C70 for ; Thu, 13 Oct 2011 18:13:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-type:subject:mime-version:user-agent:from:date :message-id:received:received:x-virus-scanned; s=cs; t= 1318526007; bh=y8+yUwszaJC3WNQgXe21ril1hRK29CoFY47qDnCCvVo=; b=J Z2llAh7Zkq22yUHN8M3fEeVwS/dEtzeSJbdrrLouu27J5JBy35DxosBPsiaSJOmg vUzBEO60Kii2hazg2v9Q4LYA9q60kZVhC8mIB2fz+UHH9w8uiXSz4Aorkw22Pkog CxUSqBdsnstGEO0LwR0rD1vOWF1YBB76CSo0UBFAvXF5FCBKaFcf2B7hmYbSyD+7 G2Pq0SpmZD2eiey7d0Gk7wYN+k+FjDU2kKotXH2yWIIn96816uD+NT8fKbppd4ll k/OzVDfGsJh6AN1T2cmEySgzSxJvCZLAz0EwQa0DUNMtCwMVJYRCEPwMwGI7yzF6 hXbI0bpyNogqKPpp8oJcw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 4M8gqSxiDi-c for ; Thu, 13 Oct 2011 18:13:27 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.24.80]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 843AD171C71 for ; Thu, 13 Oct 2011 18:13:26 +0100 (IST) Message-ID: <4E971C36.7050000@cs.tcd.ie> Date: Thu, 13 Oct 2011 18:13:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: multipart/mixed; boundary="------------080909020901040701060003" Subject: [OAUTH-WG] AD review of -22 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 17:13:35 -0000 This is a multi-part message in MIME format. --------------080909020901040701060003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. --------------080909020901040701060003 Content-Type: text/plain; name="oauth-22-ad-comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="oauth-22-ad-comments.txt" List 1 - Fairly sure these need changes: ---------------------------------------- (1) In 2.3.1 MUST the AS support both HTTP basic and the client_id and client_secret in the request schemes? You say it MAY "allow" credentials in the request body, but that's different from what the AS coder has to implement. Saying an AS that issues passwords MUST support "basic over TLS" and MAY support including credentials in the body would seem right here. (2) In 2.3.1 (and more generally) what does "MUST require the use of a transport-layer security mechanism" really mean? I think you need to say explicitly what this means in terms of TLS and which version of TLS and which ciphersuites etc. Doing that once is fine and you could then have a defined phrase for it, but it needs to be specified for each place where TLS is used. The text at the end of p15 is almost exactly what's needed, and would be if you said which ciphersuites are MUSTs. I think you might need to pick ciphersuites for each version if you want some combination of tls1.0 and tls1.2 and need server auth at least. (3) Having a MUST for TLS1.0 and a SHOULD for TLS1.2 is going to generate a DISCUSS or two. I think you really need to justify that in the Document and PROTO write up if you want to stick with the current choices. I personally would prefer if those were swapped myself, that is have a MUST for the latest version of TLS (TLS1.2) and a MAY/SHOULD for TLS 1.0. In addition to taking care of process concerns, there is also the recent TLS chosen plaintext attack where TLS1.2 has no problem but TLS1.0 does. (This differs from (2) above, since the former is almost editorial, but I guess this one needs to go to the WG.) (4) The response_type description in 3.1.1 is unclear. You say it MUST be "one of" various values, but then that it can be a space separated list of values. When >1 value is provided, it doesn't say what that means, it only says that the order is irrelevant. (It could mean "any of these" or "all of these" for example, both are order independent, but are not the same.) I suggest adding a sentence to say that "code token" means "please send both" if that's what it means. (5) How does a client implement the MUST in the last sentence of 3.1.2.3? I don't see anything here or in 10.15 that says how to do this. I guess ideally, you'd just need a reference to somewhere else in the doc or to something else, but I do think you need something since you've made this a "MUST ensure" rule for clients. Adding a sentence/short paragraph here or in 10.15 with some typical/good ways to ensure this would be fine. (6) In 7.1 what does it mean to say that the client MUST NOT use the access token if it doesn't trust the token type? I don't know what code I'd write there in a client. Maybe s/trust/support/ or s/trust/understand/ would fix this. (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. One way to do this would be to mandate that the client MUST support mac and MAY support bearer but to allow the server to choose which token types they support. And as a consequence one or both of the mac/bearer drafts need to end up as normative I think. (8) 10.3 says access tokens MUST be kept confidential in transit. Does that not mean that non-anonymous TLS is a MUST? If so, then saying that clearly here would be good. If not, then saying what's really meant clearly is needed. (Same point for refresh tokens in 10.4.) (9) 10.5 says "effort should be made" to keep codes confidential, but I expect that'll generate AD comments - that's just a bit too vague - what do you really mean there? (10) 10.10 has an impossible requirement - you cannot stop/prevent attackers guessing, but you can ensure that such guessing is futile. Can you not be a bit more specific about a "reasonable" level of entropy here? I'd say 10 bits is not enough, 128 is, and there may be a good level to at least RECOMMEND (e.g. maybe >N bits if rate limiting can effectively prevent 2^(N/2) guesses going undetected? I'm not recommending an "N" myself here, but rather that the WG consider picking one or else justify not picking one. (The same comment applies to the term "non-guessable" as used in 10.12 and maybe elsewhere as well.) (11) Section 11 says a couple of times that the apps ADs are the appeal chain - shouldn't that be the SEC ADs now? List 2 - Questions: (not sure whether change needed or not) ---------- (1) p12 - 2.1 says that the client developer declares the type of the client, but then says that the definition is up to the authorization server really, so, in principle one client might have different types for different authorization servers. I think you could make this clearer by adding a sentence saying that one client could have >1 type according to different authorization servers or that the client type could change over time, e.g as some vulnerability in an OS gets discovered or if a new OS feature is added. I'm not sure if there's any action that could/should be taken if the client type changes, perhaps re-registration with a SHOULD for using a new redirection URL and invalidating all outstanding tokens or something? Maybe this sounds like something that some other document (and RFC or not) can tackle later. (2) 3.1 - I think you may need more about how passwords are handled, esp. when they contain odd characters. Is there really no problem with x-www-form-urlencoded when such a password is in a form? Have you checked with someone who really cares about such things? (3) Generally, the specificaion is a bit unclear about what each component MUST do, its hard to figure that out with the style of describing the 2119 rules on a per endpoint basis. Not sure what to suggest that'd not be loads of work, but I wondered if there's evidence that someone not involved in the WG or Oauth1 would find it easy or very hard to implement and get interop? I know that there've been some people who've implemented from the drafts and I'm told some of those were not involved in the WG at all. If you know of any such implementers, it'd be good to note that in the PROTO write-up since it'd answer this question, which I'd expect to be posed by some AD. (4) Is it clear that a client always knows when a redirection request will result in sensitve data being sent, thus triggering the SHOULD for use of TLS in 3.1.2.1? It may well be the case but it wasn't clear to me from reading whether I could write code that'd know when it's ok to not use TLS. (5) 3.1.2.2 says ASes MAY support >1 redirection URI. Why not make that a MUST? If a client needed it, then it couldn't interop with an AS that only supports 1, and it ought be easy for an AS to support >1 I guess. (6) What's the case where the AS is ok to redirect to an unregistered or untrusted URI that corresponds to the 2nd para of 3.1.2.4? (7) Can a client really ensure that other scripts don't go before its own as required in 3.1.2.5? (8) What is the impact of the "MUST be taken into consideration" at the end of 3.2.1? I can't see how to implement that nor is it clear what checks an AS could do at registration time. (9) Does the recent list discussion about scope encoding require any changes to 3.3? (10) Is there anything that needs saying if the AS ignores the client's requested scope but doesn't indicate that in the response? Put another way - why is that SHOULD not a MUST? (Just asking that you explain, not change.) (11) State and scope variables probably should not contain anything sensitive for the client or user, since the AS and UA both get to see them, is that stated somewhere? (Maybe with a hint that if you need something sensitive in the state, then just generate a symmetric key and encrypt it for yourself.) An example of what not to include would be a banking client including a user's bank a/c number as the state variable. (12) 4.4.3 says a refresh token SHOULD NOT be included. Seems like the AS actions for good requests are fairly variable, which is likely to cause developers to do the wrong thing - is there no way to make the AS actions more consistent? (Could be that they are consistent though, but I'm just getting lost in the text;-) (13) 10.9 says that the client MUST verify the server's cert which is fine. However, does that need a reference to e.g. rfc 6125? Also, do you want to be explicit here about the TLS server cert and thereby possibly rule out using DANE with the non PKI options that that WG (may) produce? Suggested non-trivial clarifications: ------------------------------------- (1) 1.3.4 - "previously arranged" might trigger discusses on the document since it implies that this spec might not be suited for broad use. I think that making it clear that the normal mode for client developers is to work against an existing service (AS and resource server) would help to clarify that such arrangements are ok here. (2) p11, in step (F) is there a way to distinguish between an access token that is invalid due to expiry vs. e.g. data corruption? Section 6 refers to 5.2 for the error codes but its not clear to me which one is returned for this case. I think clarifying that in section 6 or 5.2 is needed. (3) p13, 2.2 and 2.3 - these things happens at registration time right? I think making that clear is needed since we don't specify a registration protocol here. (4) 2.3.1 uses the term "token endpoint" without definition (its defined in section 3) and in particular without making it clear if both access and refresh token issuance is covered (I guess it is). (5) The same text about x-www-form-urlencoded is repeated various times, it'd be better to do that once and refer to it where necessary. (6) 3.1.2.2 states the rules for when ASes are to require registration of redirection URIs. I think you need to clarify that some. First, you use the term "redirection_uri" for both a "complete" URI and for a scheme/authority/path triple that can be added to via a query component which is confusing. Second, its overall a very complex rule with a MUST, two MAYs and 3 SHOULDs. I do think it could be made clearer by putting the MUST up front and separating issues related to complete URI and triples separately from the when something MUST be registered. (7) 4.2.1 and elsewhere - refers back to 3.1.2 for the way in which the redirection-uri is OPTIONAL - I'm not sure that's sufficiently clear, 3.1.2 is quite long and discusses a bunch of things - couldn't it be made clearer when the messages are defined? More generally, is there no way to avoid the extensive cross-referencing in the message field definitions? E.g. 4.2.2 has references to 7.1 and 3.3, and others are similar. Organising the text for the benefit of the reader is a good thing so would it be worthwhile to do an editing pass for just this purpose - to reduce the number of forward references and minimise the number of pointers in general? On a similar note, 4.1 & 4.2 call out specific errors, but 4.3 defers to 5.2, why? Be good if that could be made more cosistent at the TOC level. (8) How can the AS protect against brute force attacks in 4.3.2? I think you could give a bit more guidance, e.g. say to rate-limit or generate alerts or whatever, but not as normative text, just good hints. (9) In 10.12 you say how a client can protect against CSRF via the state field but you don't say how the AS can do the same in order to satisfy the MUST in the last para of 10.12. Can you not add a hint or reference here? Some nits: (Stuff that seemed more serious at first:-) --------- (1) In 2.3.1 I think you're ruling out putting the client_id and client_secret in the request URL - is that right? If so, that's good, but I think it needs calling out since people do that all the time and it'd be good to say why its bad to do that. (2) The redirection endpoint is introduced in 3.2.1 but is not listed at the start of section 3 which only lists two endpoints. (3) In 4.1.2 what does it mean to "attempt" to revoke tokens? Why can't the AS just revoke them? (Where revoke == not accept them when they are next presented, right?) (4) I think this is just language but wanna check. 4.1.2.1 and 4.2.2.1 errors have a state field. Text says: "If a valid "state" parameter was present..." which would imply that state variables are either valid or invalid according to the AS. I don't think that's the case, and nor should it be. (If it were, I'd have a security concern that I could use otherwise crap requests to probe for good state values.) s/valid// I think? (5) I don't get the benefit of saying the client SHOULD ignore unknown fields in the response in 4.2.2 - what's effectively the difference between that and "MUST ignore" - I don't get it, and hence don't see why you don't say MUST ignore. (6) Why say "MUST NOT issue a refresh token" in 4.2.2? Are you making an assumption that access & refresh tokens are distinguishable to anyone other than the issuer? If not, then is this just saying "don't make a mistake"? (7) 5.1 says that the client SHOULD ignore "unrecognized response parameters" - does that mean unrecognized parameters in the JSON entity body? Is it clear enough as-is that those are "response parameters"? (8) How does the use of TLS on endpoints used for end-user interaction "reduce the risk of phishing attacks"? I don't get that. Maybe you mean that TLS+users actually checking server identity reduces the risk of successful phishes? I think that's a bit different. (I do like the MUST though.) Original list of nits: ---------------------- - Intro: Maybe add some ascii-art showing the roles of the user, browser, client etc. The term client as used here is still commonly confusing and especially worth going the extra mile to clarify, before it is first used. What I think needs to be said early is that what is here called a client is normally (running on) a web server. - p4: Maybe s/a string/an octet string/ in the token descriptions, unless the access token encoding is constrined to what'd be understood as a string. - p8: Seems odd to speak of "issuing" an implicit grant - wouldn't that make something explicit? Maybe say "With an implicit grant..." instead in the 2nd para of 1.3.2? - p8: I don't get what "its device operating system" means. Do you mean the client is an already-trusted part of the resource owner's device OS? - p9 - "Issuing a refresh token is optional" - might be better to say that its the authorization server's choice and there's no way for the client to signal a request for one. - p10 - In figure 2, why is the Refresh token shown as optional in step (H) but not in step (B)? I think it'd be clearer for the figure to reflect the protocol options and say that the refresh token is optional in (B) as well. - p12 - the confidential/public terminology isn't great, did the WG consider "authenticating" vs "non-authenticating"? Trying again to find better terms would maybe be worthwhile. Also, it may be worth explicitly saying that it doens't matter how hard to guess a secret the client has nor how good a MAC algorithm you use with that secret - if anyone can get the secret then the client is still public. It nearly says that, but not quite and given that many developers just don't apparently still think that a hardcoded secret embedded into a binary is good enough, I'd argue its worth adding a bit more here. - p12/13 in the application profile descriptions - is "resource owner's device" correct? That seems to rule out kiosks, which may be correct, but which isn't obvious. Maybe you mean "device being used by the resource owner" with no implication as to ownership of the device? - p13 - client application: typos: s/such access tokens/such as access tokens/ s/which...interact with/with which the application may interact/ - p13, "establishing trust with the client or its developer" is badly phrased, I think you mean the AS SHOULD NOT just accept the client type unless it has some external reason to do so. Trusting the developer might be one such. Being paid is another, and maybe more likely;-) - p13, 2.3 has 2119 language both about the things established at registration time and things done in the protocol defined here - would it be better to identify those separately in different sections or maybe move the registration time stuff into 2.2 with a possible renaming of 2.2. - 3.1.2.1 has a SHOULD for TLS which I think generated a lot of mail on the list. I think saying why this is not a MUST would be useful, since its the kind of thing that might get revised later on if the situation changes. - Figure 3, (p21) has multiple lines labelled A,B & C - saying why might reduce some confusion. Or maybe, say that the labels reflect rough event timing or something. It'd also be good if subsequent sections said which parts of figure 3 they're addressing, e.g. 4.1.1 maps to (A), right? Its hard to tell. -p25, 4.1.3, what does "assigned" "authentication requirements" mean? Suggest deleting the parenthetical clause since "confifential client" should be sufficiently well-defined to cover that. -p28, the description of step (D) isn't clear to me - who does what with the URI fragment? -p30, why refer to "HTTP client implementations" when you're previously said UA? If there's a substantive difference it'd be good to be clear about that. Same para: s/such client/such clients/ -p33 - Just checking - 4.3.1 says the client MUST discard the credentials once an access token has been obtained - why not before though, e.g. once an access token has been requested? Is there a re-tx thing that the client might do? -p38, is "token_type":"example" a valid value? If not, better to use one that is. -p40, s/client it was issued/client to which it was issued/? -p40, s/require/REQUIRE/ in the 2nd last bullet on the page -p43, s/native clients may require/native clients require/ I'd say the "may" is worth deleting both to avoid 2119 language and because we do know that these require special consideration. -p46, s/such malicious clients/such potentially malicious clients/? Not all unauthenticated clients are bad, though all of them could be bad. -p47, s/Access token (as well as.../Access tokens (as well as.../ -p50, 10.8 seems to just repeat stuff from earlier in 10.3 & 10.4, is that deliberate? --------------080909020901040701060003-- From hannes.tschofenig@gmx.net Fri Oct 14 05:25:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCE421F8B79 for ; Fri, 14 Oct 2011 05:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.02 X-Spam-Level: X-Spam-Status: No, score=-101.02 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XGEwhd6HueL for ; Fri, 14 Oct 2011 05:25:29 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2B6AB21F8B49 for ; Fri, 14 Oct 2011 05:25:28 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2011 12:25:27 -0000 Received: from unknown (EHLO [10.255.132.80]) [192.100.123.77] by mail.gmx.net (mp013) with SMTP; 14 Oct 2011 14:25:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1914AkTwmR1FFZedKx9Ad2a/jeys2bXvK1kAGBZcY lST4VO+f8kzRYa From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 15:25:25 +0300 Message-Id: <101476B6-E03C-4188-9DB4-176541FDC0C5@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 12:25:30 -0000 Hi all,=20 I had a discussion with Mike and Julian to hear what to discuss the open = issues with the OAuth Bearer Token draft. Below is a short writeup of my = impressions.=20 1. Error Description The error description field provides information to the software = developer and is not meant to be shown to the end user. As such, there = is no desire to provide internationalization support for this field. = Hence, it has a similar characteristic as the HTTP 'Reason-Phrase.=20 = http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.ht= ml#reason.phrase says " The Reason Phrase exists for the sole purpose of providing a textual = description associated with the numeric status code, out of deference to = earlier Internet application protocols that were more frequently used = with interactive text clients. A client SHOULD ignore the content of the = Reason Phrase. Reason-Phrase =3D *( HTAB / SP / VCHAR / obs-text ) " We can use something similar for the error description field and even = simplify it further by omitting HTAB and obs-text: error-desc =3D "error_description" "=3D" *( SP / VCHAR ) 2. Scope The scope field is yet another item that will not be shown to the user = and it serves the purpose of an identifier for authorization comparison. = So, we don't need to have any internationalization support here either.=20= The suggestion is to re-use the 'token ABNF syntax from the HTTP spec: = http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.ht= ml#rfc.section.3.2.3 3. Authorization Request Header Field Finally, there is the authorization request header field where we have = to decide how we want to deal with extensions.=20 The current specification says:=20 credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) This means that we can have either a base64 opaque blob or a parameter = like syntax (but not both).=20 An example of the b64token is=20 Authorization: Bearer vF9dft4qmT and an example of the auth-param usage is Authorization: Bearer t=3DvF9dft4qmT With an opaque blob extensibility is limited and for this reason, I = guess, Mike had provided the additional option of auth-parameter.=20 If we want to allow extensibility then we have to go for the auth-param = approach. If we only use the auth-param (without the b64token) then = there may be an issue with already existing implementations. We will = have to double-check.=20 Then, there is the possibility to provide two ways to encode the same = information, namely either as a base64 blob and in the auth-parameter = style. (In a single protocol run one would obviously only use one or the = other.) If we define the auth-param then we have to also provide information on = what it actually is. We cannot leave that out of scope.=20 Ciao Hannes From Michael.Jones@microsoft.com Fri Oct 14 08:43:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1F921F8AEC for ; Fri, 14 Oct 2011 08:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oWLyilL5dyl for ; Fri, 14 Oct 2011 08:43:06 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id EBD8121F84F5 for ; Fri, 14 Oct 2011 08:42:59 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Oct 2011 08:42:59 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 08:42:59 -0700 From: Mike Jones To: Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHg== Date: Fri, 14 Oct 2011 15:42:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C23C5A6TK5EX14MBXC284r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 15:43:09 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C23C5A6TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the useful discussion and the write-up, Hannes. For context, Ha= nnes and I discussed how to resolve the remaining Bearer spec issues in a m= anner that meets the needs of implementations and will not generate objecti= ons during the IESG or IETF Last Call reviews. A few additional comments..= . 1. Error Description - Nothing to add to Hannes' write-up. 2. Scope - I was planning to allow a broader set of ASCII characters than = the "token" set, as these characters are inadequate for the use of URIs/URL= s as scope elements. In particular, scope elements need to permit the full= sets of "reserved" and "u= nreserved" characters in R= FC 3986. The draft I am working on wil= l say that scope is a space separated set of elements, where the elements c= onsist of one or more characters from the union of the "reserved" and "unre= served" sets. 3. Authorization Request Header Field - We agreed on the call that we're n= ot doing implementers any favors by allowing both the b64token and #auth-pa= ram syntaxes, and that it is better to specify one or the other. Since exi= sting practice corresponds to the b4token syntax, the choice is clear which= to specify. Thus, it was a mistake to introduce the #auth-param choice in= draft 9. It will be removed in draft 10, which is shortly forthcoming. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Friday, October 14, 2011 5:25 AM To: OAuth WG Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed R= esolutions Hi all, I had a discussion with Mike and Julian to hear what to discuss the open is= sues with the OAuth Bearer Token draft. Below is a short writeup of my impr= essions. 1. Error Description The error description field provides information to the software developer = and is not meant to be shown to the end user. As such, there is no desire t= o provide internationalization support for this field. Hence, it has a simi= lar characteristic as the HTTP 'Reason-Phrase. http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.htm= l#reason.phrase says " The Reason Phrase exists for the sole purpose of providing a textual descri= ption associated with the numeric status code, out of deference to earlier = Internet application protocols that were more frequently used with interact= ive text clients. A client SHOULD ignore the content of the Reason Phrase. Reason-Phrase =3D *( HTAB / SP / VCHAR / obs-text ) " We can use something similar for the error description field and even simpl= ify it further by omitting HTAB and obs-text: error-desc =3D "error_description" "=3D" *( SP / VCHAR ) 2. Scope The scope field is yet another item that will not be shown to the user and = it serves the purpose of an identifier for authorization comparison. So, we= don't need to have any internationalization support here either. The suggestion is to re-use the 'token ABNF syntax from the HTTP spec: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.htm= l#rfc.section.3.2.3 3. Authorization Request Header Field Finally, there is the authorization request header field where we have to d= ecide how we want to deal with extensions. The current specification says: credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) This means that we can have either a base64 opaque blob or a parameter like= syntax (but not both). An example of the b64token is Authorization: Bearer vF9dft4qmT and an example of the auth-param usage is Authorization: Bearer t=3DvF9dft4qmT With an opaque blob extensibility is limited and for this reason, I guess, = Mike had provided the additional option of auth-parameter. If we want to allow extensibility then we have to go for the auth-param app= roach. If we only use the auth-param (without the b64token) then there may = be an issue with already existing implementations. We will have to double-c= heck. Then, there is the possibility to provide two ways to encode the same infor= mation, namely either as a base64 blob and in the auth-parameter style. (In= a single protocol run one would obviously only use one or the other.) If we define the auth-param then we have to also provide information on wha= t it actually is. We cannot leave that out of scope. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435C23C5A6TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the useful discussion and the write-up= , Hannes.  For context, Hannes and I discussed how to resolve the rema= ining Bearer spec issues in a manner that meets the needs of implementation= s and will not generate objections during the IESG or IETF Last Call reviews.  A few additional comments…=

 

1.  Error Description – Nothing to add= to Hannes’ write-up.

 

2.  Scope – I was planning to allow a = broader set of ASCII characters than the “token” set, as these = characters are inadequate for the use of URIs/URLs as scope elements. = In particular, scope elements need to permit the full sets of “reserved= ” and “unreserved” characters in RFC 3986.  The draft I am working on will say that scope is a space separate= d set of elements, where the elements consist of one or more characters fro= m the union of the “reserved” and “unreserved” sets.

 

3.  Authorization Request Header Field ̵= 1; We agreed on the call that we’re not doing implementers any favors= by allowing both the b64token and #auth-param syntaxes, and that it is bet= ter to specify one or the other.  Since existing practice corresponds to the b4token syntax, the choice is clear which to specify.&n= bsp; Thus, it was a mistake to introduce the #auth-param choice in draft 9.=   It will be removed in draft 10, which is shortly forthcoming.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; -- Mike

 

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig
Sent: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions

 

Hi all,

 

I had a discussion with Mike and Julian to hear w= hat to discuss the open issues with the OAuth Bearer Token draft. Below is = a short writeup of my impressions.

 

1. Error Description

 

The error description field provides information = to the software developer and is not meant to be shown to the end user. As = such, there is no desire to provide internationalization support for this f= ield. Hence, it has a similar characteristic as the HTTP 'Reason-Phrase.

 

http://greenbytes.de/tech/webdav/draft-iet= f-httpbis-p1-messaging-latest.html#reason.phrase says

 

"

The Reason Phrase exists for the sole purpose of = providing a textual description associated with the numeric status code, ou= t of deference to earlier Internet application protocols that were more fre= quently used with interactive text clients. A client SHOULD ignore the content of the Reason Phrase.

 

Reason-Phrase  =3D *( HTAB / SP / VCHAR / ob= s-text ) "

 

We can use something similar for the error descri= ption field and even simplify it further by omitting HTAB and obs-text:

 

  error-desc      = =3D "error_description" "=3D" *( SP / VCHAR )

 

2. Scope

 

The scope field is yet another item that will not= be shown to the user and it serves the purpose of an identifier for author= ization comparison. So, we don't need to have any internationalization supp= ort here either.

 

The suggestion is to re-use the 'token ABNF synta= x from the HTTP spec:

http://greenbytes.de/tech/webdav/draft= -ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.3

 

3. Authorization Request Header Field<= /p>

 

Finally, there is the authorization request heade= r field where we have to decide how we want to deal with extensions.

The current specification says:

 

  credentials =3D "Bearer" 1*SP ( = b64token / #auth-param )

 

This means that we can have either a base64 opaqu= e blob or a parameter like syntax (but not both).

 

An example of the b64token is

 

Authorization: Bearer vF9dft4qmT

 

and an example of the auth-param usage is

 

Authorization: Bearer t=3DvF9dft4qmT

 

With an opaque blob extensibility is limited and = for this reason, I guess, Mike had provided the additional option of auth-p= arameter.

 

If we want to allow extensibility then we have to= go for the auth-param approach. If we only use the auth-param (without the= b64token) then there may be an issue with already existing implementations= . We will have to double-check.

 

Then, there is the possibility to provide two way= s to encode the same information, namely either as a base64 blob and in the= auth-parameter style. (In a single protocol run one would obviously only u= se one or the other.)

 

If we define the auth-param then we have to also = provide information on what it actually is. We cannot leave that out of sco= pe.

 

Ciao

Hannes

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org=

https://www.ie= tf.org/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B16804296739435C23C5A6TK5EX14MBXC284r_-- From julian.reschke@gmx.de Fri Oct 14 08:52:25 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC7D21F8CA9 for ; Fri, 14 Oct 2011 08:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmm0DDtSH4fw for ; Fri, 14 Oct 2011 08:52:24 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id ADB2E21F8CA5 for ; Fri, 14 Oct 2011 08:52:23 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2011 15:52:22 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 14 Oct 2011 17:52:22 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX183WmgUjfI3ZiPJJRH6y3eaYJGfJ5fj3nRXfZrKvb /FXDngxesbC9Xr Message-ID: <4E985AB2.10201@gmx.de> Date: Fri, 14 Oct 2011 17:52:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 15:52:25 -0000 On 2011-10-14 17:42, Mike Jones wrote: > Thanks for the useful discussion and the write-up, Hannes. For context, > Hannes and I discussed how to resolve the remaining Bearer spec issues > in a manner that meets the needs of implementations and will not > generate objections during the IESG or IETF Last Call reviews. A few > additional comments… > > 1. Error Description – Nothing to add to Hannes’ write-up. > > 2. Scope – I was planning to allow a broader set of ASCII characters > than the “token” set, as these characters are inadequate for the use of > URIs/URLs as scope elements. In particular, scope elements need to > permit the full sets of “reserved” > and “unreserved” > characters in RFC 3986 > . The draft I am working on will say > that scope is a space separated set of elements, where the elements > consist of one or more characters from the union of the “reserved” and > “unreserved” sets. > ... If you do that, you'll need to be careful with the encoding in case you stick with x-www-url-encoded (SP -> "+" etc). Best regards, Julian From eran@hueniverse.com Fri Oct 14 09:01:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83C721F84C9 for ; Fri, 14 Oct 2011 09:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z7MuCfQufV1 for ; Fri, 14 Oct 2011 09:01:06 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 5883F21F84A5 for ; Fri, 14 Oct 2011 09:01:06 -0700 (PDT) Received: (qmail 26940 invoked from network); 14 Oct 2011 15:55:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Oct 2011 15:55:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 14 Oct 2011 08:55:35 -0700 From: Eran Hammer-Lahav To: Mike Jones , Hannes Tschofenig , OAuth WG Date: Fri, 14 Oct 2011 08:55:07 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAANS7Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452604B8EDD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.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_90C41DD21FB7C64BB94121FBBC2E723452604B8EDDP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:01:09 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723452604B8EDDP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is not sufficient. For scope, if you are going to restrict the allowed characters, you must ei= ther specify how to encode all other values to fit the field, or we must mo= ve this restriction to the v2 specification so that no encoding is required= . For the token, you need to also define allowed token values so that they wi= ll fit in the header without encode, or specify an encoding scheme. The MAC= token restricts token values (called MAC identifier) to %x20-21 / %x23-5B = / %x5D-7E (any printable ASCII character except for " and \). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, October 14, 2011 8:43 AM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Thanks for the useful discussion and the write-up, Hannes. For context, Ha= nnes and I discussed how to resolve the remaining Bearer spec issues in a m= anner that meets the needs of implementations and will not generate objecti= ons during the IESG or IETF Last Call reviews. A few additional comments..= . 1. Error Description - Nothing to add to Hannes' write-up. 2. Scope - I was planning to allow a broader set of ASCII characters than = the "token" set, as these characters are inadequate for the use of URIs/URL= s as scope elements. In particular, scope elements need to permit the full= sets of "reserved" and "u= nreserved" characters in R= FC 3986. The draft I am working on wil= l say that scope is a space separated set of elements, where the elements c= onsist of one or more characters from the union of the "reserved" and "unre= served" sets. 3. Authorization Request Header Field - We agreed on the call that we're n= ot doing implementers any favors by allowing both the b64token and #auth-pa= ram syntaxes, and that it is better to specify one or the other. Since exi= sting practice corresponds to the b4token syntax, the choice is clear which= to specify. Thus, it was a mistake to introduce the #auth-param choice in= draft 9. It will be removed in draft 10, which is shortly forthcoming. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Hanne= s Tschofenig Sent: Friday, October 14, 2011 5:25 AM To: OAuth WG Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed R= esolutions Hi all, I had a discussion with Mike and Julian to hear what to discuss the open is= sues with the OAuth Bearer Token draft. Below is a short writeup of my impr= essions. 1. Error Description The error description field provides information to the software developer = and is not meant to be shown to the end user. As such, there is no desire t= o provide internationalization support for this field. Hence, it has a simi= lar characteristic as the HTTP 'Reason-Phrase. http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.htm= l#reason.phrase says " The Reason Phrase exists for the sole purpose of providing a textual descri= ption associated with the numeric status code, out of deference to earlier = Internet application protocols that were more frequently used with interact= ive text clients. A client SHOULD ignore the content of the Reason Phrase. Reason-Phrase =3D *( HTAB / SP / VCHAR / obs-text ) " We can use something similar for the error description field and even simpl= ify it further by omitting HTAB and obs-text: error-desc =3D "error_description" "=3D" *( SP / VCHAR ) 2. Scope The scope field is yet another item that will not be shown to the user and = it serves the purpose of an identifier for authorization comparison. So, we= don't need to have any internationalization support here either. The suggestion is to re-use the 'token ABNF syntax from the HTTP spec: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.htm= l#rfc.section.3.2.3 3. Authorization Request Header Field Finally, there is the authorization request header field where we have to d= ecide how we want to deal with extensions. The current specification says: credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) This means that we can have either a base64 opaque blob or a parameter like= syntax (but not both). An example of the b64token is Authorization: Bearer vF9dft4qmT and an example of the auth-param usage is Authorization: Bearer t=3DvF9dft4qmT With an opaque blob extensibility is limited and for this reason, I guess, = Mike had provided the additional option of auth-parameter. If we want to allow extensibility then we have to go for the auth-param app= roach. If we only use the auth-param (without the b64token) then there may = be an issue with already existing implementations. We will have to double-c= heck. Then, there is the possibility to provide two ways to encode the same infor= mation, namely either as a base64 blob and in the auth-parameter style. (In= a single protocol run one would obviously only use one or the other.) If we define the auth-param then we have to also provide information on wha= t it actually is. We cannot leave that out of scope. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723452604B8EDDP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is not sufficient.

 

For scope, if you are going to restr= ict the allowed characters, you must either specify how to encode all other= values to fit the field, or we must move this restriction to the v2 specif= ication so that no encoding is required.

 

For the token, you need to also = define allowed token values so that they will fit in the header without enc= ode, or specify an encoding scheme. The MAC token restricts token values (c= alled MAC identifier) to %x20-21 / %x23-5B / %x5D-7E (any printable ASCII c= haracter except for " and \).

 

EHL

 

 

From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday= , October 14, 2011 8:43 AM
To: Hannes Tschofenig; OAuth WG
= Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &= ; Proposed Resolutions

 

Thanks for the useful discus= sion and the write-up, Hannes.  For context, Hannes and I discussed ho= w to resolve the remaining Bearer spec issues in a manner that meets the ne= eds of implementations and will not generate objections during the IESG or = IETF Last Call reviews.  A few additional comments…

 

1.&n= bsp; Error Description – Nothing to add to Hannes’ write-up.

 

2.  Scope – I was planning to allow a broader set of ASCII= characters than the “token” set, as these characters are inade= quate for the use of URIs/URLs as scope elements.  In particular, scop= e elements need to permit the full sets of “reserved” and “unreserved” char= acters in RFC 3986. = ; The draft I am working on will say that scope is a space separated set of= elements, where the elements consist of one or more characters from the un= ion of the “reserved” and “unreserved” sets.

 

3.  Authorization Request Header Field – We agreed on the call= that we’re not doing implementers any favors by allowing both the b6= 4token and #auth-param syntaxes, and that it is better to specify one or th= e other.  Since existing practice corresponds to the b4token syntax, t= he choice is clear which to specify.  Thus, it was a mistake to introd= uce the #auth-param choice in draft 9.  It will be removed in draft 10= , which is shortly forthcoming.

=  

      = ;            &n= bsp;            = ;            &n= bsp;            = ;    -- Mike

&nbs= p;

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf Of Hannes Tschofenig
Sent: Friday, October 14, 2011 5:25 = AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Op= en Issues & Proposed Resolutions

=  

Hi all,

 

I had a discu= ssion with Mike and Julian to hear what to discuss the open issues with the= OAuth Bearer Token draft. Below is a short writeup of my impressions.

 

1. Error Description

 =

The error description field provides info= rmation to the software developer and is not meant to be shown to the end u= ser. As such, there is no desire to provide internationalization support fo= r this field. Hence, it has a similar characteristic as the HTTP 'Reason-Ph= rase.

 

http://greenbytes.de/tech/webdav/draft-ietf-httpbis-= p1-messaging-latest.html#reason.phrase says

 

"<= /o:p>

The Reason Phrase exists for the sole purp= ose of providing a textual description associated with the numeric status c= ode, out of deference to earlier Internet application protocols that were m= ore frequently used with interactive text clients. A client SHOULD ignore t= he content of the Reason Phrase.

 

Reason-Phrase  =3D *( HTAB / = SP / VCHAR / obs-text ) "

&= nbsp;

We can use something similar for the= error description field and even simplify it further by omitting HTAB and = obs-text:

 

  error-desc      =3D "= ;error_description" "=3D" *( SP / VCHAR )

 

2. Scope

 

The scope field is yet another item that will not be shown to the us= er and it serves the purpose of an identifier for authorization comparison.= So, we don't need to have any internationalization support here either.

 

The suggestion is to re-use the 'token ABNF syntax from the HTTP spe= c:

http://greenbytes.de/te= ch/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.3

 

3. Authorization Request Header Field

 

Finally, ther= e is the authorization request header field where we have to decide how we = want to deal with extensions.

The cu= rrent specification says:

 = ;

  credentials =3D "Bearer"= ; 1*SP ( b64token / #auth-param )

 

This means that we can have eithe= r a base64 opaque blob or a parameter like syntax (but not both).

 

= An example of the b64token is

&= nbsp;

Authorization: Bearer vF9dft4qmT

 

and an example of the auth-param usage is

 

Authorization: Beare= r t=3DvF9dft4qmT

 

With an opaque blob extensibility is limited and f= or this reason, I guess, Mike had provided the additional option of auth-pa= rameter.

 

If we want to allow extensibility then we have to go for = the auth-param approach. If we only use the auth-param (without the b64toke= n) then there may be an issue with already existing implementations. We wil= l have to double-check.

 <= /o:p>

Then, there is the possibility to provide = two ways to encode the same information, namely either as a base64 blob and= in the auth-parameter style. (In a single protocol run one would obviously= only use one or the other.)

&nb= sp;

If we define the auth-param then we ha= ve to also provide information on what it actually is. We cannot leave that= out of scope.

 

=

Ciao

Hannes

 

_______________________________________________

OAuth mailing list

= OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/= oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723452604B8EDDP3PW5EX1MB01E_-- From julian.reschke@gmx.de Fri Oct 14 09:10:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C82721F84FC for ; Fri, 14 Oct 2011 09:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXotscgY1w-1 for ; Fri, 14 Oct 2011 09:10:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 60A8021F84B7 for ; Fri, 14 Oct 2011 09:10:44 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2011 16:10:43 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp040) with SMTP; 14 Oct 2011 18:10:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/8ol0y/oj8Amx87vN4UQrgJtRk0uKV11GkLZeJlr ctclGZ2UzSJEA2 Message-ID: <4E985EFF.8080807@gmx.de> Date: Fri, 14 Oct 2011 18:10:39 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E985AB2.10201@gmx.de> In-Reply-To: <4E985AB2.10201@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:10:45 -0000 On 2011-10-14 17:52, Julian Reschke wrote: > On 2011-10-14 17:42, Mike Jones wrote: >> Thanks for the useful discussion and the write-up, Hannes. For context, >> Hannes and I discussed how to resolve the remaining Bearer spec issues >> in a manner that meets the needs of implementations and will not >> generate objections during the IESG or IETF Last Call reviews. A few >> additional comments… >> >> 1. Error Description – Nothing to add to Hannes’ write-up. >> >> 2. Scope – I was planning to allow a broader set of ASCII characters >> than the “token” set, as these characters are inadequate for the use of >> URIs/URLs as scope elements. In particular, scope elements need to >> permit the full sets of “reserved” >> and “unreserved” >> characters in RFC 3986 >> . The draft I am working on will say >> that scope is a space separated set of elements, where the elements >> consist of one or more characters from the union of the “reserved” and >> “unreserved” sets. >> ... > > If you do that, you'll need to be careful with the encoding in case you > stick with x-www-url-encoded (SP -> "+" etc). Sorry, /me confused. Looked again at : scope = "scope" "=" <"> scope-v *( SP scope-v ) <"> scope-v = 1*quoted-char quoted-char = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" You can't do this, as it conflicts with the syntax for quoted-string. So the right way to do this is to say: scope = "scope" *SP "=" *SP ( token / quoted-string ) and then have prose constrain the value of the param after potentially unescaping the quoted-string. Best regards, Julian From Michael.Jones@microsoft.com Fri Oct 14 09:46:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28E721F8C96 for ; Fri, 14 Oct 2011 09:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-PfWcWH6Xqy for ; Fri, 14 Oct 2011 09:46:54 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2419D21F8C93 for ; Fri, 14 Oct 2011 09:46:54 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Oct 2011 09:46:31 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 09:46:31 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAO/tgAAACkEIAADX9yIA== Date: Fri, 14 Oct 2011 16:46:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23C756@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E985AB2.10201@gmx.de> <4E985EFF.8080807@gmx.de> In-Reply-To: <4E985EFF.8080807@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:46:54 -0000 Indeed, recognizing that you're right that "you can't do that" with the cur= rent syntax, we decided to change scope to quoted-string so that it is comp= atible with HTTPbis and add the restriction that no "\" quoting may be pres= ent in the string (to simplify implementations). -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Friday, October 14, 2011 9:11 AM To: Mike Jones Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions On 2011-10-14 17:52, Julian Reschke wrote: > On 2011-10-14 17:42, Mike Jones wrote: >> Thanks for the useful discussion and the write-up, Hannes. For=20 >> context, Hannes and I discussed how to resolve the remaining Bearer=20 >> spec issues in a manner that meets the needs of implementations and=20 >> will not generate objections during the IESG or IETF Last Call=20 >> reviews. A few additional comments... >> >> 1. Error Description - Nothing to add to Hannes' write-up. >> >> 2. Scope - I was planning to allow a broader set of ASCII characters=20 >> than the "token" set, as these characters are inadequate for the use=20 >> of URIs/URLs as scope elements. In particular, scope elements need to=20 >> permit the full sets of "reserved" >> and "unreserved" >> characters in RFC=20 >> 3986 . The draft I am working on=20 >> will say that scope is a space separated set of elements, where the=20 >> elements consist of one or more characters from the union of the=20 >> "reserved" and "unreserved" sets. >> ... > > If you do that, you'll need to be careful with the encoding in case=20 > you stick with x-www-url-encoded (SP -> "+" etc). Sorry, /me confused. Looked again at : scope =3D "scope" "=3D" <"> scope-v *( SP scope-v ) <"> scope-v =3D 1*quoted-char quoted-char =3D ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" You can't do this, as it conflicts with the syntax for quoted-string. So the right way to do this is to say: scope =3D "scope" *SP "=3D" *SP ( token / quoted-string ) and then have prose constrain the value of the param after potentially unes= caping the quoted-string. Best regards, Julian From wmills@yahoo-inc.com Fri Oct 14 09:49:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977EE21F8CB6 for ; Fri, 14 Oct 2011 09:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.998 X-Spam-Level: X-Spam-Status: No, score=-16.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmCERzNja0ja for ; Fri, 14 Oct 2011 09:49:36 -0700 (PDT) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by ietfa.amsl.com (Postfix) with SMTP id 95E9021F8CB1 for ; Fri, 14 Oct 2011 09:49:36 -0700 (PDT) Received: from [98.139.91.69] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 14 Oct 2011 16:49:35 -0000 Received: from [98.139.91.11] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 14 Oct 2011 16:48:35 -0000 Received: from [127.0.0.1] by omp1011.mail.sp2.yahoo.com with NNFMP; 14 Oct 2011 16:48:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 579625.17691.bm@omp1011.mail.sp2.yahoo.com Received: (qmail 93219 invoked by uid 60001); 14 Oct 2011 16:48:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1318610914; bh=4H27TnPZTrcWH9QDprQCoJhlzUltH82vYdIWzPkdtls=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IcXgGcxAWYvlhQX0e7qHRruLyIjA2SR2gFiX2pYDFCj4c2IUwFSovuoEjT7Yjk7JSq4/LUBx0/ImZFb2jLgDm8biwFhWifKjQnzf6DowdwsEbKAJ3Y0bQ+8H0pr/1Z8Hlx8w6zOvWe/O4YTQUFMx8VKMf0s4PVD+uA1g4j5hJQg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CYALGeoxV/yxbRhnwG2cmbCgcAPwPFw3klyaxr8GeqnDncNO1fhjH09jDyTvpMmOc8pQkT46Bbv6XVJH/fxNuRhrFMF6VVrWLUicVtSIo8DadZwp45U2v7z4q3SV9rBLmZGD9cfjsjMj4IkSo6s3mxNIv9dMddFv5PIozHbfGdA=; X-YMail-OSG: Fmu669AVM1mxEJt6wTvfpOdEMXGikwWXQORtQpLFWGKx6at Aef_2XJr2ZoFItJQVA3XO31rxemtg_uvIQwLaQqh8gRlcIWWORPE1x3rK5W8 W5ar4kBKFetgUbx6OBVG4wOOfjNG8K7.ILElL6yE0ftIcvhgGIaXokQ8c068 .t83ArVQJ1aOZsHoN6MVFGxofW9dNBGQ355PAsmEHlKAYvNvj7SdXCU71tp2 1HWbJGeUMZTSjuaf2qIpSEHUg1ALfinX3EOBIHZFe3CB_bsn.t6GC0uor.SQ RJLRYqUEyNvL__2ULrNEqt7t9QkUvjimGnV323OVlTYFWHMwXvdRkMxa4cO2 s9khkHWmsSbD9wV7J4EoWpFfWBtuW6vasrvC4zHkQDzSGvEvpZ2uK_pPLv.C FeXZubCCrlckYK3y1akunRxT1vVkc8vq3WdvRR90VTTzGmfx0vcDEyfXmlDD PR8K9A3TPLYp_h1i1ULHzBXoYEBJYJrD0bozqa_W3xg9.P58m9IidAzMT9gL q0AwOulLqgTAVHT7itp8PK.0y1V0- Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Fri, 14 Oct 2011 09:48:34 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1318610914.92931.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Fri, 14 Oct 2011 09:48:34 -0700 (PDT) From: William Mills To: Mike Jones , Hannes Tschofenig , OAuth WG In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1929416670-1318610914=:92931" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:49:37 -0000 --0-1929416670-1318610914=:92931 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Scope has to be defined in the core OAuth spec.=C2=A0 I think it's a mistak= e to talk about it in regard to the Bearer token spec specifically.=0A=0AI = think removing the auth-param usage is workable.=C2=A0 Then if we need exte= nsibility defining a new scheme can do that.=C2=A0 It's a bit more work tha= t way if needed, but it's clean.=0A=0A=0A-bill=0A=0A=0A=0A_________________= _______________=0AFrom: Mike Jones =0ATo: Hann= es Tschofenig ; OAuth WG =0ASent= : Friday, October 14, 2011 8:42 AM=0ASubject: Re: [OAUTH-WG] draft-ietf-oau= th-v2-bearer-09: Open Issues & Proposed Resolutions=0A=0A=0A =0AThanks for = the useful discussion and the write-up, Hannes. =C2=A0For context, Hannes a= nd I discussed how to resolve the remaining Bearer spec issues in a manner = that meets the needs of implementations and will not generate objections du= ring the IESG or IETF Last Call reviews.=C2=A0 A few additional comments=E2= =80=A6=0A=C2=A0=0A1.=C2=A0 Error Description =E2=80=93 Nothing to add to Ha= nnes=E2=80=99 write-up.=0A=C2=A0=0A2.=C2=A0 Scope =E2=80=93 I was planning = to allow a broader set of ASCII characters than the =E2=80=9Ctoken=E2=80=9D= set, as these characters are inadequate for the use of URIs/URLs as scope = elements.=C2=A0 In particular, scope elements need to permit the full sets = of =E2=80=9Creserved=E2=80=9D and =E2=80=9Cunreserved=E2=80=9D characters i= n RFC 3986.=C2=A0 The draft I am working on will say that scope is a space = separated set of elements, where the elements consist of one or more charac= ters from the union of the =E2=80=9Creserved=E2=80=9D and =E2=80=9Cunreserv= ed=E2=80=9D sets.=0A=C2=A0=0A3.=C2=A0 Authorization Request Header Field = =E2=80=93 We agreed on the call that we=E2=80=99re not doing implementers a= ny favors by allowing both the b64token and #auth-param syntaxes, and that = it is better to specify one or the other.=C2=A0 Since existing practice cor= responds to the b4token syntax, the choice is clear which to specify.=C2=A0= Thus, it was a mistake to introduce the #auth-param choice in draft 9.=C2= =A0 It will be removed in draft 10, which is shortly forthcoming.=0A=C2=A0= =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A=C2=A0= =0A-----Original Message-----=0AFrom: oauth-bounces@ietf.org [mailto:oauth-= bounces@ietf.org] On Behalf Of Hannes Tschofenig=0ASent: Friday, October 14= , 2011 5:25 AM=0ATo: OAuth WG=0ASubject: [OAUTH-WG] draft-ietf-oauth-v2-bea= rer-09: Open Issues & Proposed Resolutions=0A=C2=A0=0AHi all, =0A=C2=A0=0AI= had a discussion with Mike and Julian to hear what to discuss the open iss= ues with the OAuth Bearer Token draft. Below is a short writeup of my impre= ssions. =0A=C2=A0=0A1. Error Description=0A=C2=A0=0AThe error description f= ield provides information to the software developer and is not meant to be = shown to the end user. As such, there is no desire to provide international= ization support for this field. Hence, it has a similar characteristic as t= he HTTP 'Reason-Phrase. =0A=C2=A0=0Ahttp://greenbytes.de/tech/webdav/draft-= ietf-httpbis-p1-messaging-latest.html#reason.phrase says=0A=C2=A0=0A"=0AThe= Reason Phrase exists for the sole purpose of providing a textual descripti= on associated with the numeric status code, out of deference to earlier Int= ernet application protocols that were more frequently used with interactive= text clients. A client SHOULD ignore the content of the Reason Phrase.=0A= =C2=A0=0AReason-Phrase=C2=A0 =3D *( HTAB / SP / VCHAR / obs-text ) "=0A=C2= =A0=0AWe can use something similar for the error description field and even= simplify it further by omitting HTAB and obs-text:=0A=C2=A0=0A=C2=A0 error= -desc=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "error_description" "=3D" *( SP / V= CHAR )=0A=C2=A0=0A2. Scope=0A=C2=A0=0AThe scope field is yet another item t= hat will not be shown to the user and it serves the purpose of an identifie= r for authorization comparison. So, we don't need to have any international= ization support here either. =0A=C2=A0=0AThe suggestion is to re-use the 't= oken ABNF syntax from the HTTP spec:=0Ahttp://greenbytes.de/tech/webdav/dra= ft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.3=0A=C2=A0=0A3. Au= thorization Request Header Field=0A=C2=A0=0AFinally, there is the authoriza= tion request header field where we have to decide how we want to deal with = extensions. =0AThe current specification says: =0A=C2=A0=0A=C2=A0 credentia= ls =3D "Bearer" 1*SP ( b64token / #auth-param )=0A=C2=A0=0AThis means that = we can have either a base64 opaque blob or a parameter like syntax (but not= both). =0A=C2=A0=0AAn example of the b64token is =0A=C2=A0=0AAuthorization= : Bearer vF9dft4qmT=0A=C2=A0=0Aand an example of the auth-param usage is=0A= =C2=A0=0AAuthorization: Bearer t=3DvF9dft4qmT=0A=C2=A0=0AWith an opaque blo= b extensibility is limited and for this reason, I guess, Mike had provided = the additional option of auth-parameter. =0A=C2=A0=0AIf we want to allow ex= tensibility then we have to go for the auth-param approach. If we only use = the auth-param (without the b64token) then there may be an issue with alrea= dy existing implementations. We will have to double-check. =0A=C2=A0=0AThen= , there is the possibility to provide two ways to encode the same informati= on, namely either as a base64 blob and in the auth-parameter style. (In a s= ingle protocol run one would obviously only use one or the other.)=0A=C2=A0= =0AIf we define the auth-param then we have to also provide information on = what it actually is. We cannot leave that out of scope. =0A=C2=A0=0ACiao=0A= Hannes=0A=C2=A0=0A_______________________________________________=0AOAuth m= ailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth= =0A=C2=A0=0A_______________________________________________=0AOAuth mailing= list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1929416670-1318610914=:92931 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A
Scope has to be defined in the core OAuth spec.  I think it's a mist= ake to talk about it in regard to the Bearer token spec specifically.

I think removing the auth-par= am usage is workable.  Then if we need extensibility defining a new sc= heme can do that.  It's a bit more work that way if needed, but it's c= lean.

-bill

From: Mike Jones <Michael.Jones@microsoft.com>
To: Hannes Tschofenig <hannes.t= schofenig@gmx.net>; OAuth WG <oauth@ietf.org>
Sent: Friday, October 14, 2011 8:42 AM
<= b>Subject: Re: [OAUTH-WG] dra= ft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

=0A
=0A=0A =0A =0A=0A=0A
=0A
= =0A
Thanks for the useful discussio= n and the write-up, Hannes.  For context, Hannes and I discussed how t= o resolve the remaining Bearer spec issues in a manner that meets the needs= of implementations and will not generate objections during=0A the IESG or = IETF Last Call reviews.  A few additional comments=E2=80=A6
=0A<= div class=3D"yiv1413577610MsoPlainText">  
=0A
1.  Error Description =E2=80=93 Nothing to add = to Hannes=E2=80=99 write-up.
=0A
 
=0A
2.  Scop= e =E2=80=93 I was planning to allow a broader set of ASCII characters than = the =E2=80=9Ctoken=E2=80=9D set, as these characters are inadequate for the= use of URIs/URLs as scope elements.  In particular, scope elements ne= ed to permit the full sets of=0A =E2=80=9Creserved=E2=80= =9D and =E2=80=9Cunreserved=E2=80=9D=0Acharacter= s in RFC 3986.  The draft I am working on will say that sco= pe is a space separated set of elements, where the elements consist of one = or more characters from the union of the =E2=80=9Creserved=E2=80=9D and =E2= =80=9Cunreserved=E2=80=9D=0A sets.
=0A
 
=0A
3. = ; Authorization Request Header Field =E2=80=93 We agreed on the call that w= e=E2=80=99re not doing implementers any favors by allowing both the b64toke= n and #auth-param syntaxes, and that it is better to specify one or the oth= er.  Since existing practice=0A corresponds to the b4token syntax, the= choice is clear which to specify.  Thus, it was a mistake to introduc= e the #auth-param choice in draft 9.  It will be removed in draft 10, = which is shortly forthcoming.
=0A
 
=0A
  =             &nb= sp;            =             &nb= sp;            =         -- Mike
=0A
 
=0A
-----Original Message-----
=0AFrom: oauth-bounces@ietf.org [mai= lto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
=0ASent: Frid= ay, October 14, 2011 5:25 AM
=0ATo: OAuth WG
=0ASubject: [OAUTH-WG] d= raft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions
= =0A
 
=0A
Hi all,
=0A
 
=0A
I had = a discussion with Mike and Julian to hear what to discuss the open issues w= ith the OAuth Bearer Token draft. Below is a short writeup of my impression= s.=0A
=0A
 
=0A1. Error Description
=0A
 
=0A
The error description field provides information to the s= oftware developer and is not meant to be shown to the end user. As such, th= ere is no desire to provide internationalization support for this field. He= nce, it has a similar characteristic=0A as the HTTP 'Reason-Phrase.
= =0A
 
=0A
http:= //greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rea= son.phrase=0A says
=0A
 
=0A
"
=0A<= div class=3D"yiv1413577610MsoPlainText">The Reason Phrase exists for the so= le purpose of providing a textual description associated with the numeric s= tatus code, out of deference to earlier Internet application protocols that= were more frequently used with interactive text=0A clients. A client SHOUL= D ignore the content of the Reason Phrase.
=0A
 
=0A
Reason-Phrase  =3D *( HTAB / SP / VCHAR / obs-text ) "
=0A
 
=0A
We can use something similar for the error description f= ield and even simplify it further by omitting HTAB and obs-text:
=0A<= div class=3D"yiv1413577610MsoPlainText">  
=0A
  error-desc      =3D = "error_description" "=3D" *( SP / VCHAR )
=0A
 
=0A
= 2. Scope
=0A
 
= =0A
The scope field is yet another = item that will not be shown to the user and it serves the purpose of an ide= ntifier for authorization comparison. So, we don't need to have any interna= tionalization support here either.=0A
=0A
 
=0A
The = suggestion is to re-use the 'token ABNF syntax from the HTTP spec:
= =0A
http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-mess= aging-latest.html#rfc.section.3.2.3
=0A
 
=0A
3. Authorization Request Header Field
=0A
 
=0A
Finally, there is the authorization request header field where we have to = decide how we want to deal with extensions.=0A
=0A
The current specification says:
=0A
 
=0A
  credentials =3D "Bearer" 1*SP ( b64token / #auth-param= )
=0A
 
=0A
This means that we can have either a ba= se64 opaque blob or a parameter like syntax (but not both).=0A
=0A  
=0A
An example of the b64token is
=0A
 
=0A
Authorization: Bearer vF9dft4qmT
=0A
 
=0A
and an example of the auth-param usage is
=0A
 
=0A
Authorization: Bearer t=3DvF9dft4qmT
=0A
 
=0A
With= an opaque blob extensibility is limited and for this reason, I guess, Mike= had provided the additional option of auth-parameter.=0A
=0A
 
=0A
If we want to allow extensibility then we have to go for th= e auth-param approach. If we only use the auth-param (without the b64token)= then there may be an issue with already existing implementations. We will = have to double-check.=0A
=0A
=  
=0A
Then, there is th= e possibility to provide two ways to encode the same information, namely ei= ther as a base64 blob and in the auth-parameter style. (In a single protoco= l run one would obviously only use one or the other.)
=0A
 
=0A
If we define the auth-param then we have to also provide info= rmation on what it actually is. We cannot leave that out of scope.=0A
= =0A
 
=0A
Ciao
=0A
Hannes
=0A
  =0A
___________________________= ____________________
=0A
OAut= h mailing list
=0A
OA= uth@ietf.org
=0A
<= a rel=3D"nofollow" target=3D"_blank" href=3D"https://www.ietf.org/mailman/l= istinfo/oauth">https= ://www.ietf.org/mailman/listinfo/oauth
=0A
 
=0A
=0A

__= _____________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth


--0-1929416670-1318610914=:92931-- From Michael.Jones@microsoft.com Fri Oct 14 09:51:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B09521F8A4E for ; Fri, 14 Oct 2011 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.183 X-Spam-Level: X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tsv-t7hB1Q+m for ; Fri, 14 Oct 2011 09:51:47 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 03EE321F8A80 for ; Fri, 14 Oct 2011 09:51:47 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Oct 2011 09:51:23 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 09:51:22 -0700 From: Mike Jones To: Eran Hammer-Lahav , Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAANS7QAAIF9KA= Date: Fri, 14 Oct 2011 16:51:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23C7BF@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723452604B8EDD@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B8EDD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C23C7BFTK5EX14MBXC284r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:51:50 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C23C7BFTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am fine with this scope character set restriction also being added to the= core spec. As to your second comment, you'll find that the b64token definition already prov= ides a character set restriction (as you suggest is needed). -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, October 14, 2011 8:55 AM To: Mike Jones; Hannes Tschofenig; OAuth WG Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions This is not sufficient. For scope, if you are going to restrict the allowed characters, you must ei= ther specify how to encode all other values to fit the field, or we must mo= ve this restriction to the v2 specification so that no encoding is required= . For the token, you need to also define allowed token values so that they wi= ll fit in the header without encode, or specify an encoding scheme. The MAC= token restricts token values (called MAC identifier) to %x20-21 / %x23-5B = / %x5D-7E (any printable ASCII character except for " and \). EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Friday, October 14, 2011 8:43 AM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Thanks for the useful discussion and the write-up, Hannes. For context, Ha= nnes and I discussed how to resolve the remaining Bearer spec issues in a m= anner that meets the needs of implementations and will not generate objecti= ons during the IESG or IETF Last Call reviews. A few additional comments..= . 1. Error Description - Nothing to add to Hannes' write-up. 2. Scope - I was planning to allow a broader set of ASCII characters than = the "token" set, as these characters are inadequate for the use of URIs/URL= s as scope elements. In particular, scope elements need to permit the full= sets of "reserved" and "u= nreserved" characters in R= FC 3986. The draft I am working on wil= l say that scope is a space separated set of elements, where the elements c= onsist of one or more characters from the union of the "reserved" and "unre= served" sets. 3. Authorization Request Header Field - We agreed on the call that we're n= ot doing implementers any favors by allowing both the b64token and #auth-pa= ram syntaxes, and that it is better to specify one or the other. Since exi= sting practice corresponds to the b4token syntax, the choice is clear which= to specify. Thus, it was a mistake to introduce the #auth-param choice in= draft 9. It will be removed in draft 10, which is shortly forthcoming. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Hanne= s Tschofenig Sent: Friday, October 14, 2011 5:25 AM To: OAuth WG Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed R= esolutions Hi all, I had a discussion with Mike and Julian to hear what to discuss the open is= sues with the OAuth Bearer Token draft. Below is a short writeup of my impr= essions. 1. Error Description The error description field provides information to the software developer = and is not meant to be shown to the end user. As such, there is no desire t= o provide internationalization support for this field. Hence, it has a simi= lar characteristic as the HTTP 'Reason-Phrase. http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.htm= l#reason.phrase says " The Reason Phrase exists for the sole purpose of providing a textual descri= ption associated with the numeric status code, out of deference to earlier = Internet application protocols that were more frequently used with interact= ive text clients. A client SHOULD ignore the content of the Reason Phrase. Reason-Phrase =3D *( HTAB / SP / VCHAR / obs-text ) " We can use something similar for the error description field and even simpl= ify it further by omitting HTAB and obs-text: error-desc =3D "error_description" "=3D" *( SP / VCHAR ) 2. Scope The scope field is yet another item that will not be shown to the user and = it serves the purpose of an identifier for authorization comparison. So, we= don't need to have any internationalization support here either. The suggestion is to re-use the 'token ABNF syntax from the HTTP spec: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.htm= l#rfc.section.3.2.3 3. Authorization Request Header Field Finally, there is the authorization request header field where we have to d= ecide how we want to deal with extensions. The current specification says: credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) This means that we can have either a base64 opaque blob or a parameter like= syntax (but not both). An example of the b64token is Authorization: Bearer vF9dft4qmT and an example of the auth-param usage is Authorization: Bearer t=3DvF9dft4qmT With an opaque blob extensibility is limited and for this reason, I guess, = Mike had provided the additional option of auth-parameter. If we want to allow extensibility then we have to go for the auth-param app= roach. If we only use the auth-param (without the b64token) then there may = be an issue with already existing implementations. We will have to double-c= heck. Then, there is the possibility to provide two ways to encode the same infor= mation, namely either as a base64 blob and in the auth-parameter style. (In= a single protocol run one would obviously only use one or the other.) If we define the auth-param then we have to also provide information on wha= t it actually is. We cannot leave that out of scope. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435C23C7BFTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am fine with this sc= ope character set restriction also being added to the core spec.=

 

As to your second comm= ent, you’ll find that the b64token definition already provi= des a character set restriction (as you suggest is needed).

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      -- Mike

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Friday, October 14, 2011 8:55 AM
To: Mike Jones; Hannes Tschofenig; OAuth WG
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &= amp; Proposed Resolutions

 

This is not sufficient= .

 

For scope, if you are = going to restrict the allowed characters, you must either specify how to en= code all other values to fit the field, or we must move this restriction to= the v2 specification so that no encoding is required.

 

For the token, you nee= d to also define allowed token values so that they will fit in the header w= ithout encode, or specify an encoding scheme. The MAC token restricts token= values (called MAC identifier) to %x20-21 / %x23-5B / %x5D-7E (any printable ASCII character except for " and \= ).

 

EHL<= /p>

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, October 14, 2011 8:43 AM
To: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &= amp; Proposed Resolutions

 

Thanks for the useful discussion and the write-up= , Hannes.  For context, Hannes and I discussed how to resolve the rema= ining Bearer spec issues in a manner that meets the needs of implementation= s and will not generate objections during the IESG or IETF Last Call reviews.  A few additional comments…=

 

1.  Error Description – Nothing to add= to Hannes’ write-up.

 

2.  Scope – I was planning to allow a = broader set of ASCII characters than the “token” set, as these = characters are inadequate for the use of URIs/URLs as scope elements. = In particular, scope elements need to permit the full sets of “reserved= ” and “unreserved” characters in RFC 3986.  The draft I am working on will say that scope is a space separate= d set of elements, where the elements consist of one or more characters fro= m the union of the “reserved” and “unreserved” sets.

 

3.  Authorization Request Header Field ̵= 1; We agreed on the call that we’re not doing implementers any favors= by allowing both the b64token and #auth-param syntaxes, and that it is bet= ter to specify one or the other.  Since existing practice corresponds to the b4token syntax, the choice is clear which to specify.&n= bsp; Thus, it was a mistake to introduce the #auth-param choice in draft 9.=   It will be removed in draft 10, which is shortly forthcoming.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; -- Mike

 

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions

 

Hi all,

 

I had a discussion with Mike and Julian to hear w= hat to discuss the open issues with the OAuth Bearer Token draft. Below is = a short writeup of my impressions.

 

1. Error Description

 

The error description field provides information = to the software developer and is not meant to be shown to the end user. As = such, there is no desire to provide internationalization support for this f= ield. Hence, it has a similar characteristic as the HTTP 'Reason-Phrase.

 

http://greenbytes.de/tech/webdav/draft-iet= f-httpbis-p1-messaging-latest.html#reason.phrase says

 

"

The Reason Phrase exists for the sole purpose of = providing a textual description associated with the numeric status code, ou= t of deference to earlier Internet application protocols that were more fre= quently used with interactive text clients. A client SHOULD ignore the content of the Reason Phrase.

 

Reason-Phrase  =3D *( HTAB / SP / VCHAR / ob= s-text ) "

 

We can use something similar for the error descri= ption field and even simplify it further by omitting HTAB and obs-text:

 

  error-desc      = =3D "error_description" "=3D" *( SP / VCHAR )

 

2. Scope

 

The scope field is yet another item that will not= be shown to the user and it serves the purpose of an identifier for author= ization comparison. So, we don't need to have any internationalization supp= ort here either.

 

The suggestion is to re-use the 'token ABNF synta= x from the HTTP spec:

http://greenbytes.de/tech/webdav/draft= -ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.3

 

3. Authorization Request Header Field<= /p>

 

Finally, there is the authorization request heade= r field where we have to decide how we want to deal with extensions.

The current specification says:

 

  credentials =3D "Bearer" 1*SP ( = b64token / #auth-param )

 

This means that we can have either a base64 opaqu= e blob or a parameter like syntax (but not both).

 

An example of the b64token is

 

Authorization: Bearer vF9dft4qmT

 

and an example of the auth-param usage is

 

Authorization: Bearer t=3DvF9dft4qmT

 

With an opaque blob extensibility is limited and = for this reason, I guess, Mike had provided the additional option of auth-p= arameter.

 

If we want to allow extensibility then we have to= go for the auth-param approach. If we only use the auth-param (without the= b64token) then there may be an issue with already existing implementations= . We will have to double-check.

 

Then, there is the possibility to provide two way= s to encode the same information, namely either as a base64 blob and in the= auth-parameter style. (In a single protocol run one would obviously only u= se one or the other.)

 

If we define the auth-param then we have to also = provide information on what it actually is. We cannot leave that out of sco= pe.

 

Ciao

Hannes

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org=

https://www.ie= tf.org/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B16804296739435C23C7BFTK5EX14MBXC284r_-- From julian.reschke@gmx.de Fri Oct 14 09:56:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C9421F8BA7 for ; Fri, 14 Oct 2011 09:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeXRgijDG1u1 for ; Fri, 14 Oct 2011 09:56:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 98C4121F8B55 for ; Fri, 14 Oct 2011 09:56:44 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2011 16:56:43 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp011) with SMTP; 14 Oct 2011 18:56:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+X5jFSZgiXTjRwMlLjuDhX0LIxELA8tVLcuSoyhG foJmX0Q60JvIEj Message-ID: <4E9869C7.7050406@gmx.de> Date: Fri, 14 Oct 2011 18:56:39 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E985AB2.10201@gmx.de> <4E985EFF.8080807@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23C756@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23C756@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:56:45 -0000 On 2011-10-14 18:46, Mike Jones wrote: > Indeed, recognizing that you're right that "you can't do that" with the current syntax, we decided to change scope to quoted-string so that it is compatible with HTTPbis and add the restriction that no "\" quoting may be present in the string (to simplify implementations). > ... That's better, but I still believe that making up special rules is not productive. Just stick with the base syntax. If a "\" appears in a quoted-string, it means what it means, and recipients should be able to deal with it. Best regards, Julian From eran@hueniverse.com Fri Oct 14 10:25:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F6521F8C3A for ; Fri, 14 Oct 2011 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DroAVVHf8wgL for ; Fri, 14 Oct 2011 10:25:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id B10DE21F8C5F for ; Fri, 14 Oct 2011 10:25:00 -0700 (PDT) Received: (qmail 4546 invoked from network); 14 Oct 2011 17:24:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Oct 2011 17:24:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 14 Oct 2011 10:24:55 -0700 From: Eran Hammer-Lahav To: Mike Jones , Hannes Tschofenig , OAuth WG Date: Fri, 14 Oct 2011 10:24:26 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAANS7QAAIF9KAAATErQA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452604B8F06@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723452604B8EDD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739435C23C7BF@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23C7BF@TK5EX14MBXC284.redmond.corp.microsoft.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_90C41DD21FB7C64BB94121FBBC2E723452604B8F06P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:25:04 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723452604B8F06P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Relying on b64token is not enough because you are only restricting the head= er syntax, not the other methods. Also, you are not restricting the server = from issuing other values, in which case the client will need to figure out= how to use the header with those values. My point is that you need to expl= icitly define the allowed range for tokens. Saying they must comply with th= e b64token rule is enough, just not enough to leave it implied via the head= er definition. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, October 14, 2011 9:51 AM To: Eran Hammer-Lahav; Hannes Tschofenig; OAuth WG Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions I am fine with this scope character set restriction also being added to the= core spec. As to your second comment, you'll find that the b64token definition already prov= ides a character set restriction (as you suggest is needed). -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, October 14, 2011 8:55 AM To: Mike Jones; Hannes Tschofenig; OAuth WG Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions This is not sufficient. For scope, if you are going to restrict the allowed characters, you must ei= ther specify how to encode all other values to fit the field, or we must mo= ve this restriction to the v2 specification so that no encoding is required= . For the token, you need to also define allowed token values so that they wi= ll fit in the header without encode, or specify an encoding scheme. The MAC= token restricts token values (called MAC identifier) to %x20-21 / %x23-5B = / %x5D-7E (any printable ASCII character except for " and \). EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Friday, October 14, 2011 8:43 AM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Thanks for the useful discussion and the write-up, Hannes. For context, Ha= nnes and I discussed how to resolve the remaining Bearer spec issues in a m= anner that meets the needs of implementations and will not generate objecti= ons during the IESG or IETF Last Call reviews. A few additional comments..= . 1. Error Description - Nothing to add to Hannes' write-up. 2. Scope - I was planning to allow a broader set of ASCII characters than = the "token" set, as these characters are inadequate for the use of URIs/URL= s as scope elements. In particular, scope elements need to permit the full= sets of "reserved" and "u= nreserved" characters in R= FC 3986. The draft I am working on wil= l say that scope is a space separated set of elements, where the elements c= onsist of one or more characters from the union of the "reserved" and "unre= served" sets. 3. Authorization Request Header Field - We agreed on the call that we're n= ot doing implementers any favors by allowing both the b64token and #auth-pa= ram syntaxes, and that it is better to specify one or the other. Since exi= sting practice corresponds to the b4token syntax, the choice is clear which= to specify. Thus, it was a mistake to introduce the #auth-param choice in= draft 9. It will be removed in draft 10, which is shortly forthcoming. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Hanne= s Tschofenig Sent: Friday, October 14, 2011 5:25 AM To: OAuth WG Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed R= esolutions Hi all, I had a discussion with Mike and Julian to hear what to discuss the open is= sues with the OAuth Bearer Token draft. Below is a short writeup of my impr= essions. 1. Error Description The error description field provides information to the software developer = and is not meant to be shown to the end user. As such, there is no desire t= o provide internationalization support for this field. Hence, it has a simi= lar characteristic as the HTTP 'Reason-Phrase. http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.htm= l#reason.phrase says " The Reason Phrase exists for the sole purpose of providing a textual descri= ption associated with the numeric status code, out of deference to earlier = Internet application protocols that were more frequently used with interact= ive text clients. A client SHOULD ignore the content of the Reason Phrase. Reason-Phrase =3D *( HTAB / SP / VCHAR / obs-text ) " We can use something similar for the error description field and even simpl= ify it further by omitting HTAB and obs-text: error-desc =3D "error_description" "=3D" *( SP / VCHAR ) 2. Scope The scope field is yet another item that will not be shown to the user and = it serves the purpose of an identifier for authorization comparison. So, we= don't need to have any internationalization support here either. The suggestion is to re-use the 'token ABNF syntax from the HTTP spec: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.htm= l#rfc.section.3.2.3 3. Authorization Request Header Field Finally, there is the authorization request header field where we have to d= ecide how we want to deal with extensions. The current specification says: credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) This means that we can have either a base64 opaque blob or a parameter like= syntax (but not both). An example of the b64token is Authorization: Bearer vF9dft4qmT and an example of the auth-param usage is Authorization: Bearer t=3DvF9dft4qmT With an opaque blob extensibility is limited and for this reason, I guess, = Mike had provided the additional option of auth-parameter. If we want to allow extensibility then we have to go for the auth-param app= roach. If we only use the auth-param (without the b64token) then there may = be an issue with already existing implementations. We will have to double-c= heck. Then, there is the possibility to provide two ways to encode the same infor= mation, namely either as a base64 blob and in the auth-parameter style. (In= a single protocol run one would obviously only use one or the other.) If we define the auth-param then we have to also provide information on wha= t it actually is. We cannot leave that out of scope. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723452604B8F06P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Relying on b64token is not enough because you are only restri= cting the header syntax, not the other methods. Also, you are not restricti= ng the server from issuing other values, in which case the client will need= to figure out how to use the header with those values. My point is that yo= u need to explicitly define the allowed range for tokens. Saying they must = comply with the b64token rule is enough, just not enough to leave it implie= d via the header definition.

 

= EHL

 

From: Mike Jones [mailto:Michael.Jones@microsoft.co= m]
Sent: Friday, October 14, 2011 9:51 AM
To: Eran Ham= mer-Lahav; Hannes Tschofenig; OAuth WG
Subject: RE: [OAUTH-WG] dr= aft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

 

I am fine with this scope chara= cter set restriction also being added to the core spec.

 

As to your second = comment, you’ll find that the b64token definition already p= rovides a character set restriction (as you suggest is needed).<= /span>

 

 &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        -- Mike

<= p class=3DMsoNormal> <= /p>

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Se= nt: Friday, October 14, 2011 8:55 AM
To: Mike Jones; Hannes T= schofenig; OAuth WG
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-b= earer-09: Open Issues & Proposed Resolutions

 

This is not sufficient.

 

<= p class=3DMsoNormal>For scope, if you are goi= ng to restrict the allowed characters, you must either specify how to encod= e all other values to fit the field, or we must move this restriction to th= e v2 specification so that no encoding is required.

 

For the token, you nee= d to also define allowed token values so that they will fit in the header w= ithout encode, or specify an encoding scheme. The MAC token restricts token= values (called MAC identifier) to %x20-21 / %x23-5B / %x5D-7E (any printab= le ASCII character except for " and \).

 

EHL

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, October 14, 2011 8:43 AM
To:= Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-o= auth-v2-bearer-09: Open Issues & Proposed Resolutions=

 

Thanks for the useful discussion and the write-up, Hannes.  For= context, Hannes and I discussed how to resolve the remaining Bearer spec i= ssues in a manner that meets the needs of implementations and will not gene= rate objections during the IESG or IETF Last Call reviews.  A few addi= tional comments…

 

1.  Error Description – Nothing t= o add to Hannes’ write-up.

 

2.  Scope – I was plann= ing to allow a broader set of ASCII characters than the “token”= set, as these characters are inadequate for the use of URIs/URLs as scope = elements.  In particular, scope elements need to permit the full sets = of “reserv= ed” and “unreserved” characters in RFC 3986.  The draft I am working on will say tha= t scope is a space separated set of elements, where the elements consist of= one or more characters from the union of the “reserved” and &#= 8220;unreserved” sets.

&nb= sp;

3.  Authorization Request Header = Field – We agreed on the call that we’re not doing implementers= any favors by allowing both the b64token and #auth-param syntaxes, and tha= t it is better to specify one or the other.  Since existing practice c= orresponds to the b4token syntax, the choice is clear which to specify.&nbs= p; Thus, it was a mistake to introduce the #auth-param choice in draft 9.&n= bsp; It will be removed in draft 10, which is shortly forthcoming.

 

=             &nb= sp;            =             &nb= sp;            =           -- Mike

 

----= -Original Message-----
From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sen= t: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] = draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions<= /o:p>

 

Hi all,

 

I had a discussion with Mike and Julian to hear what to= discuss the open issues with the OAuth Bearer Token draft. Below is a shor= t writeup of my impressions.

&n= bsp;

1. Error Description

 

The erro= r description field provides information to the software developer and is n= ot meant to be shown to the end user. As such, there is no desire to provid= e internationalization support for this field. Hence, it has a similar char= acteristic as the HTTP 'Reason-Phrase.

 

http://greenbytes.de= /tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#reason.phrase says

 

"

The Reason= Phrase exists for the sole purpose of providing a textual description asso= ciated with the numeric status code, out of deference to earlier Internet a= pplication protocols that were more frequently used with interactive text c= lients. A client SHOULD ignore the content of the Reason Phrase.=

 

Re= ason-Phrase  =3D *( HTAB / SP / VCHAR / obs-text ) "

 

We c= an use something similar for the error description field and even simplify = it further by omitting HTAB and obs-text:

 

  error-desc &n= bsp;    =3D "error_description" "=3D" *(= SP / VCHAR )

 

2. Scope

&= nbsp;

The scope field is yet another item = that will not be shown to the user and it serves the purpose of an identifi= er for authorization comparison. So, we don't need to have any internationa= lization support here either.

&= nbsp;

The suggestion is to re-use the 'tok= en ABNF syntax from the HTTP spec:

http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-l= atest.html#rfc.section.3.2.3

 

3. Authorization Request He= ader Field

 

Finally, there is the authorization request header field= where we have to decide how we want to deal with extensions.

The current specification says:

 

  c= redentials =3D "Bearer" 1*SP ( b64token / #auth-param )

 

T= his means that we can have either a base64 opaque blob or a parameter like = syntax (but not both).

 

An example of the b64token is

 

Auth= orization: Bearer vF9dft4qmT

&nb= sp;

and an example of the auth-param usage= is

 

Authorization: Bearer t=3DvF9dft4qmT

 

With an opaque blo= b extensibility is limited and for this reason, I guess, Mike had provided = the additional option of auth-parameter.

 

If we want to allow exten= sibility then we have to go for the auth-param approach. If we only use the= auth-param (without the b64token) then there may be an issue with already = existing implementations. We will have to double-check.

 

Then, ther= e is the possibility to provide two ways to encode the same information, na= mely either as a base64 blob and in the auth-parameter style. (In a single = protocol run one would obviously only use one or the other.)

=

 

If we = define the auth-param then we have to also provide information on what it a= ctually is. We cannot leave that out of scope.

 

Ciao

=

Hannes

&= nbsp;

____________________________________= ___________

OAuth mailing list

OAuth@ietf.org=

https:= //www.ietf.org/mailman/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723452604B8F06P3PW5EX1MB01E_-- From hannes.tschofenig@gmx.net Fri Oct 14 11:14:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4034C21F8CB8 for ; Fri, 14 Oct 2011 11:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7KidxmIrfcM for ; Fri, 14 Oct 2011 11:14:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 856FC21F8C6B for ; Fri, 14 Oct 2011 11:13:58 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2011 18:13:57 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp061) with SMTP; 14 Oct 2011 20:13:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gYq9MyOygMtRYNFAs92VxijvrYJhBGI9uWZX1b6 JxHOkH1in8VWLs Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 14 Oct 2011 21:13:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4E7FD14D-3605-4B23-99A3-5F2B3CF813FF@gmx.net> References: <101476B6-E03C-4188-9DB4-176541FDC0C5@gmx.net> To: Bob Van Zant X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 18:14:08 -0000 Hi Bob,=20 the question is only how to provide extensibility then. You are then = essentially forced to know, because of pre-arrangements, what the = content of the blob is going to be.=20 Is that also fine for you?=20 On Oct 14, 2011, at 7:04 PM, Bob Van Zant wrote: > I'm in favor of removing the auth param option. It seems that half the > point of the Bearer token is to have a very simple way of passing > around opaque tokens. >=20 > If there are reasons for building a more feature-ful token with cool > parameters then let's bring about a new token type. For now I like the > brain dead simple Bearer: >=20 > credentials =3D "Bearer" 1*SP b64token >=20 > -Bob Ciao Hannes From Michael.Jones@microsoft.com Fri Oct 14 11:18:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E6121F8CC5 for ; Fri, 14 Oct 2011 11:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ii1QBLEqHMd for ; Fri, 14 Oct 2011 11:18:18 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 30CDE21F8CC3 for ; Fri, 14 Oct 2011 11:18:18 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Oct 2011 11:18:17 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 11:18:17 -0700 From: Mike Jones To: Hannes Tschofenig , Bob Van Zant Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AQHMip0WmyebLEkdsU6M7VYC1BiSYpV8JcAg Date: Fri, 14 Oct 2011 18:18:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23CA0D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <101476B6-E03C-4188-9DB4-176541FDC0C5@gmx.net> <4E7FD14D-3605-4B23-99A3-5F2B3CF813FF@gmx.net> In-Reply-To: <4E7FD14D-3605-4B23-99A3-5F2B3CF813FF@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 18:18:18 -0000 I think that William Mills already gave the best answer to the extensibilit= y question when he wrote: "I think removing the auth-param usage is workable. Then if we need extens= ibility defining a new scheme can do that. It's a bit more work that way i= f needed, but it's clean." Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Friday, October 14, 2011 11:14 AM To: Bob Van Zant Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Hi Bob,=20 the question is only how to provide extensibility then. You are then essent= ially forced to know, because of pre-arrangements, what the content of the = blob is going to be.=20 Is that also fine for you?=20 On Oct 14, 2011, at 7:04 PM, Bob Van Zant wrote: > I'm in favor of removing the auth param option. It seems that half the=20 > point of the Bearer token is to have a very simple way of passing=20 > around opaque tokens. >=20 > If there are reasons for building a more feature-ful token with cool=20 > parameters then let's bring about a new token type. For now I like the=20 > brain dead simple Bearer: >=20 > credentials =3D "Bearer" 1*SP b64token >=20 > -Bob Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Fri Oct 14 11:27:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D436E21F8BB3 for ; Fri, 14 Oct 2011 11:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.739 X-Spam-Level: X-Spam-Status: No, score=-101.739 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-RUzBTDB0sP for ; Fri, 14 Oct 2011 11:27:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 006C921F8BA9 for ; Fri, 14 Oct 2011 11:27:10 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2011 18:27:09 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp009) with SMTP; 14 Oct 2011 20:27:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gm9skwLygt5JeUS9Kjm821+mmTVA2s5eWS22tSd mju7Cg7OoOlN6W Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 14 Oct 2011 21:27:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 18:27:11 -0000 Hi Mike,=20 On Oct 14, 2011, at 6:42 PM, Mike Jones wrote: > 2. Scope =96 I was planning to allow a broader set of ASCII = characters than the =93token=94 set, as these characters are inadequate = for the use of URIs/URLs as scope elements. In particular, scope = elements need to permit the full sets of =93reserved=94 and =93unreserved=94= characters in RFC 3986. The draft I am working on will say that scope = is a space separated set of elements, where the elements consist of one = or more characters from the union of the =93reserved=94 and =93unreserved=94= sets. Wouldn't it be more useful to say that you either want some plaintext = values for the scope or URLs but not both? Also, if you want to introduce "standardized" (or reserved values) then = you have to=20 a) specify them now (with no ability to change them), or=20 b) prefix them. Ciao Hannes From Michael.Jones@microsoft.com Fri Oct 14 11:32:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB40521F8C59 for ; Fri, 14 Oct 2011 11:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozqSFGSCCRp2 for ; Fri, 14 Oct 2011 11:32:12 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCC121F8C53 for ; Fri, 14 Oct 2011 11:32:12 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Oct 2011 11:32:12 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 11:32:11 -0700 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAUZreAAA6h74A= Date: Fri, 14 Oct 2011 18:32:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net> In-Reply-To: <7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 18:32:12 -0000 The core spec says "The strings are defined by the authorization server" (s= ee http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3). I don't= see a reason to change that - especially this late in the game. I am not = introducing any standardized or reserved values. My intent is not require or even suggest that scope values should be URIs. = My intent is to not preclude them from being so. -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, October 14, 2011 11:27 AM To: Mike Jones Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Hi Mike,=20 On Oct 14, 2011, at 6:42 PM, Mike Jones wrote: > 2. Scope - I was planning to allow a broader set of ASCII characters tha= n the "token" set, as these characters are inadequate for the use of URIs/U= RLs as scope elements. In particular, scope elements need to permit the fu= ll sets of "reserved" and "unreserved" characters in RFC 3986. The draft I= am working on will say that scope is a space separated set of elements, wh= ere the elements consist of one or more characters from the union of the "r= eserved" and "unreserved" sets. Wouldn't it be more useful to say that you either want some plaintext value= s for the scope or URLs but not both? Also, if you want to introduce "standardized" (or reserved values) then you= have to=20 a) specify them now (with no ability to change them), or=20 b) prefix them. Ciao Hannes From hannes.tschofenig@gmx.net Fri Oct 14 12:28:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590A521F8D96 for ; Fri, 14 Oct 2011 12:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjgZ+5P0ykSt for ; Fri, 14 Oct 2011 12:28:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 34EC921F8D94 for ; Fri, 14 Oct 2011 12:28:30 -0700 (PDT) Received: (qmail invoked by alias); 14 Oct 2011 19:28:29 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp062) with SMTP; 14 Oct 2011 21:28:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ZS0FPoGYZx3aMrsSM+vqhz/uaa3aNsHmMJlzKbN Y223TQB5zB8Hny Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 14 Oct 2011 22:28:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:28:32 -0000 Hi Mike,=20 what values do we want to support?=20 We know that from the base specification we want a list of = space-delimited, case sensitive strings. We don't want support for internationalized character-sets.=20 Ciao Hannes On Oct 14, 2011, at 9:32 PM, Mike Jones wrote: > The core spec says "The strings are defined by the authorization = server" (see = http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3). I don't = see a reason to change that - especially this late in the game. I am = not introducing any standardized or reserved values. >=20 > My intent is not require or even suggest that scope values should be = URIs. My intent is to not preclude them from being so. >=20 > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Friday, October 14, 2011 11:27 AM > To: Mike Jones > Cc: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & = Proposed Resolutions >=20 > Hi Mike,=20 >=20 > On Oct 14, 2011, at 6:42 PM, Mike Jones wrote: >=20 >> 2. Scope - I was planning to allow a broader set of ASCII characters = than the "token" set, as these characters are inadequate for the use of = URIs/URLs as scope elements. In particular, scope elements need to = permit the full sets of "reserved" and "unreserved" characters in RFC = 3986. The draft I am working on will say that scope is a space = separated set of elements, where the elements consist of one or more = characters from the union of the "reserved" and "unreserved" sets. >=20 > Wouldn't it be more useful to say that you either want some plaintext = values for the scope or URLs but not both? >=20 > Also, if you want to introduce "standardized" (or reserved values) = then you have to=20 > a) specify them now (with no ability to change them), or=20 > b) prefix them. >=20 > Ciao > Hannes >=20 >=20 From Michael.Jones@microsoft.com Fri Oct 14 12:40:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEDA21F8D6E for ; Fri, 14 Oct 2011 12:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjzt03AYwTLx for ; Fri, 14 Oct 2011 12:40:36 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 7998621F8D6D for ; Fri, 14 Oct 2011 12:40:31 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Oct 2011 12:40:30 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Fri, 14 Oct 2011 12:40:30 -0700 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAUZreAAA6h74D//5wXAIAAcimw Date: Fri, 14 Oct 2011 19:40:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com> <89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> In-Reply-To: <89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:40:37 -0000 Any strings that the Authorization Server chooses to define meanings for -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, October 14, 2011 12:28 PM To: Mike Jones Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Hi Mike,=20 what values do we want to support?=20 We know that from the base specification we want a list of space-delimited,= case sensitive strings. We don't want support for internationalized character-sets.=20 Ciao Hannes On Oct 14, 2011, at 9:32 PM, Mike Jones wrote: > The core spec says "The strings are defined by the authorization server" = (see http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3). I don= 't see a reason to change that - especially this late in the game. I am no= t introducing any standardized or reserved values. >=20 > My intent is not require or even suggest that scope values should be URIs= . My intent is to not preclude them from being so. >=20 > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Friday, October 14, 2011 11:27 AM > To: Mike Jones > Cc: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Prop= osed Resolutions >=20 > Hi Mike,=20 >=20 > On Oct 14, 2011, at 6:42 PM, Mike Jones wrote: >=20 >> 2. Scope - I was planning to allow a broader set of ASCII characters th= an the "token" set, as these characters are inadequate for the use of URIs/= URLs as scope elements. In particular, scope elements need to permit the f= ull sets of "reserved" and "unreserved" characters in RFC 3986. The draft = I am working on will say that scope is a space separated set of elements, w= here the elements consist of one or more characters from the union of the "= reserved" and "unreserved" sets. >=20 > Wouldn't it be more useful to say that you either want some plaintext val= ues for the scope or URLs but not both? >=20 > Also, if you want to introduce "standardized" (or reserved values) then y= ou have to=20 > a) specify them now (with no ability to change them), or=20 > b) prefix them. >=20 > Ciao > Hannes >=20 >=20 From ve7jtb@ve7jtb.com Fri Oct 14 13:45:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E3921F8D02 for ; Fri, 14 Oct 2011 13:45:05 -0700 (PDT) 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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qKYudlxYrgF for ; Fri, 14 Oct 2011 13:45:04 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86A5C21F8AFC for ; Fri, 14 Oct 2011 13:45:04 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1763398ggn.31 for ; Fri, 14 Oct 2011 13:45:04 -0700 (PDT) Received: by 10.236.129.238 with SMTP id h74mr14468820yhi.99.1318625104038; Fri, 14 Oct 2011 13:45:04 -0700 (PDT) Received: from [192.168.1.213] ([190.22.67.212]) by mx.google.com with ESMTPS id d5sm6506732yhl.19.2011.10.14.13.45.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 13:45:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_B3ADD970-CD74-4109-88CB-F5E3889DBDC8"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23CA0D@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 14 Oct 2011 17:44:54 -0300 Message-Id: <80C4604C-85CB-4A0D-820C-A780877DEF2E@ve7jtb.com> References: <101476B6-E03C-4188-9DB4-176541FDC0C5@gmx.net> <4E7FD14D-3605-4B23-99A3-5F2B3CF813FF@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CA0D@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 20:45:05 -0000 --Apple-Mail=_B3ADD970-CD74-4109-88CB-F5E3889DBDC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree that is the cleanest. John B. On 2011-10-14, at 3:18 PM, Mike Jones wrote: > I think that William Mills already gave the best answer to the = extensibility question when he wrote: > "I think removing the auth-param usage is workable. Then if we need = extensibility defining a new scheme can do that. It's a bit more work = that way if needed, but it's clean." >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Hannes Tschofenig > Sent: Friday, October 14, 2011 11:14 AM > To: Bob Van Zant > Cc: OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & = Proposed Resolutions >=20 > Hi Bob,=20 >=20 > the question is only how to provide extensibility then. You are then = essentially forced to know, because of pre-arrangements, what the = content of the blob is going to be.=20 >=20 > Is that also fine for you?=20 >=20 > On Oct 14, 2011, at 7:04 PM, Bob Van Zant wrote: >=20 >> I'm in favor of removing the auth param option. It seems that half = the=20 >> point of the Bearer token is to have a very simple way of passing=20 >> around opaque tokens. >>=20 >> If there are reasons for building a more feature-ful token with cool=20= >> parameters then let's bring about a new token type. For now I like = the=20 >> brain dead simple Bearer: >>=20 >> credentials =3D "Bearer" 1*SP b64token >>=20 >> -Bob >=20 > Ciao > Hannes >=20 > _______________________________________________ > 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 --Apple-Mail=_B3ADD970-CD74-4109-88CB-F5E3889DBDC8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEw MTQyMDQ0NTVaMCMGCSqGSIb3DQEJBDEWBBS5L6iQh5nvc4PHZKoncEHkmIrM4DCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQCZ39MoUOAV1Sv3DMvrCeuMmGgjgBBK2LUTADE+RiceMSNJhKQCa0Xf+nXA6TpUnCG11byEgOif olP47fmkB2r+g3dpQ6GvtaHH5jmvePT2NTsKU63eMrbUXJgivCY3w3YUkfutF/k+gCbnjd2p0wMZ 1TA81OkFBpbrOelL5avVzMlRE6KbH2AgbrPUT5qUHw9SffOP5ObyWhqMNjCiL0yjx4dAVILc4jUe HakknAIqJmIC88/z4Lm9mVluCjtN7J2rWMP03JF/MD98sZtZm39ul2DCpa0krfxazP8B2Hm1koQe XHq7yzaJuKa7XDVXRw5eQkAHz03UXhbGxmhlhLpPAAAAAAAA --Apple-Mail=_B3ADD970-CD74-4109-88CB-F5E3889DBDC8-- From hannes.tschofenig@nsn.com Sat Oct 15 05:14:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BA821F8B1A for ; Sat, 15 Oct 2011 05:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFSlMKKQhgBY for ; Sat, 15 Oct 2011 05:14:41 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id AD79A21F8B0B for ; Sat, 15 Oct 2011 05:14:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9FCEdRZ024421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Oct 2011 14:14:39 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9FCEb5m011347; Sat, 15 Oct 2011 14:14:38 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 15 Oct 2011 14:14:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Oct 2011 15:16:00 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAUZreAAA6h74D//5wXAIAAcimw///XqhA= References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Mike Jones" , "Hannes Tschofenig" X-OriginalArrivalTime: 15 Oct 2011 12:14:32.0671 (UTC) FILETIME=[FF1EE6F0:01CC8B33] Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 12:14:41 -0000 Hi Mike,=20 this is not specific enough. A string could be defined as " A string is a sequence of zero or more Unicode characters [UNICODE]. " (as in RFC 4627), or as " 8-bit binary data without a NUL (hex 00) termination " (as in RADIUS, RFC 2865).=20 In any case, we have to consider the constraints from the usage of "application/x-www-form-urlencoded". In our specific case this means that we have to get from the scope string to an octet sequence, which is allowed by application/x-www-form-urlencoded. Julian had pointed to this issue already (see mail from October 7th). If you want any string (with the exception of SP, which is the delimiter) then you have to choose an encoding that is able to represent Unicode in ASCII. There are a few choices and according to Julian the following options exist: a) RFC 5987 b) URI encoding to UTF-8 encoding (which is essentially like RFC 5987 but to omit the language part of the triple) c) JSON (with the problem that the "\" notation in the quoted-string) If you want to go along this route then I would suggest to go for (a) and to include a couple of examples (see Section 3.2.2 of RFC 5987 for examples). This is clearly better than inventing a new mechanism ourselves. The language tag is optional and RFC 5987 only requires parser support for UTF-8 and ISO-8859-1.=20 Ciao Hannes -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext Mike Jones Sent: Friday, October 14, 2011 10:40 PM To: Hannes Tschofenig Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Any strings that the Authorization Server chooses to define meanings for -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, October 14, 2011 12:28 PM To: Mike Jones Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Hi Mike,=20 what values do we want to support?=20 We know that from the base specification we want a list of space-delimited, case sensitive strings. We don't want support for internationalized character-sets.=20 Ciao Hannes On Oct 14, 2011, at 9:32 PM, Mike Jones wrote: > The core spec says "The strings are defined by the authorization server" (see http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3). I don't see a reason to change that - especially this late in the game. I am not introducing any standardized or reserved values. >=20 > My intent is not require or even suggest that scope values should be URIs. My intent is to not preclude them from being so. >=20 > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Friday, October 14, 2011 11:27 AM > To: Mike Jones > Cc: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions >=20 > Hi Mike,=20 >=20 > On Oct 14, 2011, at 6:42 PM, Mike Jones wrote: >=20 >> 2. Scope - I was planning to allow a broader set of ASCII characters than the "token" set, as these characters are inadequate for the use of URIs/URLs as scope elements. In particular, scope elements need to permit the full sets of "reserved" and "unreserved" characters in RFC 3986. The draft I am working on will say that scope is a space separated set of elements, where the elements consist of one or more characters from the union of the "reserved" and "unreserved" sets. >=20 > Wouldn't it be more useful to say that you either want some plaintext values for the scope or URLs but not both? >=20 > Also, if you want to introduce "standardized" (or reserved values) then you have to=20 > a) specify them now (with no ability to change them), or=20 > b) prefix them. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Sat Oct 15 05:20:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F115521F8B5D for ; Sat, 15 Oct 2011 05:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.488 X-Spam-Level: X-Spam-Status: No, score=-104.488 tagged_above=-999 required=5 tests=[AWL=-1.889, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8KbEp-rWU+j for ; Sat, 15 Oct 2011 05:20:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 08AB221F8B5B for ; Sat, 15 Oct 2011 05:20:21 -0700 (PDT) Received: (qmail invoked by alias); 15 Oct 2011 12:20:20 -0000 Received: from p5DCCB50E.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.181.14] by mail.gmx.net (mp015) with SMTP; 15 Oct 2011 14:20:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/0KVAMM7f0wTpH+A732MpZfmtQieI3J9m2MsqALG Yc7SQOPQ6cUPr6 Message-ID: <4E997A80.3000202@gmx.de> Date: Sat, 15 Oct 2011 14:20:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 12:20:23 -0000 On 2011-10-15 14:16, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Mike, > > this is not specific enough. A string could be defined as > " > A string is a sequence of zero or more Unicode characters [UNICODE]. > " > (as in RFC 4627), or as > " > 8-bit binary data without a NUL (hex 00) termination > " > (as in RADIUS, RFC 2865). > > In any case, we have to consider the constraints from the usage of > "application/x-www-form-urlencoded". In our specific case this means > that we have to get from the scope string to an octet sequence, which is > allowed by application/x-www-form-urlencoded. > > Julian had pointed to this issue already (see mail from October 7th). > > If you want any string (with the exception of SP, which is the > delimiter) then you have to choose an encoding that is able to represent > Unicode in ASCII. There are a few choices and according to Julian the > following options exist: > > a) RFC 5987 > b) URI encoding to UTF-8 encoding > (which is essentially like RFC 5987 but to omit the language part of the > triple) Actually, omitting both the charset and the language part, and hardwiring the encoding to UTF-8. > c) JSON (with the problem that the "\" notation in the quoted-string) > > If you want to go along this route then I would suggest to go for (a) > and to include a couple of examples (see Section 3.2.2 of RFC 5987 for > examples). This is clearly better than inventing a new mechanism > ourselves. The language tag is optional and RFC 5987 only requires > parser support for UTF-8 and ISO-8859-1. ...and for RFC5987bis we are discussing to restrict this to UTF-8 only... Best regards, Julian From Michael.Jones@microsoft.com Sat Oct 15 22:12:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC2921F8678 for ; Sat, 15 Oct 2011 22:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.698 X-Spam-Level: X-Spam-Status: No, score=-9.698 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA55U+-AQHZ3 for ; Sat, 15 Oct 2011 22:12:33 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id AD83D21F85B1 for ; Sat, 15 Oct 2011 22:12:33 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 15 Oct 2011 22:12:33 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Sat, 15 Oct 2011 22:12:33 -0700 From: Mike Jones To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "Hannes Tschofenig" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAUZreAAA6h74D//5wXAIAAcimw///XqhD//pNi4A== Date: Sun, 16 Oct 2011 05:12:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 05:12:34 -0000 In your note yesterday summarizing our proposed issue resolutions, you wrot= e "The scope field is yet another item that will not be shown to the user a= nd it serves the purpose of an identifier for authorization comparison. So,= we don't need to have any internationalization support here either." I'm therefore confused by your note below, Hannes, as it seems to me to con= tradict both your statement above. In particular, there's no need for Unic= ode encodings when internationalization isn't required. ASCII characters a= re fine for representing machine-readable scope elements that will never be= displayed to users. That's the approach I'm taking in draft 10. (And ind= eed, EVERY draft of the bearer token spec has specified only ASCII characte= rs, so this is nothing new...) -- Mike -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com= ]=20 Sent: Saturday, October 15, 2011 5:16 AM To: Mike Jones; Hannes Tschofenig Cc: OAuth WG Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Hi Mike,=20 this is not specific enough. A string could be defined as " A string is a sequence of zero or more Unicode characters [UNICODE]. " (as in RFC 4627), or as " 8-bit binary data without a NUL (hex 00) termination " (as in RADIUS, RFC 2865).=20 In any case, we have to consider the constraints from the usage of "applica= tion/x-www-form-urlencoded". In our specific case this means that we have t= o get from the scope string to an octet sequence, which is allowed by appli= cation/x-www-form-urlencoded. Julian had pointed to this issue already (see mail from October 7th). If you want any string (with the exception of SP, which is the delimiter) then you have to choose an encoding that is able to represent Un= icode in ASCII. There are a few choices and according to Julian the followi= ng options exist: a) RFC 5987 b) URI encoding to UTF-8 encoding (which is essentially like RFC 5987 but to omit the language part of the triple) c) JSON (with the problem that the "\" notation in the quoted-string) If you want to go along this route then I would suggest to go for (a) and t= o include a couple of examples (see Section 3.2.2 of RFC 5987 for examples)= . This is clearly better than inventing a new mechanism ourselves. The lang= uage tag is optional and RFC 5987 only requires parser support for UTF-8 an= d ISO-8859-1.=20 Ciao Hannes -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of e= xt Mike Jones Sent: Friday, October 14, 2011 10:40 PM To: Hannes Tschofenig Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Any strings that the Authorization Server chooses to define meanings for -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: Friday, October 14, 2011 12:28 PM To: Mike Jones Cc: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Hi Mike,=20 what values do we want to support?=20 We know that from the base specification we want a list of space-delimited,= case sensitive strings. We don't want support for internationalized character-sets.=20 Ciao Hannes On Oct 14, 2011, at 9:32 PM, Mike Jones wrote: > The core spec says "The strings are defined by the authorization server" (see http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3). I don't se= e a reason to change that - especially this late in the game. I am not int= roducing any standardized or reserved values. >=20 > My intent is not require or even suggest that scope values should be URIs. My intent is to not preclude them from being so. >=20 > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Friday, October 14, 2011 11:27 AM > To: Mike Jones > Cc: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions >=20 > Hi Mike, >=20 > On Oct 14, 2011, at 6:42 PM, Mike Jones wrote: >=20 >> 2. Scope - I was planning to allow a broader set of ASCII characters than the "token" set, as these characters are inadequate for the use of URI= s/URLs as scope elements. In particular, scope elements need to permit the= full sets of "reserved" and "unreserved" characters in RFC 3986. The draf= t I am working on will say that scope is a space separated set of elements,= where the elements consist of one or more characters from the union of the= "reserved" and "unreserved" sets. >=20 > Wouldn't it be more useful to say that you either want some plaintext values for the scope or URLs but not both? >=20 > Also, if you want to introduce "standardized" (or reserved values) then you have to=20 > a) specify them now (with no ability to change them), or > b) prefix them. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Sun Oct 16 03:43:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85E521F8A97 for ; Sun, 16 Oct 2011 03:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uj9HiZ5-Bxj for ; Sun, 16 Oct 2011 03:43:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DA58C21F8A7D for ; Sun, 16 Oct 2011 03:43:52 -0700 (PDT) Received: (qmail invoked by alias); 16 Oct 2011 10:43:50 -0000 Received: from p5DCCB50E.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.181.14] by mail.gmx.net (mp022) with SMTP; 16 Oct 2011 12:43:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19r7oNg/VBraqpNCSW1orD7InDWhAiqt2kfUtkP80 LNtbSHzr+IfHPw Message-ID: <4E9AB561.5060904@gmx.de> Date: Sun, 16 Oct 2011 12:43:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 10:44:00 -0000 On 2011-10-16 07:12, Mike Jones wrote: > In your note yesterday summarizing our proposed issue resolutions, you wrote "The scope field is yet another item that will not be shown to the user and it serves the purpose of an identifier for authorization comparison. So, we don't need to have any internationalization support here either." > > I'm therefore confused by your note below, Hannes, as it seems to me to contradict both your statement above. In particular, there's no need for Unicode encodings when internationalization isn't required. ASCII characters are fine for representing machine-readable scope elements that will never be displayed to users. That's the approach I'm taking in draft 10. (And indeed, EVERY draft of the bearer token spec has specified only ASCII characters, so this is nothing new...) Confused we are :-) The core spec doesn't restrict what can be in a scope (looking at ). Also, you wrote earlier on: > Any strings that the Authorization Server chooses to define meanings for Best regards, Julian From Michael.Jones@microsoft.com Sun Oct 16 09:44:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E30221F886A for ; Sun, 16 Oct 2011 09:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.754 X-Spam-Level: X-Spam-Status: No, score=-9.754 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuSYLCXQNR0d for ; Sun, 16 Oct 2011 09:44:35 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B03F521F87FA for ; Sun, 16 Oct 2011 09:44:35 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 16 Oct 2011 09:44:35 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0339.002; Sun, 16 Oct 2011 09:44:34 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyKh/E84FL2MRLXQ1OcfkfuKXpuHgAUZreAAA6h74D//5wXAIAAcimw///XqhD//pNi4IADtNqAgAARHJA= Date: Sun, 16 Oct 2011 16:44:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> In-Reply-To: <4E9AB561.5060904@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 16:44:36 -0000 As Eran wrote on 9/30, "The fact that the v2 spec allows a wide range of ch= aracters in scope was unintentional. The design was limited to allow simple= ASCII strings and URIs." -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Sunday, October 16, 2011 3:44 AM To: Mike Jones Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions On 2011-10-16 07:12, Mike Jones wrote: > In your note yesterday summarizing our proposed issue resolutions, you wr= ote "The scope field is yet another item that will not be shown to the user= and it serves the purpose of an identifier for authorization comparison. S= o, we don't need to have any internationalization support here either." > > I'm therefore confused by your note below, Hannes, as it seems to me=20 > to contradict both your statement above. In particular, there's no=20 > need for Unicode encodings when internationalization isn't required. =20 > ASCII characters are fine for representing machine-readable scope=20 > elements that will never be displayed to users. That's the approach=20 > I'm taking in draft 10. (And indeed, EVERY draft of the bearer token=20 > spec has specified only ASCII characters, so this is nothing new...) Confused we are :-) The core spec doesn't restrict what can be in a scope (looking at ). Also, you wrote earlier on: > Any strings that the Authorization Server chooses to define meanings for Best regards, Julian From julian.reschke@gmx.de Sun Oct 16 11:00:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B211321F8AD9 for ; Sun, 16 Oct 2011 11:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.349 X-Spam-Level: X-Spam-Status: No, score=-104.349 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfEewE6aM0ZF for ; Sun, 16 Oct 2011 11:00:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BDF8C21F8AD3 for ; Sun, 16 Oct 2011 11:00:21 -0700 (PDT) Received: (qmail invoked by alias); 16 Oct 2011 18:00:15 -0000 Received: from p5DCCB2CC.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.178.204] by mail.gmx.net (mp071) with SMTP; 16 Oct 2011 20:00:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX192f0stmj52J3uYm7Ol9sFmF9x4uFH5hjzM4dDPJt lQKbWHZhPdM+NQ Message-ID: <4E9B1BA6.2060704@gmx.de> Date: Sun, 16 Oct 2011 20:00:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 18:00:22 -0000 On 2011-10-16 18:44, Mike Jones wrote: > As Eran wrote on 9/30, "The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs." > ... I see. Thanks. Is this going to be clarified in -23? Best regards, Julian From eran@hueniverse.com Sun Oct 16 15:54:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D0121F8A95 for ; Sun, 16 Oct 2011 15:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I98dTXvWAsL1 for ; Sun, 16 Oct 2011 15:54:27 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id CB45221F8A80 for ; Sun, 16 Oct 2011 15:54:27 -0700 (PDT) Received: (qmail 3132 invoked from network); 16 Oct 2011 22:54:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Oct 2011 22:54:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 16 Oct 2011 15:54:26 -0700 From: Eran Hammer-Lahav To: Julian Reschke , Mike Jones Date: Sun, 16 Oct 2011 15:54:20 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyMLXar6ldGoIMwSEO2ZRLrILsLpgAKQ7zg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> In-Reply-To: <4E9B1BA6.2060704@gmx.de> 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] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 22:54:28 -0000 It's an open question for the list. EHL > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Sunday, October 16, 2011 11:00 AM > To: Mike Jones > Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG; > Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > Proposed Resolutions >=20 > On 2011-10-16 18:44, Mike Jones wrote: > > As Eran wrote on 9/30, "The fact that the v2 spec allows a wide range o= f > characters in scope was unintentional. The design was limited to allow si= mple > ASCII strings and URIs." > > ... >=20 > I see. Thanks. >=20 > Is this going to be clarified in -23? >=20 > Best regards, Julian From ve7jtb@ve7jtb.com Sun Oct 16 17:11:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739E321F84F5 for ; Sun, 16 Oct 2011 17:11:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVnJIfAxx74w for ; Sun, 16 Oct 2011 17:11:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7FE321F84D5 for ; Sun, 16 Oct 2011 17:11:58 -0700 (PDT) Received: by gyh20 with SMTP id 20so3040589gyh.31 for ; Sun, 16 Oct 2011 17:11:58 -0700 (PDT) Received: by 10.151.122.4 with SMTP id z4mr15630502ybm.76.1318810318136; Sun, 16 Oct 2011 17:11:58 -0700 (PDT) Received: from [10.10.1.58] ([209.118.182.66]) by mx.google.com with ESMTPS id l8sm7827255anb.1.2011.10.16.17.11.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Oct 2011 17:11:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: John Bradley In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 16 Oct 2011 17:11:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 00:11:59 -0000 Restricting it now in the core spec is going to save a lot of headaches = later. John B. On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: > It's an open question for the list. >=20 > EHL >=20 >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Sunday, October 16, 2011 11:00 AM >> To: Mike Jones >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG; >> Eran Hammer-Lahav >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >> Proposed Resolutions >>=20 >> On 2011-10-16 18:44, Mike Jones wrote: >>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide = range of >> characters in scope was unintentional. The design was limited to = allow simple >> ASCII strings and URIs." >>> ... >>=20 >> I see. Thanks. >>=20 >> Is this going to be clarified in -23? >>=20 >> Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Sun Oct 16 19:19:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E451F0C38 for ; Sun, 16 Oct 2011 19:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwdsASoo1CXH for ; Sun, 16 Oct 2011 19:19:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6EA1F0C36 for ; Sun, 16 Oct 2011 19:19:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1D94B21B0797; Sun, 16 Oct 2011 22:19:10 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 15EDA21B030A; Sun, 16 Oct 2011 22:19:10 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.101]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Sun, 16 Oct 2011 22:19:09 -0400 From: "Richer, Justin P." To: John Bradley , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AQHMjGFpkEkw94Idb0mUaXO7/pfvH5V/zFZP Date: Mon, 17 Oct 2011 02:19:09 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> In-Reply-To: <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 02:19:18 -0000 I think the limit makes sense, but then are tokens limited by the same rule= s? They need to live in all the same places (query parameters, headers, for= ms) that scopes do and would be subject to the same kinds of encoding woes = that scopes will. Or am I missing something obvious as to why this isn't a = problem for tokens (both bearer tokens and the public part of MAC tokens) b= ut is a problem for scope strings?=0A= =0A= -- Justin=0A= ________________________________________=0A= From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of John Bra= dley [ve7jtb@ve7jtb.com]=0A= Sent: Sunday, October 16, 2011 8:11 PM=0A= To: Eran Hammer-Lahav=0A= Cc: OAuth WG=0A= Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Pro= posed Resolutions=0A= =0A= Restricting it now in the core spec is going to save a lot of headaches lat= er.=0A= =0A= John B.=0A= On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote:=0A= =0A= > It's an open question for the list.=0A= >=0A= > EHL=0A= >=0A= >> -----Original Message-----=0A= >> From: Julian Reschke [mailto:julian.reschke@gmx.de]=0A= >> Sent: Sunday, October 16, 2011 11:00 AM=0A= >> To: Mike Jones=0A= >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG;=0A= >> Eran Hammer-Lahav=0A= >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &=0A= >> Proposed Resolutions=0A= >>=0A= >> On 2011-10-16 18:44, Mike Jones wrote:=0A= >>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide range o= f=0A= >> characters in scope was unintentional. The design was limited to allow s= imple=0A= >> ASCII strings and URIs."=0A= >>> ...=0A= >>=0A= >> I see. Thanks.=0A= >>=0A= >> Is this going to be clarified in -23?=0A= >>=0A= >> Best regards, Julian=0A= > _______________________________________________=0A= > OAuth mailing list=0A= > OAuth@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/oauth=0A= =0A= _______________________________________________=0A= OAuth mailing list=0A= OAuth@ietf.org=0A= https://www.ietf.org/mailman/listinfo/oauth=0A= From julian.reschke@gmx.de Mon Oct 17 01:32:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF3721F86FF for ; Mon, 17 Oct 2011 01:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.214 X-Spam-Level: X-Spam-Status: No, score=-104.214 tagged_above=-999 required=5 tests=[AWL=-1.615, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW1uLtPR4DZt for ; Mon, 17 Oct 2011 01:32:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 69F0421F87E2 for ; Mon, 17 Oct 2011 01:32:44 -0700 (PDT) Received: (qmail invoked by alias); 17 Oct 2011 08:32:41 -0000 Received: from p5DCCB2CC.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.178.204] by mail.gmx.net (mp008) with SMTP; 17 Oct 2011 10:32:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/CoU0d3GjClWb+N+Pxdk8RCnbd2BgaXwcD/vSUnl aWUc5Rofx6EqHT Message-ID: <4E9BE823.4080305@gmx.de> Date: Mon, 17 Oct 2011 10:32:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 08:32:45 -0000 On 2011-10-17 00:54, Eran Hammer-Lahav wrote: > It's an open question for the list. > > EHL > ... Well, as long as it is not restricted in the core spec, the bearer spec will have to handle the case (or document this as known technical omission, I guess). Best regards, Julian From ve7jtb@ve7jtb.com Mon Oct 17 06:07:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323A721F8B90 for ; Mon, 17 Oct 2011 06:07:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oym1qRRUsOjK for ; Mon, 17 Oct 2011 06:07:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9621F8B79 for ; Mon, 17 Oct 2011 06:07:12 -0700 (PDT) Received: by gyh20 with SMTP id 20so3620111gyh.31 for ; Mon, 17 Oct 2011 06:07:12 -0700 (PDT) Received: by 10.68.34.138 with SMTP id z10mr38143163pbi.105.1318856831518; Mon, 17 Oct 2011 06:07:11 -0700 (PDT) Received: from [10.10.1.58] ([209.118.182.66]) by mx.google.com with ESMTPS id z1sm58731292pbl.5.2011.10.17.06.07.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 06:07:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: John Bradley In-Reply-To: Date: Mon, 17 Oct 2011 06:07:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:07:13 -0000 The scopes cross all of the profiles. I expect that restricting the character sets for bearer tokens, MAC, and = other future variants should be dealt with in those profiles.=20 Without restricting scope in core, we leave the possibility of coming up = with different rules in different profiles e.g. MAC vs Bearer. It is probably best to have one rule in core that works across all the = profiles. John B. On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: > I think the limit makes sense, but then are tokens limited by the same = rules? They need to live in all the same places (query parameters, = headers, forms) that scopes do and would be subject to the same kinds of = encoding woes that scopes will. Or am I missing something obvious as to = why this isn't a problem for tokens (both bearer tokens and the public = part of MAC tokens) but is a problem for scope strings? >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of = John Bradley [ve7jtb@ve7jtb.com] > Sent: Sunday, October 16, 2011 8:11 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & = Proposed Resolutions >=20 > Restricting it now in the core spec is going to save a lot of = headaches later. >=20 > John B. > On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: >=20 >> It's an open question for the list. >>=20 >> EHL >>=20 >>> -----Original Message----- >>> From: Julian Reschke [mailto:julian.reschke@gmx.de] >>> Sent: Sunday, October 16, 2011 11:00 AM >>> To: Mike Jones >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth = WG; >>> Eran Hammer-Lahav >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >>> Proposed Resolutions >>>=20 >>> On 2011-10-16 18:44, Mike Jones wrote: >>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide = range of >>> characters in scope was unintentional. The design was limited to = allow simple >>> ASCII strings and URIs." >>>> ... >>>=20 >>> I see. Thanks. >>>=20 >>> Is this going to be clarified in -23? >>>=20 >>> Best regards, Julian >> _______________________________________________ >> 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 eran@hueniverse.com Mon Oct 17 07:27:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2618721F8BD8 for ; Mon, 17 Oct 2011 07:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNWVDvlpscvQ for ; Mon, 17 Oct 2011 07:27:50 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 6A47721F8BBB for ; Mon, 17 Oct 2011 07:27:50 -0700 (PDT) Received: (qmail 21997 invoked from network); 17 Oct 2011 14:27:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Oct 2011 14:27:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 17 Oct 2011 07:27:24 -0700 From: Eran Hammer-Lahav To: John Bradley , "Richer, Justin P." Date: Mon, 17 Oct 2011 07:27:20 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyMzbtPF0tDWFJjQtiOK2e+wcQYlgACyL+Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> In-Reply-To: <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> 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] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:27:51 -0000 I agree. EHL > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Monday, October 17, 2011 6:07 AM > To: Richer, Justin P. > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > Proposed Resolutions >=20 > The scopes cross all of the profiles. >=20 > I expect that restricting the character sets for bearer tokens, MAC, and = other > future variants should be dealt with in those profiles. >=20 > Without restricting scope in core, we leave the possibility of coming up = with > different rules in different profiles e.g. MAC vs Bearer. >=20 > It is probably best to have one rule in core that works across all the pr= ofiles. >=20 > John B. > On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: >=20 > > I think the limit makes sense, but then are tokens limited by the same > rules? They need to live in all the same places (query parameters, header= s, > forms) that scopes do and would be subject to the same kinds of encoding > woes that scopes will. Or am I missing something obvious as to why this i= sn't > a problem for tokens (both bearer tokens and the public part of MAC token= s) > but is a problem for scope strings? > > > > -- Justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of > > John Bradley [ve7jtb@ve7jtb.com] > > Sent: Sunday, October 16, 2011 8:11 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > Proposed Resolutions > > > > Restricting it now in the core spec is going to save a lot of headaches= later. > > > > John B. > > On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: > > > >> It's an open question for the list. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: Julian Reschke [mailto:julian.reschke@gmx.de] > >>> Sent: Sunday, October 16, 2011 11:00 AM > >>> To: Mike Jones > >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth > >>> WG; Eran Hammer-Lahav > >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > >>> Proposed Resolutions > >>> > >>> On 2011-10-16 18:44, Mike Jones wrote: > >>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide > >>>> range of > >>> characters in scope was unintentional. The design was limited to > >>> allow simple ASCII strings and URIs." > >>>> ... > >>> > >>> I see. Thanks. > >>> > >>> Is this going to be clarified in -23? > >>> > >>> Best regards, Julian > >> _______________________________________________ > >> 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 Mon Oct 17 09:11:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E768E21F8D53 for ; Mon, 17 Oct 2011 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.948 X-Spam-Level: X-Spam-Status: No, score=-16.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRMFc4-QyQip for ; Mon, 17 Oct 2011 09:11:46 -0700 (PDT) Received: from nm24-vm3.bullet.mail.ne1.yahoo.com (nm24-vm3.bullet.mail.ne1.yahoo.com [98.138.91.154]) by ietfa.amsl.com (Postfix) with SMTP id 2C57021F8D52 for ; Mon, 17 Oct 2011 09:11:45 -0700 (PDT) Received: from [98.138.90.56] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 16:11:35 -0000 Received: from [98.138.88.233] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 16:11:35 -0000 Received: from [127.0.0.1] by omp1033.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 16:11:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 589372.86456.bm@omp1033.mail.ne1.yahoo.com Received: (qmail 3769 invoked by uid 60001); 17 Oct 2011 16:11:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1318867895; bh=wj6hGupAJX/KdolXVXSEtTnK9PaP5He99fS7og3GDmM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cAXnOJrxV4iOTaf7reh7+4j3EWSqPcvSqBgBNLtNcv0va7SN28epQXAR4rATkTpKfJHWRZtdlW+Ip6nABFY9jEuqC8SN17QRE9Wmmii4L88F5affQTVrphE94ppSJJxWmNnKfixh+oPPE0lli+9rGT0aXzNIIxnA49tcwdruw0s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GB6J4Sq73/tlPcIZGDYXz1rI5Rz5kJMQpHWshw7q7w5OJzn7yg7cQS6KEnlRBZmC+E1KioyCFn1Is0RBDm8rzQQwNSbqkJjB806eal/ztACWralHNaslfYFzlAPV+FBnfMxAV+L9jCwYEgyoiFoZe8KN4+FkxX98L61xWhEMNXM=; X-YMail-OSG: 1_rf_X4VM1n39l_NTw8Cu3eAmgWIC_nmjH8N1YtUUzvLjHt oUsX4moM.qErQZWOkmm.K9Rt.D_w2M43ZwyF4pSCAYbF_3TKHis19OyV5tV_ rkDyWFxYvKgxq0qHRrOyx3Raim5__c7mfBVapGbUK27YvErP7PyfBuW9IbuS xqCLcoOZ8CTx0c4GWm5H30uF85CnEpgRhRU1zqdsdk3r7yTRPZf5Af9Z757J NGIDp6DYXUN6JPxJAYhauG9X_NNCGAKtFL4Si7Vz2kLg8nB56Gb4Y4DrTMZL _dzolWN7wENPa6o7xnzu.5CWJxd8UTyo.hOpNJ5EaZoDzxs7Qcp6UogVtjEi THGP2XRF5g6PSAR.H_GAzePq_2BOJzG3T9VxEhYRqkTOOezYr9AMnvg1XQul coFxddbyzpnjs0VfQoIqU6Ux57Q0YYAwTQQ-- Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Mon, 17 Oct 2011 09:11:34 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1318867894.30512.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Mon, 17 Oct 2011 09:11:34 -0700 (PDT) From: William Mills To: Eran Hammer-Lahav , John Bradley , "Richer, Justin P." In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2139641421-1318867894=:30512" Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 16:11:57 -0000 --0-2139641421-1318867894=:30512 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable What's the current leaning in the core spec.=A0 Is there a direction emergi= ng for this answer?=0A=0A=0A=0A________________________________=0AFrom: Era= n Hammer-Lahav =0ATo: John Bradley = ; "Richer, Justin P." =0ACc: OAuth WG = =0ASent: Monday, October 17, 2011 7:27 AM=0ASubject: Re: [OAUTH-WG] draft-i= etf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions=0A=0AI agree.=0A= =0AEHL=0A=0A> -----Original Message-----=0A> From: John Bradley [mailto:ve7= jtb@ve7jtb.com]=0A> Sent: Monday, October 17, 2011 6:07 AM=0A> To: Richer, = Justin P.=0A> Cc: Eran Hammer-Lahav; OAuth WG=0A> Subject: Re: [OAUTH-WG] d= raft-ietf-oauth-v2-bearer-09: Open Issues &=0A> Proposed Resolutions=0A> = =0A> The scopes cross all of the profiles.=0A> =0A> I expect that restricti= ng the character sets for bearer tokens, MAC, and other=0A> future variants= should be dealt with in those profiles.=0A> =0A> Without restricting scope= in core, we leave the possibility of coming up with=0A> different rules in= different profiles e.g. MAC vs Bearer.=0A> =0A> It is probably best to hav= e one rule in core that works across all the profiles.=0A> =0A> John B.=0A>= On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote:=0A> =0A> > I think the= limit makes sense, but then are tokens limited by the same=0A> rules? They= need to live in all the same places (query parameters, headers,=0A> forms)= that scopes do and would be subject to the same kinds of encoding=0A> woes= that scopes will. Or am I missing something obvious as to why this isn't= =0A> a problem for tokens (both bearer tokens and the public part of MAC to= kens)=0A> but is a problem for scope strings?=0A> >=0A> > -- Justin=0A> > _= _______________________________________=0A> > From: oauth-bounces@ietf.org = [oauth-bounces@ietf.org] on behalf of=0A> > John Bradley [ve7jtb@ve7jtb.com= ]=0A> > Sent: Sunday, October 16, 2011 8:11 PM=0A> > To: Eran Hammer-Lahav= =0A> > Cc: OAuth WG=0A> > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-beare= r-09: Open Issues &=0A> Proposed Resolutions=0A> >=0A> > Restricting it now= in the core spec is going to save a lot of headaches later.=0A> >=0A> > Jo= hn B.=0A> > On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote:=0A> >=0A> >= > It's an open question for the list.=0A> >>=0A> >> EHL=0A> >>=0A> >>> ----= -Original Message-----=0A> >>> From: Julian Reschke [mailto:julian.reschke@= gmx.de]=0A> >>> Sent: Sunday, October 16, 2011 11:00 AM=0A> >>> To: Mike Jo= nes=0A> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAu= th=0A> >>> WG; Eran Hammer-Lahav=0A> >>> Subject: Re: [OAUTH-WG] draft-ietf= -oauth-v2-bearer-09: Open Issues &=0A> >>> Proposed Resolutions=0A> >>>=0A>= >>> On 2011-10-16 18:44, Mike Jones wrote:=0A> >>>> As Eran wrote on 9/30,= "The fact that the v2 spec allows a wide=0A> >>>> range of=0A> >>> charact= ers in scope was unintentional. The design was limited to=0A> >>> allow sim= ple ASCII strings and URIs."=0A> >>>> ...=0A> >>>=0A> >>> I see. Thanks.=0A= > >>>=0A> >>> Is this going to be clarified in -23?=0A> >>>=0A> >>> Best re= gards, Julian=0A> >> _______________________________________________=0A> >>= OAuth mailing list=0A> >> OAuth@ietf.org=0A> >> https://www.ietf.org/mailm= an/listinfo/oauth=0A> >=0A> > _____________________________________________= __=0A> > OAuth mailing list=0A> > OAuth@ietf.org=0A> > https://www.ietf.org= /mailman/listinfo/oauth=0A=0A______________________________________________= _=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/list= info/oauth --0-2139641421-1318867894=:30512 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
What's the current leaning in the core spec.  Is there a direction e= merging for this answer?

From: Eran Hammer-Lahav <eran@huenive= rse.com>
To: John Br= adley <ve7jtb@ve7jtb.com>; "Richer, Justin P." <jricher@mitre.org&= gt;
Cc: OAuth WG <oa= uth@ietf.org>
Sent: = Monday, October 17, 2011 7:27 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: O= pen Issues & Proposed Resolutions

=0AI agree.

EHL<= br>
> -----Original Message-----
> From: John Bradley [mailto:<= a ymailto=3D"mailto:ve7jtb@ve7jtb.com" href=3D"mailto:ve7jtb@ve7jtb.com">ve= 7jtb@ve7jtb.com]
> Sent: Monday, October 17, 2011 6:07 AM
>= To: Richer, Justin P.
> Cc: Eran Hammer-Lahav; OAuth WG
> Subj= ect: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>= ; Proposed Resolutions
>
> The scopes cross all of the profile= s.
>
> I expect that restricting the character sets for bearer= tokens, MAC, and other
> future variants should be dealt with in tho= se profiles.
>
> Without restricting scope in core, we leave t= he possibility of coming up with
> different rules in different profi= les e.g. MAC vs Bearer.
>
> It is probably best to have one ru= le in core that works across all the profiles.
>
> John B.
= > On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote:
>
> > I think the limit makes sense, but then are t= okens limited by the same
> rules? They need to live in all the same = places (query parameters, headers,
> forms) that scopes do and would = be subject to the same kinds of encoding
> woes that scopes will. Or = am I missing something obvious as to why this isn't
> a problem for t= okens (both bearer tokens and the public part of MAC tokens)
> but is= a problem for scope strings?
> >
> > -- Justin
> &= gt; ________________________________________
> > From: o= auth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf o= f
> > John Bradley [ve7jtb@ve7jtb.com]
> > Sent: Sun= day, October 16, 2011 8:11 PM
> > To: Eran Hammer-Lahav
> > C= c: OAuth WG
> > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer= -09: Open Issues &
> Proposed Resolutions
> >
> &g= t; Restricting it now in the core spec is going to save a lot of headaches = later.
> >
> > John B.
> > On 2011-10-16, at 3:5= 4 PM, Eran Hammer-Lahav wrote:
> >
> >> It's an open q= uestion for the list.
> >>
> >> EHL
> >>= ;
> >>> -----Original Message-----
> >>> From= : Julian Reschke [mailto:julian.reschke@gmx.de]
> >&g= t;> Sent: Sunday, October 16, 2011 11:00 AM
> >>> To: Mik= e Jones
> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hanne= s Tschofenig; OAuth
> >>> WG; Eran Hammer-Lahav
> >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open I= ssues &
> >>> Proposed Resolutions
> >>><= br>> >>> On 2011-10-16 18:44, Mike Jones wrote:
> >>= ;>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide> >>>> range of
> >>> characters in scope w= as unintentional. The design was limited to
> >>> allow simp= le ASCII strings and URIs."
> >>>> ...
> >>&g= t;
> >>> I see. Thanks.
> >>>
> >>= ;> Is this going to be clarified in -23?
> >>>
> &g= t;>> Best regards, Julian
> >> __________________________= _____________________
> >> OAuth mailing list
> >> = OAuth@i= etf.org
> >> htt= ps://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-2139641421-1318867894=:30512-- From Hannes.Tschofenig@gmx.net Mon Oct 17 09:28:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A10521F8CAB for ; Mon, 17 Oct 2011 09:28:48 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP9VEm1JV+D1 for ; Mon, 17 Oct 2011 09:28:47 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 558CE21F8C55 for ; Mon, 17 Oct 2011 09:28:46 -0700 (PDT) Received: (qmail invoked by alias); 17 Oct 2011 16:28:44 -0000 Received: from unknown (EHLO [10.2.210.110]) [12.229.246.2] by mail.gmx.net (mp067) with SMTP; 17 Oct 2011 18:28:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/I7k4ryz/I4kjsvOCcka07knMBNCEdSebttJmoQY Yr+IYthKXbKa/X Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 17 Oct 2011 08:25:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 16:28:48 -0000 It is good that we have an agreement among a few people that more text = needs to be provided in the core specification on the issue of the scope = element.=20 Now, there is still the question of what the text should say. The = questions from my earlier mails are therefore still applicable and need = an answer.=20 Ciao Hannes On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote: > I agree. >=20 > EHL >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Monday, October 17, 2011 6:07 AM >> To: Richer, Justin P. >> Cc: Eran Hammer-Lahav; OAuth WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >> Proposed Resolutions >>=20 >> The scopes cross all of the profiles. >>=20 >> I expect that restricting the character sets for bearer tokens, MAC, = and other >> future variants should be dealt with in those profiles. >>=20 >> Without restricting scope in core, we leave the possibility of coming = up with >> different rules in different profiles e.g. MAC vs Bearer. >>=20 >> It is probably best to have one rule in core that works across all = the profiles. >>=20 >> John B. >> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: >>=20 >>> I think the limit makes sense, but then are tokens limited by the = same >> rules? They need to live in all the same places (query parameters, = headers, >> forms) that scopes do and would be subject to the same kinds of = encoding >> woes that scopes will. Or am I missing something obvious as to why = this isn't >> a problem for tokens (both bearer tokens and the public part of MAC = tokens) >> but is a problem for scope strings? >>>=20 >>> -- Justin >>> ________________________________________ >>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of >>> John Bradley [ve7jtb@ve7jtb.com] >>> Sent: Sunday, October 16, 2011 8:11 PM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >> Proposed Resolutions >>>=20 >>> Restricting it now in the core spec is going to save a lot of = headaches later. >>>=20 >>> John B. >>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: >>>=20 >>>> It's an open question for the list. >>>>=20 >>>> EHL >>>>=20 >>>>> -----Original Message----- >>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de] >>>>> Sent: Sunday, October 16, 2011 11:00 AM >>>>> To: Mike Jones >>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth >>>>> WG; Eran Hammer-Lahav >>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues = & >>>>> Proposed Resolutions >>>>>=20 >>>>> On 2011-10-16 18:44, Mike Jones wrote: >>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide >>>>>> range of >>>>> characters in scope was unintentional. The design was limited to >>>>> allow simple ASCII strings and URIs." >>>>>> ... >>>>>=20 >>>>> I see. Thanks. >>>>>=20 >>>>> Is this going to be clarified in -23? >>>>>=20 >>>>> Best regards, Julian >>>> _______________________________________________ >>>> 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Oct 17 12:09:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C39C21F8C80 for ; Mon, 17 Oct 2011 12:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i6W+xgnNkft for ; Mon, 17 Oct 2011 12:09:28 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 2B68D21F8B3F for ; Mon, 17 Oct 2011 12:09:25 -0700 (PDT) Received: (qmail 29869 invoked from network); 17 Oct 2011 18:54:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Oct 2011 18:54:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 17 Oct 2011 11:53:48 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig Date: Mon, 17 Oct 2011 11:53:43 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyM6d4wnMmHqnZaTgqyfYFK6i43BgAFA8yw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> In-Reply-To: <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@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 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 19:09:29 -0000 All I agree with is to limit the scope character-set in the v2 spec to the = subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so = no escaping is needed, ever. EHL > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, October 17, 2011 8:25 AM > To: Eran Hammer-Lahav > Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > Proposed Resolutions >=20 > It is good that we have an agreement among a few people that more text > needs to be provided in the core specification on the issue of the scope > element. >=20 > Now, there is still the question of what the text should say. The questio= ns > from my earlier mails are therefore still applicable and need an answer. >=20 > Ciao > Hannes >=20 > On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote: >=20 > > I agree. > > > > EHL > > > >> -----Original Message----- > >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] > >> Sent: Monday, October 17, 2011 6:07 AM > >> To: Richer, Justin P. > >> Cc: Eran Hammer-Lahav; OAuth WG > >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > >> Proposed Resolutions > >> > >> The scopes cross all of the profiles. > >> > >> I expect that restricting the character sets for bearer tokens, MAC, > >> and other future variants should be dealt with in those profiles. > >> > >> Without restricting scope in core, we leave the possibility of coming > >> up with different rules in different profiles e.g. MAC vs Bearer. > >> > >> It is probably best to have one rule in core that works across all the > profiles. > >> > >> John B. > >> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: > >> > >>> I think the limit makes sense, but then are tokens limited by the > >>> same > >> rules? They need to live in all the same places (query parameters, > >> headers, > >> forms) that scopes do and would be subject to the same kinds of > >> encoding woes that scopes will. Or am I missing something obvious as > >> to why this isn't a problem for tokens (both bearer tokens and the > >> public part of MAC tokens) but is a problem for scope strings? > >>> > >>> -- Justin > >>> ________________________________________ > >>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of > >>> John Bradley [ve7jtb@ve7jtb.com] > >>> Sent: Sunday, October 16, 2011 8:11 PM > >>> To: Eran Hammer-Lahav > >>> Cc: OAuth WG > >>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > >> Proposed Resolutions > >>> > >>> Restricting it now in the core spec is going to save a lot of headach= es > later. > >>> > >>> John B. > >>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: > >>> > >>>> It's an open question for the list. > >>>> > >>>> EHL > >>>> > >>>>> -----Original Message----- > >>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de] > >>>>> Sent: Sunday, October 16, 2011 11:00 AM > >>>>> To: Mike Jones > >>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth > >>>>> WG; Eran Hammer-Lahav > >>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues > >>>>> & Proposed Resolutions > >>>>> > >>>>> On 2011-10-16 18:44, Mike Jones wrote: > >>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide > >>>>>> range of > >>>>> characters in scope was unintentional. The design was limited to > >>>>> allow simple ASCII strings and URIs." > >>>>>> ... > >>>>> > >>>>> I see. Thanks. > >>>>> > >>>>> Is this going to be clarified in -23? > >>>>> > >>>>> Best regards, Julian > >>>> _______________________________________________ > >>>> 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 ve7jtb@ve7jtb.com Mon Oct 17 12:13:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5095021F8C73 for ; Mon, 17 Oct 2011 12:13:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIOrlu6-jwZo for ; Mon, 17 Oct 2011 12:13:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6173B21F8C83 for ; Mon, 17 Oct 2011 12:13:37 -0700 (PDT) Received: by iabn5 with SMTP id n5so7080250iab.31 for ; Mon, 17 Oct 2011 12:13:32 -0700 (PDT) Received: by 10.42.147.65 with SMTP id m1mr36107953icv.27.1318878812055; Mon, 17 Oct 2011 12:13:32 -0700 (PDT) Received: from [10.66.225.224] (h-64-236-139-254.aoltw.net. [64.236.139.254]) by mx.google.com with ESMTPS id l28sm38577082ibc.3.2011.10.17.12.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 12:13:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_FD2D42F1-6159-4E01-B939-462B1015589F"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 17 Oct 2011 12:13:28 -0700 Message-Id: <0AE463C6-254C-4776-A6EC-08DBE3F8A7F1@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-35 20DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 19:13:38 -0000 --Apple-Mail=_FD2D42F1-6159-4E01-B939-462B1015589F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote: > All I agree with is to limit the scope character-set in the v2 spec to = the subset of ASCII allowed in HTTP header quoted-string, excluding " = and \ so no escaping is needed, ever. >=20 > EHL >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Monday, October 17, 2011 8:25 AM >> To: Eran Hammer-Lahav >> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >> Proposed Resolutions >>=20 >> It is good that we have an agreement among a few people that more = text >> needs to be provided in the core specification on the issue of the = scope >> element. >>=20 >> Now, there is still the question of what the text should say. The = questions >> from my earlier mails are therefore still applicable and need an = answer. >>=20 >> Ciao >> Hannes >>=20 >> On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote: >>=20 >>> I agree. >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Monday, October 17, 2011 6:07 AM >>>> To: Richer, Justin P. >>>> Cc: Eran Hammer-Lahav; OAuth WG >>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues = & >>>> Proposed Resolutions >>>>=20 >>>> The scopes cross all of the profiles. >>>>=20 >>>> I expect that restricting the character sets for bearer tokens, = MAC, >>>> and other future variants should be dealt with in those profiles. >>>>=20 >>>> Without restricting scope in core, we leave the possibility of = coming >>>> up with different rules in different profiles e.g. MAC vs Bearer. >>>>=20 >>>> It is probably best to have one rule in core that works across all = the >> profiles. >>>>=20 >>>> John B. >>>> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: >>>>=20 >>>>> I think the limit makes sense, but then are tokens limited by the >>>>> same >>>> rules? They need to live in all the same places (query parameters, >>>> headers, >>>> forms) that scopes do and would be subject to the same kinds of >>>> encoding woes that scopes will. Or am I missing something obvious = as >>>> to why this isn't a problem for tokens (both bearer tokens and the >>>> public part of MAC tokens) but is a problem for scope strings? >>>>>=20 >>>>> -- Justin >>>>> ________________________________________ >>>>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of >>>>> John Bradley [ve7jtb@ve7jtb.com] >>>>> Sent: Sunday, October 16, 2011 8:11 PM >>>>> To: Eran Hammer-Lahav >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues = & >>>> Proposed Resolutions >>>>>=20 >>>>> Restricting it now in the core spec is going to save a lot of = headaches >> later. >>>>>=20 >>>>> John B. >>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: >>>>>=20 >>>>>> It's an open question for the list. >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de] >>>>>>> Sent: Sunday, October 16, 2011 11:00 AM >>>>>>> To: Mike Jones >>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; = OAuth >>>>>>> WG; Eran Hammer-Lahav >>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open = Issues >>>>>>> & Proposed Resolutions >>>>>>>=20 >>>>>>> On 2011-10-16 18:44, Mike Jones wrote: >>>>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide >>>>>>>> range of >>>>>>> characters in scope was unintentional. The design was limited to >>>>>>> allow simple ASCII strings and URIs." >>>>>>>> ... >>>>>>>=20 >>>>>>> I see. Thanks. >>>>>>>=20 >>>>>>> Is this going to be clarified in -23? >>>>>>>=20 >>>>>>> Best regards, Julian >>>>>> _______________________________________________ >>>>>> 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 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_FD2D42F1-6159-4E01-B939-462B1015589F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEw MTcxOTEzMjlaMCMGCSqGSIb3DQEJBDEWBBQZP4ZNoLcTioqQNVc0CGB9NklrIDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQC1TmJ8v7OdXb7HdeCw0ScXXavfvZhrLdcZGd38jydX0cZsCYqs20YZJLVMS3RVoFQ8fbIMGsot lKDWRYKyUooRpTRPsacVjgp/CX53i9LUGASFr9YTm0l/RrvnqvdBOH9dS5zXWPqa+v+v7pnR7E3G dLT2YiYMjMQwETj7aHxiWG247/ImZkJzTuSfE+kQLvkimoJyi7oA+LAFpdQ07ZteBJteIN5wyAOD 7ZRDZ4HNdZWDtxx+I+UuZSdxqLNUfamIOHECNGg1ShGLIRp+xleqYD1IgT5gIlXn/gsbMAZeSNcR daP+zYzt8wD6E8B1guBanUJ/2oO09JUdQfow1mu5AAAAAAAA --Apple-Mail=_FD2D42F1-6159-4E01-B939-462B1015589F-- From wmills@yahoo-inc.com Mon Oct 17 13:53:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0781F0C4E for ; Mon, 17 Oct 2011 13:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.165 X-Spam-Level: X-Spam-Status: No, score=-17.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqsV3MZJwKuW for ; Mon, 17 Oct 2011 13:53:22 -0700 (PDT) Received: from nm34-vm1.bullet.mail.ne1.yahoo.com (nm34-vm1.bullet.mail.ne1.yahoo.com [98.138.229.81]) by ietfa.amsl.com (Postfix) with SMTP id 4F8921F0C49 for ; Mon, 17 Oct 2011 13:53:21 -0700 (PDT) Received: from [98.138.90.53] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 20:53:18 -0000 Received: from [98.138.88.232] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 20:53:18 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 20:53:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 169504.73975.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 50693 invoked by uid 60001); 17 Oct 2011 20:53:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1318884797; bh=d6OzlhKgeFO4/66kHKxRZIG/iELtXN/QpXmNVCYVCT0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=a7x4umpeCnnQ6A2bXGgB7qt9sxjC333htTEzvfwloebyhkUTtWq58Pd7u6dEPV/ObDgXptsmh2FRZ91gFn591FZmlp0Hkmpo1hhrFG5EdQF051579ML9ujugky5X74rpYpFNpaqYJf9NNkEavGfHttQF+af4HKmKdjHSz1xySxw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eWwjBB/fP5cuG7ooPtEGY3qaw/ycWp8d+HSf1UHSDavB2zI6aiGPSD5lht5RPssazCy/0TVMwcBnWJa6qRz4A3z0M2/eg65jeRj2Bb19HbGZV35CVD7LJa0KR1Qpaglaaw5MdH9mV0Pb47v7owaedUzwB6v+ugPn1wMurR5veqw=; X-YMail-OSG: zI7YUQAVM1l.65KeP4K8wx_lotFm_JbgATy3YNuj748cBYM Y5FJrZNzeJ.aVoK_nACHeVIuIjgzQB0_Kx8NQcEAVpV_.ekVLUqL2PG9VpOB SfOl3MqO_F9pBn5DdbNSNRmml.B5NtcobL820bwkF_hhi14M.IKkckUHPNYp GLw4SborSKH43VtIx_zIn5XGiu7GFjvkvZ8_Mo3AHBgh5FtkfJbJdcj4T.is 3zvqR8agdqCaKLboLzrKtl1le8B_YISKEpMQ8qD7Dxxyoup1xwBwJ79dffQT QilJXMFpl0k7UN9PMPO_zhgDfbaMOcHY9zdd1a5u_mfP_aiEIn35VuhVj9VH EBd0SluRdBCql5IruWqGxCsr5nYd2yV8wMtyxQo_zIj4tx1WkblREy7fXPNa xAWdkj4MDFAw8CZnOX1PwTiWUGV5BThuN Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Mon, 17 Oct 2011 13:53:17 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-35 20DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0AE463C6-254C-4776-A6EC-08DBE3F8A7F1@ve7jtb.com> Message-ID: <1318884797.81519.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Mon, 17 Oct 2011 13:53:17 -0700 (PDT) From: William Mills To: John Bradley , Eran Hammer-Lahav In-Reply-To: <0AE463C6-254C-4776-A6EC-08DBE3F8A7F1@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2115303481-1318884797=:81519" Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 20:53:23 -0000 --0-2115303481-1318884797=:81519 Content-Type: text/plain; charset=us-ascii +1 ________________________________ From: John Bradley To: Eran Hammer-Lahav Cc: OAuth WG Sent: Monday, October 17, 2011 12:13 PM Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions +1 On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote: > All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever. > > EHL > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Monday, October 17, 2011 8:25 AM >> To: Eran Hammer-Lahav >> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >> Proposed Resolutions >> >> It is good that we have an agreement among a few people that more text >> needs to be provided in the core specification on the issue of the scope >> element. >> >> Now, there is still the question of what the text should say. The questions >> from my earlier mails are therefore still applicable and need an answer. >> >> Ciao >> Hannes >> >> On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote: >> >>> I agree. >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Monday, October 17, 2011 6:07 AM >>>> To: Richer, Justin P. >>>> Cc: Eran Hammer-Lahav; OAuth WG >>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >>>> Proposed Resolutions >>>> >>>> The scopes cross all of the profiles. >>>> >>>> I expect that restricting the character sets for bearer tokens, MAC, >>>> and other future variants should be dealt with in those profiles. >>>> >>>> Without restricting scope in core, we leave the possibility of coming >>>> up with different rules in different profiles e.g. MAC vs Bearer. >>>> >>>> It is probably best to have one rule in core that works across all the >> profiles. >>>> >>>> John B. >>>> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: >>>> >>>>> I think the limit makes sense, but then are tokens limited by the >>>>> same >>>> rules? They need to live in all the same places (query parameters, >>>> headers, >>>> forms) that scopes do and would be subject to the same kinds of >>>> encoding woes that scopes will. Or am I missing something obvious as >>>> to why this isn't a problem for tokens (both bearer tokens and the >>>> public part of MAC tokens) but is a problem for scope strings? >>>>> >>>>> -- Justin >>>>> ________________________________________ >>>>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of >>>>> John Bradley [ve7jtb@ve7jtb.com] >>>>> Sent: Sunday, October 16, 2011 8:11 PM >>>>> To: Eran Hammer-Lahav >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >>>> Proposed Resolutions >>>>> >>>>> Restricting it now in the core spec is going to save a lot of headaches >> later. >>>>> >>>>> John B. >>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: >>>>> >>>>>> It's an open question for the list. >>>>>> >>>>>> EHL >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de] >>>>>>> Sent: Sunday, October 16, 2011 11:00 AM >>>>>>> To: Mike Jones >>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth >>>>>>> WG; Eran Hammer-Lahav >>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues >>>>>>> & Proposed Resolutions >>>>>>> >>>>>>> On 2011-10-16 18:44, Mike Jones wrote: >>>>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide >>>>>>>> range of >>>>>>> characters in scope was unintentional. The design was limited to >>>>>>> allow simple ASCII strings and URIs." >>>>>>>> ... >>>>>>> >>>>>>> I see. Thanks. >>>>>>> >>>>>>> Is this going to be clarified in -23? >>>>>>> >>>>>>> Best regards, Julian >>>>>> _______________________________________________ >>>>>> 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 --0-2115303481-1318884797=:81519 Content-Type: text/html; charset=us-ascii
+1

From: John Bradley <ve7jtb@ve7jtb.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Monday, October 17, 2011 12:13 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

+1

On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote:

> All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever.
>
> EHL
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>> Sent: Monday, October 17, 2011 8:25 AM
>> To: Eran Hammer-Lahav
>> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG
>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>> Proposed Resolutions
>>
>> It is good that we have an agreement among a few people that more text
>> needs to be provided in the core specification on the issue of the scope
>> element.
>>
>> Now, there is still the question of what the text should say. The questions
>> from my earlier mails are therefore still applicable and need an answer.
>>
>> Ciao
>> Hannes
>>
>> On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote:
>>
>>> I agree.
>>>
>>> EHL
>>>
>>>> -----Original Message-----
>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>> Sent: Monday, October 17, 2011 6:07 AM
>>>> To: Richer, Justin P.
>>>> Cc: Eran Hammer-Lahav; OAuth WG
>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>>>> Proposed Resolutions
>>>>
>>>> The scopes cross all of the profiles.
>>>>
>>>> I expect that restricting the character sets for bearer tokens, MAC,
>>>> and other future variants should be dealt with in those profiles.
>>>>
>>>> Without restricting scope in core, we leave the possibility of coming
>>>> up with different rules in different profiles e.g. MAC vs Bearer.
>>>>
>>>> It is probably best to have one rule in core that works across all the
>> profiles.
>>>>
>>>> John B.
>>>> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote:
>>>>
>>>>> I think the limit makes sense, but then are tokens limited by the
>>>>> same
>>>> rules? They need to live in all the same places (query parameters,
>>>> headers,
>>>> forms) that scopes do and would be subject to the same kinds of
>>>> encoding woes that scopes will. Or am I missing something obvious as
>>>> to why this isn't a problem for tokens (both bearer tokens and the
>>>> public part of MAC tokens) but is a problem for scope strings?
>>>>>
>>>>> -- Justin
>>>>> ________________________________________
>>>>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of
>>>>> John Bradley [ve7jtb@ve7jtb.com]
>>>>> Sent: Sunday, October 16, 2011 8:11 PM
>>>>> To: Eran Hammer-Lahav
>>>>> Cc: OAuth WG
>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>>>> Proposed Resolutions
>>>>>
>>>>> Restricting it now in the core spec is going to save a lot of headaches
>> later.
>>>>>
>>>>> John B.
>>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote:
>>>>>
>>>>>> It's an open question for the list.
>>>>>>
>>>>>> EHL
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>>>>>>> Sent: Sunday, October 16, 2011 11:00 AM
>>>>>>> To: Mike Jones
>>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth
>>>>>>> WG; Eran Hammer-Lahav
>>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues
>>>>>>> & Proposed Resolutions
>>>>>>>
>>>>>>> On 2011-10-16 18:44, Mike Jones wrote:
>>>>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide
>>>>>>>> range of
>>>>>>> characters in scope was unintentional. The design was limited to
>>>>>>> allow simple ASCII strings and URIs."
>>>>>>>> ...
>>>>>>>
>>>>>>> I see. Thanks.
>>>>>>>
>>>>>>> Is this going to be clarified in -23?
>>>>>>>
>>>>>>> Best regards, Julian
>>>>>> _______________________________________________
>>>>>> 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


--0-2115303481-1318884797=:81519-- From Michael.Jones@microsoft.com Mon Oct 17 15:25:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33D111E8082 for ; Mon, 17 Oct 2011 15:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.803 X-Spam-Level: X-Spam-Status: No, score=-9.803 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE3rXlLMBCAy for ; Mon, 17 Oct 2011 15:25:30 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id E007811E8073 for ; Mon, 17 Oct 2011 15:25:29 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Oct 2011 15:25:29 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Mon, 17 Oct 2011 15:25:28 -0700 From: Mike Jones To: William Mills , John Bradley , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AQHMjQDlX7tK0awYbE+qvadtyQWHMJWBeO2A//+kXmA= Date: Mon, 17 Oct 2011 22:25:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C2479E0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-35 20DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0AE463C6-254C-4776-A6EC-08DBE3F8A7F1@ve7jtb.com> <1318884797.81519.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1318884797.81519.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C2479E0TK5EX14MBXC283r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:25:31 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C2479E0TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam Mills Sent: Monday, October 17, 2011 1:53 PM To: John Bradley; Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions +1 ________________________________ From: John Bradley > To: Eran Hammer-Lahav > Cc: OAuth WG > Sent: Monday, October 17, 2011 12:13 PM Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions +1 On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote: > All I agree with is to limit the scope character-set in the v2 spec to th= e subset of ASCII allowed in HTTP header quoted-string, excluding " and \ s= o no escaping is needed, ever. > > EHL > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Monday, October 17, 2011 8:25 AM >> To: Eran Hammer-Lahav >> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >> Proposed Resolutions >> >> It is good that we have an agreement among a few people that more text >> needs to be provided in the core specification on the issue of the scope >> element. >> >> Now, there is still the question of what the text should say. The questi= ons >> from my earlier mails are therefore still applicable and need an answer. >> >> Ciao >> Hannes >> >> On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote: >> >>> I agree. >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com= ] >>>> Sent: Monday, October 17, 2011 6:07 AM >>>> To: Richer, Justin P. >>>> Cc: Eran Hammer-Lahav; OAuth WG >>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >>>> Proposed Resolutions >>>> >>>> The scopes cross all of the profiles. >>>> >>>> I expect that restricting the character sets for bearer tokens, MAC, >>>> and other future variants should be dealt with in those profiles. >>>> >>>> Without restricting scope in core, we leave the possibility of coming >>>> up with different rules in different profiles e.g. MAC vs Bearer. >>>> >>>> It is probably best to have one rule in core that works across all the >> profiles. >>>> >>>> John B. >>>> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: >>>> >>>>> I think the limit makes sense, but then are tokens limited by the >>>>> same >>>> rules? They need to live in all the same places (query parameters, >>>> headers, >>>> forms) that scopes do and would be subject to the same kinds of >>>> encoding woes that scopes will. Or am I missing something obvious as >>>> to why this isn't a problem for tokens (both bearer tokens and the >>>> public part of MAC tokens) but is a problem for scope strings? >>>>> >>>>> -- Justin >>>>> ________________________________________ >>>>> From: oauth-bounces@ietf.org [oauth-bo= unces@ietf.org] on behalf of >>>>> John Bradley [ve7jtb@ve7jtb.com] >>>>> Sent: Sunday, October 16, 2011 8:11 PM >>>>> To: Eran Hammer-Lahav >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >>>> Proposed Resolutions >>>>> >>>>> Restricting it now in the core spec is going to save a lot of headach= es >> later. >>>>> >>>>> John B. >>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: >>>>> >>>>>> It's an open question for the list. >>>>>> >>>>>> EHL >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de] >>>>>>> Sent: Sunday, October 16, 2011 11:00 AM >>>>>>> To: Mike Jones >>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth >>>>>>> WG; Eran Hammer-Lahav >>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues >>>>>>> & Proposed Resolutions >>>>>>> >>>>>>> On 2011-10-16 18:44, Mike Jones wrote: >>>>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide >>>>>>>> range of >>>>>>> characters in scope was unintentional. The design was limited to >>>>>>> allow simple ASCII strings and URIs." >>>>>>>> ... >>>>>>> >>>>>>> I see. Thanks. >>>>>>> >>>>>>> Is this going to be clarified in -23? >>>>>>> >>>>>>> Best regards, Julian >>>>>> _______________________________________________ >>>>>> 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 --_000_4E1F6AAD24975D4BA5B16804296739435C2479E0TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Monday, October 17, 2011 1:53 PM
To: John Bradley; Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &= amp; Proposed Resolutions

 

+1

 

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: John Bradley = <ve7jtb@ve7jtb.com>
To: Eran Hammer-Lahav <era= n@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Monday, October 17, 2011 12:13 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &= amp; Proposed Resolutions

+1

On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote:

> All I agree with is to limit the scope character-set in the v2 spec to= the subset of ASCII allowed in HTTP header quoted-string, excluding "= and \ so no escaping is needed, ever.
>
> EHL
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>> Sent: Monday, October 17, 2011 8:25 AM
>> To: Eran Hammer-Lahav
>> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues= &
>> Proposed Resolutions
>>
>> It is good that we have an agreement among a few people that more = text
>> needs to be provided in the core specification on the issue of the= scope
>> element.
>>
>> Now, there is still the question of what the text should say. The = questions
>> from my earlier mails are therefore still applicable and need an a= nswer.
>>
>> Ciao
>> Hannes
>>
>> On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote:
>>
>>> I agree.
>>>
>>> EHL
>>>
>>>> -----Original Message-----
>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>>> Sent: Monday, October 17, 2011 6:07 AM
>>>> To: Richer, Justin P.
>>>> Cc: Eran Hammer-Lahav; OAuth WG
>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Ope= n Issues &
>>>> Proposed Resolutions
>>>>
>>>> The scopes cross all of the profiles.
>>>>
>>>> I expect that restricting the character sets for bearer to= kens, MAC,
>>>> and other future variants should be dealt with in those pr= ofiles.
>>>>
>>>> Without restricting scope in core, we leave the possibilit= y of coming
>>>> up with different rules in different profiles e.g. MAC vs = Bearer.
>>>>
>>>> It is probably best to have one rule in core that works ac= ross all the
>> profiles.
>>>>
>>>> John B.
>>>> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote:
>>>>
>>>>> I think the limit makes sense, but then are tokens lim= ited by the
>>>>> same
>>>> rules? They need to live in all the same places (query par= ameters,
>>>> headers,
>>>> forms) that scopes do and would be subject to the same kin= ds of
>>>> encoding woes that scopes will. Or am I missing something = obvious as
>>>> to why this isn't a problem for tokens (both bearer tokens= and the
>>>> public part of MAC tokens) but is a problem for scope stri= ngs?
>>>>>
>>>>> -- Justin
>>>>> ________________________________________
>>>>> From: oauth-= bounces@ietf.org [oauth-bounc= es@ietf.org] on behalf of
>>>>> John Bradley [ve7= jtb@ve7jtb.com]
>>>>> Sent: Sunday, October 16, 2011 8:11 PM
>>>>> To: Eran Hammer-Lahav
>>>>> Cc: OAuth WG
>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09:= Open Issues &
>>>> Proposed Resolutions
>>>>>
>>>>> Restricting it now in the core spec is going to save a= lot of headaches
>> later.
>>>>>
>>>>> John B.
>>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: >>>>>
>>>>>> It's an open question for the list.
>>>>>>
>>>>>> EHL
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>>>>>>> Sent: Sunday, October 16, 2011 11:00 AM
>>>>>>> To: Mike Jones
>>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hanne= s Tschofenig; OAuth
>>>>>>> WG; Eran Hammer-Lahav
>>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-be= arer-09: Open Issues
>>>>>>> & Proposed Resolutions
>>>>>>>
>>>>>>> On 2011-10-16 18:44, Mike Jones wrote:
>>>>>>>> As Eran wrote on 9/30, "The fact that= the v2 spec allows a wide
>>>>>>>> range of
>>>>>>> characters in scope was unintentional. The des= ign was limited to
>>>>>>> allow simple ASCII strings and URIs."
>>>>>>>> ...
>>>>>>>
>>>>>>> I see. Thanks.
>>>>>>>
>>>>>>> Is this going to be clarified in -23?
>>>>>>>
>>>>>>> Best regards, Julian
>>>>>> _______________________________________________ >>>>>> 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
h= ttps://www.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B16804296739435C2479E0TK5EX14MBXC283r_-- From phil.hunt@oracle.com Mon Oct 17 15:40:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57B811E80A2 for ; Mon, 17 Oct 2011 15:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiBnR7pla483 for ; Mon, 17 Oct 2011 15:40:14 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id BA74011E8095 for ; Mon, 17 Oct 2011 15:40:14 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9HMeBPU006012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Oct 2011 22:40:13 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9HMS3Yi016929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Oct 2011 22:28:04 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9HMe6K4027562 for ; Mon, 17 Oct 2011 17:40:06 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Oct 2011 15:40:05 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 17 Oct 2011 15:40:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D1B8F29-2FB1-43E9-92D9-C3837ECBB2D2@oracle.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3! 520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: OAuth WG X-Mailer: Apple Mail (2.1251.1) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090209.4E9CAECE.001D,ss=1,re=0.000,fgs=0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:40:15 -0000 +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote: > All I agree with is to limit the scope character-set in the v2 spec to = the subset of ASCII allowed in HTTP header quoted-string, excluding " = and \ so no escaping is needed, ever. >=20 > EHL >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Monday, October 17, 2011 8:25 AM >> To: Eran Hammer-Lahav >> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG >> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & >> Proposed Resolutions >>=20 >> It is good that we have an agreement among a few people that more = text >> needs to be provided in the core specification on the issue of the = scope >> element. >>=20 >> Now, there is still the question of what the text should say. The = questions >> from my earlier mails are therefore still applicable and need an = answer. >>=20 >> Ciao >> Hannes >>=20 >> On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote: >>=20 >>> I agree. >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Monday, October 17, 2011 6:07 AM >>>> To: Richer, Justin P. >>>> Cc: Eran Hammer-Lahav; OAuth WG >>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues = & >>>> Proposed Resolutions >>>>=20 >>>> The scopes cross all of the profiles. >>>>=20 >>>> I expect that restricting the character sets for bearer tokens, = MAC, >>>> and other future variants should be dealt with in those profiles. >>>>=20 >>>> Without restricting scope in core, we leave the possibility of = coming >>>> up with different rules in different profiles e.g. MAC vs Bearer. >>>>=20 >>>> It is probably best to have one rule in core that works across all = the >> profiles. >>>>=20 >>>> John B. >>>> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote: >>>>=20 >>>>> I think the limit makes sense, but then are tokens limited by the >>>>> same >>>> rules? They need to live in all the same places (query parameters, >>>> headers, >>>> forms) that scopes do and would be subject to the same kinds of >>>> encoding woes that scopes will. Or am I missing something obvious = as >>>> to why this isn't a problem for tokens (both bearer tokens and the >>>> public part of MAC tokens) but is a problem for scope strings? >>>>>=20 >>>>> -- Justin >>>>> ________________________________________ >>>>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of >>>>> John Bradley [ve7jtb@ve7jtb.com] >>>>> Sent: Sunday, October 16, 2011 8:11 PM >>>>> To: Eran Hammer-Lahav >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues = & >>>> Proposed Resolutions >>>>>=20 >>>>> Restricting it now in the core spec is going to save a lot of = headaches >> later. >>>>>=20 >>>>> John B. >>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote: >>>>>=20 >>>>>> It's an open question for the list. >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de] >>>>>>> Sent: Sunday, October 16, 2011 11:00 AM >>>>>>> To: Mike Jones >>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; = OAuth >>>>>>> WG; Eran Hammer-Lahav >>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open = Issues >>>>>>> & Proposed Resolutions >>>>>>>=20 >>>>>>> On 2011-10-16 18:44, Mike Jones wrote: >>>>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide >>>>>>>> range of >>>>>>> characters in scope was unintentional. The design was limited to >>>>>>> allow simple ASCII strings and URIs." >>>>>>>> ... >>>>>>>=20 >>>>>>> I see. Thanks. >>>>>>>=20 >>>>>>> Is this going to be clarified in -23? >>>>>>>=20 >>>>>>> Best regards, Julian >>>>>> _______________________________________________ >>>>>> 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 >>>=20 >>> _______________________________________________ >>> 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 hardjono@mit.edu Mon Oct 17 16:25:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B981F0C62 for ; Mon, 17 Oct 2011 16:25:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPxrRCkprOeX for ; Mon, 17 Oct 2011 16:25:23 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5FC1F0C61 for ; Mon, 17 Oct 2011 16:25:23 -0700 (PDT) X-AuditID: 1209190f-b7f6e6d0000008df-17-4e9cb962ce0b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A1.C0.02271.269BC9E4; Mon, 17 Oct 2011 19:25:22 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p9HNPKlJ003783; Mon, 17 Oct 2011 19:25:21 -0400 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p9HNPJBI014897; Mon, 17 Oct 2011 19:25:20 -0400 Received: from oc11exhub2.exchange.mit.edu (18.9.3.12) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 17 Oct 2011 16:25:05 -0700 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub2.exchange.mit.edu ([18.9.3.12]) with mapi; Mon, 17 Oct 2011 19:25:19 -0400 From: Thomas Hardjono To: "oauth (oauth@ietf.org)" , "oauth-chairs@tools.ietf.org" Date: Mon, 17 Oct 2011 19:25:18 -0400 Thread-Topic: Updated UMA Core spec uploaded ----- FW: New Version Notification for draft-hardjono-oauth-umacore-01.txt Thread-Index: AcyNJAgBF49rq0e/TT+Yl2afGG8HDw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01SXUhTURzn3M15HV69zo8dp4O8JZk0V2HgQ8nyJSlYIlEgQV3d0S2367p3 E2cZ+mStl00N3RyltgXJaGhhZiYmaEyipOylUlrtQVYmZSgiWvd68ePtd35f5384f1yiGI1T 4SbGhliGNlMyuVQRX3xAU/ncpz8y+ZkqWoq2yIrCizGZDiv1+9ew0r8flmVlWIX8hAGZTfWI 1RZfkRv97bOYdYpo6P/mxppBF+EECTgkC2Fk4ZFExBlwZj4kE7CCHAPwfU+uE8h5PA7gvd8B TDzMAti69EIquoYAHPh+TBRcAD74F9yKy8g8+Hb9ZbyA00g7nOtc5nkcl5K5cCXECnQqT0+t BuMFOo1shAue/aK7AHr8b7bcBFkGe7tPCjTgZ1udDmIClpBK+Cl6HxNnToF93aM782+ORGSi Px1+aQ0BoUZCHoKhEa0YzYEddyJbcxF8NOyJSl0gw7un1bub8O5JePckeoC0H6gNlkaNhTaZ OVSl4apohkGsprDAYrIVIIN9EAiflJCZPAxWXlETgMQBlUhkVvv0iji6nnNYJkAmjlHpRNMQ TyVV1hkcRpozXmbtZsRNAIhLqDTi4nVeIwy0oxGxddtSFi6llETLsE6vIGtoG6pFyIrYbTUb xylIzA/zwRQW1aCGapPZtitjeIJQnsiX3xI8BGelLZypRtSnQY5KSYwJAikIRjuzk91euhhQ 8k9JFa9I5FdyJx3jizG+OEZ5hGIbvSupmoHTGivpunu4STvoT3av6Padc3VsutdcatXB9ZTT 2e2v/Wd/qcuZmTZbfkXbVTpwbbI0fZHWLfe1nHn2o8npOzWamhQM+y493bgRkFDvjk/mDSbN 1ar12TfDDvCwO2us9ytre9Jb4pZ/7Nwon8mJxjFVPx//iUyjwPkLA+O3mykpZ6SP5ktYjv4P lMdcA08DAAA= Subject: [OAUTH-WG] Updated UMA Core spec uploaded ----- FW: New Version Notification for draft-hardjono-oauth-umacore-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:25:24 -0000 Rm9sa3MsDQoNCkkgaGF2ZSBqdXN0IHVwbG9hZGVkIHRoZSBsYXRlc3QgcmV2IG9mIHRoZSBVTUEg Q29yZSBzcGVjLg0KKGRyYWZ0LWhhcmRqb25vLW9hdXRoLXVtYWNvcmUtMDEudHh0KS4NCg0KTkIu IFRoZSBsaXN0IG9mIGFsbCB0aGUgY28tYXV0aG9ycyBhcmUgbm93IGF0IHRoZSBlbmQgb2YgdGhl IGRvY3VtZW50Lg0KDQovdGhvbWFzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNl bnQ6IE1vbmRheSwgT2N0b2JlciAxNywgMjAxMSA3OjIwIFBNDQpUbzogVGhvbWFzIEhhcmRqb25v DQpDYzogVGhvbWFzIEhhcmRqb25vDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWhhcmRqb25vLW9hdXRoLXVtYWNvcmUtMDEudHh0DQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1oYXJkam9uby1vYXV0aC11bWFjb3JlLTAxLnR4dCBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRob21hcyBIYXJkam9ubyBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaGFyZGpvbm8tb2F1dGgtdW1hY29y ZQ0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgVXNlci1NYW5hZ2VkIEFjY2VzcyAoVU1BKSBDb3Jl IFByb3RvY29sDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0xMC0xNg0KV0cgSUQ6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDQ4DQoNCkFic3RyYWN0Og0KICAgVGhpcyBz cGVjaWZpY2F0aW9uIGRlZmluZXMgdGhlIFVzZXItTWFuYWdlZCBBY2Nlc3MgKFVNQSkgY29yZQ0K ICAgcHJvdG9jb2wuICBUaGlzIHByb3RvY29sIHByb3ZpZGVzIGEgbWV0aG9kIGZvciB1c2VycyB0 byBjb250cm9sDQogICBhY2Nlc3MgdG8gdGhlaXIgcHJvdGVjdGVkIHJlc291cmNlcywgcmVzaWRp bmcgb24gYW55IG51bWJlciBvZiBob3N0DQogICBzaXRlcywgdGhyb3VnaCBhbiBhdXRob3JpemF0 aW9uIG1hbmFnZXIgdGhhdCBnb3Zlcm5zIGFjY2VzcyBkZWNpc2lvbnMNCiAgIGJhc2VkIG9uIHVz ZXIgcG9saWN5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg== From julian.reschke@gmx.de Tue Oct 18 06:50:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A178F21F8B5D for ; Tue, 18 Oct 2011 06:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+aeC0ajGXtR for ; Tue, 18 Oct 2011 06:50:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9C9B421F8AD8 for ; Tue, 18 Oct 2011 06:50:18 -0700 (PDT) Received: (qmail invoked by alias); 18 Oct 2011 13:50:16 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp025) with SMTP; 18 Oct 2011 15:50:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18cdQwe1ywcabl7LyThCWNG8j69K+5788Q6W8ytYa afEgYLHIyX1Ohr Message-ID: <4E9D8414.4030107@gmx.de> Date: Tue, 18 Oct 2011 15:50:12 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 13:50:19 -0000 On 2011-10-17 20:53, Eran Hammer-Lahav wrote: > All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever. You also need to have one character reserved as delimiter for multiple scopes inside quoted-string, so is SP out? Best regards, Julian From eran@hueniverse.com Tue Oct 18 08:40:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B6E21F8B87 for ; Tue, 18 Oct 2011 08:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1ua79ff9chB for ; Tue, 18 Oct 2011 08:40:13 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 1ACF921F8672 for ; Tue, 18 Oct 2011 08:40:13 -0700 (PDT) Received: (qmail 26283 invoked from network); 18 Oct 2011 15:38:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Oct 2011 15:38:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 18 Oct 2011 08:38:19 -0700 From: Eran Hammer-Lahav To: Julian Reschke , OAuth WG Date: Tue, 18 Oct 2011 08:38:13 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyNnN9Z4p6pyoerR0eGua306sBBYgADu18w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452604B9314@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9D8414.4030107@gmx.de> In-Reply-To: <4E9D8414.4030107@gmx.de> 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] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:40:14 -0000 Space is allowed inside a quoted string and is already not allowed inside e= ach scope string. EHL > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, October 18, 2011 6:50 AM > To: Eran Hammer-Lahav > Cc: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > Proposed Resolutions >=20 > On 2011-10-17 20:53, Eran Hammer-Lahav wrote: > > All I agree with is to limit the scope character-set in the v2 spec to = the > subset of ASCII allowed in HTTP header quoted-string, excluding " and \ s= o no > escaping is needed, ever. >=20 > You also need to have one character reserved as delimiter for multiple > scopes inside quoted-string, so is SP out? >=20 > Best regards, Julian From julian.reschke@gmx.de Tue Oct 18 09:40:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0451421F8B9E for ; Tue, 18 Oct 2011 09:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.128 X-Spam-Level: X-Spam-Status: No, score=-103.128 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T91vq6TgtAwC for ; Tue, 18 Oct 2011 09:40:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2264721F8B98 for ; Tue, 18 Oct 2011 09:40:01 -0700 (PDT) Received: (qmail invoked by alias); 18 Oct 2011 16:40:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp005) with SMTP; 18 Oct 2011 18:40:00 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Xsw4sPy0X88DczoEVv/jMeRVeQvmmeJ7gKOzo7f dJoBzWtg1vCqWf Message-ID: <4E9DABDA.9060306@gmx.de> Date: Tue, 18 Oct 2011 18:39:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9D8414.4030107@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B9314@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B9314@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:40:03 -0000 On 2011-10-18 17:38, Eran Hammer-Lahav wrote: > Space is allowed inside a quoted string and is already not allowed inside each scope string. > > EHL > ... a) yes. b) well: The value of the scope parameter is expressed as a list of space- delimited, case sensitive strings. The strings are defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. That certainly implies that you can't have a space inside a token, but it could be clearer. Optimally, state the character repertoire precisely: scopetokenchar = %x21 / %x23-5B / %x5D-7E ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII ? Best regards, Julian From wmills@yahoo-inc.com Tue Oct 18 09:45:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E252121F86F6 for ; Tue, 18 Oct 2011 09:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.298 X-Spam-Level: X-Spam-Status: No, score=-17.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIJwgzkywAjZ for ; Tue, 18 Oct 2011 09:45:53 -0700 (PDT) Received: from nm21-vm0.bullet.mail.sp2.yahoo.com (nm21-vm0.bullet.mail.sp2.yahoo.com [98.139.91.220]) by ietfa.amsl.com (Postfix) with SMTP id 011A821F8713 for ; Tue, 18 Oct 2011 09:45:45 -0700 (PDT) Received: from [98.139.91.63] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 18 Oct 2011 16:45:45 -0000 Received: from [98.139.91.25] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 18 Oct 2011 16:45:45 -0000 Received: from [127.0.0.1] by omp1025.mail.sp2.yahoo.com with NNFMP; 18 Oct 2011 16:45:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 880972.6179.bm@omp1025.mail.sp2.yahoo.com Received: (qmail 18240 invoked by uid 60001); 18 Oct 2011 16:45:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1318956345; bh=2B8uI+ERrBIGOqMsEtfeFa0xTsUZMW3VUmRUHl/w6sk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=I8XchztpUhYrtL/KGcOv2sl7pBRJzkPjuNnsc/neqtoASJtlsjgEHxQN6CnAIKBCcvPByKmYqbJ5X5qLFFCXkp8wGFPv08cxXH6g85eCExWPi9gGt6leW85UJQcz6oEqfXKLaiBHJL13sMRnteL4Os+UekXwMqS0ui7Pr7VB3kQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=I9KTYyjAijXIhnyrlEvEfgdM9nqlAHZYUmlSDpm+ecqcjAEToLUTEZb11lTQbxZLJDdUJttH9twKG02xR+jAa1oBclHIvRzrgiTTcNmFedjrwQCijacBh0KBlNa6++yPDSXJQAeO0v4tv7/09msKwM5x9Ik9PiYrtEkTlI30gfM=; X-YMail-OSG: Lf1V_AkVM1m7hNmRYpBjnSI8F6QzoNy0PrfwdHUTks8Fvfh j0qapHCvfuq5A50FIyKcovrPrOvcwKkuAO7rFt4th84e2VAU9eO8pszzwLCM LLtxPpzcwM82K_PusR2_yofVEoZBKCjkbHLD1_ujhg3_UZGjGK1.k_jteEnO Bs8zpGXhqsHbYlGNRgJxWrE88EmBho4.39ZPLJ2LOxh3FH6k1OUiNEdrLK2C 2hIpV1QpZUCgXRXUOAIOeJmOAy3v5EMNDVdoXIGketdGKUaAXljFTh9VGKRV BzUcLjcdOpD14dxxJHmQ3m38xxCMDFTYXj3FEULspi1Q2PIrtERLJed8MFDu MKfISIr9.p5DAscydRdB6nbIOCO1j_PbPNjdDqgvVNPbDygaDeZZImyBKwXa d.AsGRDveUWU- Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Tue, 18 Oct 2011 09:45:45 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><7A22B287-CC99-4FD7-84DF-8FF5DA871FC6@gmx.net><4E1F6AAD24975D4BA5B16804296739435C23CAFE@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-35 20DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0AE463C6-254C-4776-A6EC-08DBE3F8A7F1@ve7jtb.com> <1318884797.81519.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C2479E0@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1318956345.58284.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 18 Oct 2011 09:45:45 -0700 (PDT) From: William Mills To: Mike Jones , John Bradley , Eran Hammer-Lahav In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C2479E0@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-616203687-1318956345=:58284" Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:45:55 -0000 --0-616203687-1318956345=:58284 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Anyone objecting here?=0A=0A=0A=0A________________________________=0AFrom: = Mike Jones =0ATo: William Mills ; John Bradley ; Eran Hammer-Lahav =0ACc: OAuth WG =0ASent: Monday, October 17, 2011 3= :25 PM=0ASubject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues= & Proposed Resolutions=0A=0A=0A =0A+1=0A=A0=0AFrom:oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills=0ASent: Monday, = October 17, 2011 1:53 PM=0ATo: John Bradley; Eran Hammer-Lahav=0ACc: OAuth = WG=0ASubject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & P= roposed Resolutions=0A=A0=0A+1=0A=A0=0A=0A________________________________= =0A =0AFrom:John Bradley =0ATo: Eran Hammer-Lahav =0ACc: OAuth WG =0ASent: Monday, October 17,= 2011 12:13 PM=0ASubject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Ope= n Issues & Proposed Resolutions=0A=0A+1=0A=0AOn 2011-10-17, at 11:53 AM, Er= an Hammer-Lahav wrote:=0A=0A> All I agree with is to limit the scope charac= ter-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted= -string, excluding " and \ so no escaping is needed, ever.=0A> =0A> EHL=0A>= =0A>> -----Original Message-----=0A>> From: Hannes Tschofenig [mailto:hann= es.tschofenig@gmx.net]=0A>> Sent: Monday, October 17, 2011 8:25 AM=0A>> To:= Eran Hammer-Lahav=0A>> Cc: Hannes Tschofenig; John Bradley; Richer, Justin= P.; OAuth WG=0A>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: O= pen Issues &=0A>> Proposed Resolutions=0A>> =0A>> It is good that we have a= n agreement among a few people that more text=0A>> needs to be provided in = the core specification on the issue of the scope=0A>> element.=0A>> =0A>> N= ow, there is still the question of what the text should say. The questions= =0A>> from my earlier mails are therefore still applicable and need an answ= er.=0A>> =0A>> Ciao=0A>> Hannes=0A>> =0A>> On Oct 17, 2011, at 7:27 AM, Era= n Hammer-Lahav wrote:=0A>> =0A>>> I agree.=0A>>> =0A>>> EHL=0A>>> =0A>>>> -= ----Original Message-----=0A>>>> From: John Bradley [mailto:ve7jtb@ve7jtb.c= om]=0A>>>> Sent: Monday, October 17, 2011 6:07 AM=0A>>>> To: Richer, Justin= P.=0A>>>> Cc: Eran Hammer-Lahav; OAuth WG=0A>>>> Subject: Re: [OAUTH-WG] d= raft-ietf-oauth-v2-bearer-09: Open Issues &=0A>>>> Proposed Resolutions=0A>= >>> =0A>>>> The scopes cross all of the profiles.=0A>>>> =0A>>>> I expect t= hat restricting the character sets for bearer tokens, MAC,=0A>>>> and other= future variants should be dealt with in those profiles.=0A>>>> =0A>>>> Wit= hout restricting scope in core, we leave the possibility of coming=0A>>>> u= p with different rules in different profiles e.g. MAC vs Bearer.=0A>>>> =0A= >>>> It is probably best to have one rule in core that works across all the= =0A>> profiles.=0A>>>> =0A>>>> John B.=0A>>>> On 2011-10-16, at 7:19 PM, Ri= cher, Justin P. wrote:=0A>>>> =0A>>>>> I think the limit makes sense, but t= hen are tokens limited by the=0A>>>>> same=0A>>>> rules? They need to live = in all the same places (query parameters,=0A>>>> headers,=0A>>>> forms) tha= t scopes do and would be subject to the same kinds of=0A>>>> encoding woes = that scopes will. Or am I missing something obvious as=0A>>>> to why this i= sn't a problem for tokens (both bearer tokens and the=0A>>>> public part of= MAC tokens) but is a problem for scope strings?=0A>>>>> =0A>>>>> -- Justin= =0A>>>>> ________________________________________=0A>>>>> From: oauth-bounc= es@ietf.org [oauth-bounces@ietf.org] on behalf of=0A>>>>> John Bradley [ve7= jtb@ve7jtb.com]=0A>>>>> Sent: Sunday, October 16, 2011 8:11 PM=0A>>>>> To: = Eran Hammer-Lahav=0A>>>>> Cc: OAuth WG=0A>>>>> Subject: Re: [OAUTH-WG] draf= t-ietf-oauth-v2-bearer-09: Open Issues &=0A>>>> Proposed Resolutions=0A>>>>= > =0A>>>>> Restricting it now in the core spec is going to save a lot of he= adaches=0A>> later.=0A>>>>> =0A>>>>> John B.=0A>>>>> On 2011-10-16, at 3:54= PM, Eran Hammer-Lahav wrote:=0A>>>>> =0A>>>>>> It's an open question for t= he list.=0A>>>>>> =0A>>>>>> EHL=0A>>>>>> =0A>>>>>>> -----Original Message--= ---=0A>>>>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de]=0A>>>>>>>= Sent: Sunday, October 16, 2011 11:00 AM=0A>>>>>>> To: Mike Jones=0A>>>>>>>= Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth=0A>>>>>>= > WG; Eran Hammer-Lahav=0A>>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-= v2-bearer-09: Open Issues=0A>>>>>>> & Proposed Resolutions=0A>>>>>>> =0A>>>= >>>> On 2011-10-16 18:44, Mike Jones wrote:=0A>>>>>>>> As Eran wrote on 9/3= 0, "The fact that the v2 spec allows a wide=0A>>>>>>>> range of=0A>>>>>>> c= haracters in scope was unintentional. The design was limited to=0A>>>>>>> a= llow simple ASCII strings and URIs."=0A>>>>>>>> ...=0A>>>>>>> =0A>>>>>>> I = see. Thanks.=0A>>>>>>> =0A>>>>>>> Is this going to be clarified in -23?=0A>= >>>>>> =0A>>>>>>> Best regards, Julian=0A>>>>>> ___________________________= ____________________=0A>>>>>> OAuth mailing list=0A>>>>>> OAuth@ietf.org=0A= >>>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>>> =0A>>>>> _______= ________________________________________=0A>>>>> OAuth mailing list=0A>>>>>= OAuth@ietf.org=0A>>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>> = =0A>>> _______________________________________________=0A>>> OAuth mailing = list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/oauth= =0A> =0A=0A=0A_______________________________________________=0AOAuth maili= ng list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-616203687-1318956345=:58284 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Anyone objecting here?

=
From: Mike Jones <Michael.Jones@microsoft= .com>
To: William Mi= lls <wmills@yahoo-inc.com>; John Bradley <ve7jtb@ve7jtb.com>; E= ran Hammer-Lahav <eran@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Monday, October 17, 2011 3:25 PMSubject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions
<= /font>
=0A=0A =0A =0A=0A= =0A
=0A
=0A
+1 =0A
 
=0A
=0A
=0A
From: oauth-bounces@ietf.org [mailto:oaut= h-bounces@ietf.org]=0AOn Behalf Of William Mills
=0ASent: = Monday, October 17, 2011 1:53 PM
=0ATo: John Bradley; Eran Hammer= -Lahav
=0ACc: OAuth WG
=0ASubject: Re: [OAUTH-WG] draft= -ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions =0A
=0A
=0A
 
= =0A
=0A
=0A
+1
=0A
=0A
=0A<= div class=3D"yiv543210030MsoNormal" style=3D"background:white;">  
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
<= span style=3D"font-size:10.0pt;color:black;">From: John Bradley <ve7jtb@ve7jtb.com>
=0ATo: Eran Hammer-Lahav <<= a rel=3D"nofollow" ymailto=3D"mailto:eran@hueniverse.com" target=3D"_blank"= href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com>
=0AC= c: OAuth WG <oauth@ietf.org>
= =0ASent: Monday, October 17, 2011 12:13 PM
=0ASubject: Re:= [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resol= utions
=0A
=0A+1
=0A
=0AOn = 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote:
=0A
=0A> All I a= gree with is to limit the scope character-set in the v2 spec to the subset = of ASCII allowed in HTTP header quoted-string, excluding " and \ so no esca= ping is needed, ever.
=0A>
=0A> EHL
=0A>
=0A>>= -----Original Message-----
=0A>> From: Hannes Tschofenig [mailto:= hannes.tschofenig@gmx.net= ]
=0A>> Sent: Monday, October 17, 2011 8:25 AM
=0A>> = To: Eran Hammer-Lahav
=0A>> Cc: Hannes Tschofenig; John Bradley; R= icher, Justin P.; OAuth WG
=0A>> Subject: Re: [OAUTH-WG] draft-iet= f-oauth-v2-bearer-09: Open Issues &
=0A>> Proposed Resolutions=
=0A>>
=0A>> It is good that we have an agreement among = a few people that more text
=0A>> needs to be provided in the core= specification on the issue of the scope
=0A>> element.
=0A>= >
=0A>> Now, there is still the question of what the text shou= ld say. The questions
=0A>> from my earlier mails are therefore st= ill applicable and need an answer.
=0A>>
=0A>> Ciao
= =0A>> Hannes
=0A>>
=0A>> On Oct 17, 2011, at 7:27 = AM, Eran Hammer-Lahav wrote:
=0A>>
=0A>>> I agree.=0A>>>
=0A>>> EHL
=0A>>>
=0A>>= >> -----Original Message-----
=0A>>>> From: John Bradl= ey [mailto:ve7jtb@ve7jtb.com]
=0A= >>>> Sent: Monday, October 17, 2011 6:07 AM
=0A>>>&= gt; To: Richer, Justin P.
=0A>>>> Cc: Eran Hammer-Lahav; OAu= th WG
=0A>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-be= arer-09: Open Issues &
=0A>>>> Proposed Resolutions
= =0A>>>>
=0A>>>> The scopes cross all of the pro= files.
=0A>>>>
=0A>>>> I expect that restric= ting the character sets for bearer tokens, MAC,
=0A>>>> and = other future variants should be dealt with in those profiles.
=0A>>= ;>>
=0A>>>> Without restricting scope in core, we lea= ve the possibility of coming
=0A>>>> up with different rules= in different profiles e.g. MAC vs Bearer.
=0A>>>>
=0A&g= t;>>> It is probably best to have one rule in core that works acro= ss all the
=0A>> profiles.
=0A>>>>
=0A>>&= gt;> John B.
=0A>>>> On 2011-10-16, at 7:19 PM, Richer, J= ustin P. wrote:
=0A>>>>
=0A>>>>> I think = the limit makes sense, but then are tokens limited by the
=0A>>>= ;>> same
=0A>>>> rules? They need to live in all the s= ame places (query parameters,
=0A>>>> headers,
=0A>>= ;>> forms) that scopes do and would be subject to the same kinds of=0A>>>> encoding woes that scopes will. Or am I missing somet= hing obvious as
=0A>>>> to why this isn't a problem for toke= ns (both bearer tokens and the
=0A>>>> public part of MAC to= kens) but is a problem for scope strings?
=0A>>>>>
= =0A>>>>> -- Justin
=0A>>>>> ______________= __________________________
=0A>>>>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of
=0A&g= t;>>>> John Bradley [ve7jtb@v= e7jtb.com]
=0A>>>>> Sent: Sunday, October 16, 2011 8:= 11 PM
=0A>>>>> To: Eran Hammer-Lahav
=0A>>>&g= t;> Cc: OAuth WG
=0A>>>>> Subject: Re: [OAUTH-WG] draf= t-ietf-oauth-v2-bearer-09: Open Issues &
=0A>>>> Propose= d Resolutions
=0A>>>>>
=0A>>>>> Restri= cting it now in the core spec is going to save a lot of headaches
=0A>= ;> later.
=0A>>>>>
=0A>>>>> John B.=
=0A>>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wr= ote:
=0A>>>>>
=0A>>>>>> It's an ope= n question for the list.
=0A>>>>>>
=0A>>>= >>> EHL
=0A>>>>>>
=0A>>>>>= >> -----Original Message-----
=0A>>>>>>> From= : Julian Reschke [mailto:julian.r= eschke@gmx.de]
=0A>>>>>>> Sent: Sunday, October= 16, 2011 11:00 AM
=0A>>>>>>> To: Mike Jones
=0A= >>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hanne= s Tschofenig; OAuth
=0A>>>>>>> WG; Eran Hammer-Laha= v
=0A>>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oau= th-v2-bearer-09: Open Issues
=0A>>>>>>> & Propo= sed Resolutions
=0A>>>>>>>
=0A>>>>&= gt;>> On 2011-10-16 18:44, Mike Jones wrote:
=0A>>>>&g= t;>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a w= ide
=0A>>>>>>>> range of
=0A>>>>&= gt;>> characters in scope was unintentional. The design was limited t= o
=0A>>>>>>> allow simple ASCII strings and URIs."<= br>=0A>>>>>>>> ...
=0A>>>>>>&g= t;
=0A>>>>>>> I see. Thanks.
=0A>>>>= ;>>>
=0A>>>>>>> Is this going to be clari= fied in -23?
=0A>>>>>>>
=0A>>>>>= >> Best regards, Julian
=0A>>>>>> ______________= _________________________________
=0A>>>>>> OAuth mail= ing list
=0A>>>>>> OAuth@i= etf.org
=0A>>>>>> https://www.ietf= .org/mailman/listinfo/oauth
=0A>>>>>
=0A>>&= gt;>> _______________________________________________
=0A>>&= gt;>> OAuth mailing list
=0A>>>>> OAuth@ietf.org
=0A>>>>> ht= tps://www.ietf.org/mailman/listinfo/oauth
=0A>>>
=0A>= ;>> _______________________________________________
=0A>>>= ; OAuth mailing list
=0A>>> OAuth@i= etf.org
=0A>>> https://www.ietf.org/mailm= an/listinfo/oauth
=0A>
=0A
=0A
=0A_____________________= __________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/ma= ilman/listinfo/oauth
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A=0A


--0-616203687-1318956345=:58284-- From hannes.tschofenig@gmx.net Tue Oct 18 17:22:02 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E2321F8634 for ; Tue, 18 Oct 2011 17:22:02 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as9apUHxqGWA for ; Tue, 18 Oct 2011 17:22:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 338A521F8511 for ; Tue, 18 Oct 2011 17:22:00 -0700 (PDT) Received: (qmail invoked by alias); 19 Oct 2011 00:21:59 -0000 Received: from unknown (EHLO [10.2.2.99]) [64.9.249.121] by mail.gmx.net (mp007) with SMTP; 19 Oct 2011 02:21:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+SpW8dct+SocDHjvQQ8IQTFNExX8AfjcmH6/ukTp 5LkSgR5cPVruV2 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Oct 2011 17:21:56 -0700 Message-Id: <0190D8E8-FC04-4645-A142-995CF56F7384@gmx.net> To: OAuth WG , Mike Jones Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Editorial comments for draft-ietf-oauth-v2-bearer-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 00:22:02 -0000 Hi Mike,=20 based on our discussion I suggest to make the following minor editorial = changes to the specification. Let me provide specific text proposals.=20 I recommend to extend the abstract a little bit. The current text does = not tell the reader a lot and the RFC editor will require more text = (because it is too short) FROM:=20 " Abstract This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. " TO: " Abstract This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. A bearer token has = the=20 property that any party in possession of it (a "bearer") can use it = to get=20 access to a resource granted (without demonstrating =20 possession of a cryptographic key). To prevent misuse, the bearer = token=20 has to be protected in storage and in transport.=20 " To make the introduction of Section 2 more readable I suggest the = following modified text (that replaces the existing text).=20 ----- 2. Authenticated Requests To access a protected resource the client needs to present the bearer = token=20 to the resource server. This document defines three ways to encode = the token=20 into a request, namely=20 =20 1) Authorization Request Headers (described in Section 2.1) 2) Form-Encoded Body Parameter (described in Section 2.2) =20 3) URI Query Parameter (described in Section 2.3) =20 The usage of the authorization request headers is the preferred = mechanism.=20 Resource servers MUST implement the authorization request header = mechanism=20 and MAY implement other methods. Form-Encoded Body Parameter and URI Query Parameter are fall-back = solutions=20 for environments where authorization request headers cannot be used. = They=20 are therefore NOT RECOMMENDED for usage due to security deficiencies, = as=20 documented in Section 4. They are nevertheless included in this = specification=20 to describe existing deployments. =20 Clients MUST NOT use more than one method to transmit the token in a = single=20 request. ------=20 I also suggest to Section 2.4 into Section 3. The security consideration = section then becomes Section 4.=20 Ciao Hannes From eran@hueniverse.com Tue Oct 18 20:38:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEB41F0C87 for ; Tue, 18 Oct 2011 20:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JCc29JfV2KU for ; Tue, 18 Oct 2011 20:38:39 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 962881F0C84 for ; Tue, 18 Oct 2011 20:38:35 -0700 (PDT) Received: (qmail 6878 invoked from network); 19 Oct 2011 03:38:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Oct 2011 03:38:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 18 Oct 2011 20:38:32 -0700 From: Eran Hammer-Lahav To: qijun83 Date: Tue, 18 Oct 2011 20:38:25 -0700 Thread-Topic: draft-ietf-oauth-v2-22 Thread-Index: AcyOEJKbeeFMgKOVSOyPSGRuIqW8PQ== 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: multipart/alternative; boundary="_000_AD5D14C6DB18416386C5441956EC6617hueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-22 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 03:38:39 -0000 --_000_AD5D14C6DB18416386C5441956EC6617hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VuZGluZyB0byB0aGUgcmlnaHQgcGxhY2UuDQoNCk9uIE9jdCAxOCwgMjAxMSwgYXQgMjA6MzYs ICJxaWp1bjgzIiA8cWlqdW44M0BnbWFpbC5jb208bWFpbHRvOnFpanVuODNAZ21haWwuY29tPj4g d3JvdGU6DQoNCkRlYXIgU2lyLA0KDQpJdCdzIHJlYWxseSB2ZXJ5IHBsZWFzdXJlIGZvciBtZSB0 byB3cml0ZSB0byB5b3UgZm9yIGFza2luZyBzb21lIHF1ZXN0aW9ucyBhYm91dCBvYXV0aC12Mi0y MiBhcyBmb2xsb3dzLg0KDQpJbiBzZWN0aW9uIDIuMyAoQ2xpZW50IEF1dGhlbnRpY2F0aW9uKSwg aXQgaXMgcmVjb21tZW5kZWQgdG8gdXNlIHRoZSBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIHNj aGVtZQ0KbGlrZSAiQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYw TTJKVyIsIHdoaWNoIGlzIGluY2x1ZGVkIG9mICJ1c2VyX2lkIiBhbmQNCiJwYXNzd29yZCIgYXMg ZGVmaW5lZCBpbiBbUkZDMjYxNzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyNjE3Pl0s IGluc3RlYWQgb2YgdXNpbmcgdGhlIHBhcmFtZXRlcnMgb2YgImNsaWVudF9pZCIgYW5kICJjbGll bnRfc2VjcmV0IiBpbg0KSFRUUCByZXF1ZXN0IGJvZHkuDQpJIHdhbnQgdG8ga25vdywNCigxKS4g d2hldGhlciAidXNlcl9pZCIgZXF1YWxzIHRvICJjbGllbnRfaWQiLCBhbmQgInBhc3N3b3JkIiBl cXVhbHMgdG8gImNsaWVudF9zZWNyZXQiLg0KKDIpLiBhbmQgd2hldGhlciBpdCBpcyBhbGxvd2Vk IHRvIHVzZSBib3RoIG9mIHRoZSAgSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiBzY2hlbWUgYW5k IHRoZSBjbGllbnQNCmNyZWRlbnRpYWxzIGluIHRoZSByZXF1ZXN0IGJvZHkgYXQgdGhlIHNhbWUg dGltZS4NCg0KTG9va2luZyBmb3J3YXJkIHRvIGhlYXJpbmcgZnJvbSB5b3UuDQoNCllvdXJzLCBz aW5jZXJlbHkNClFpanVuIFpoYW5nDQoNCg== --_000_AD5D14C6DB18416386C5441956EC6617hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+U2VuZGluZyB0 byB0aGUgcmlnaHQgcGxhY2UuJm5ic3A7PGJyPjxicj5PbiBPY3QgMTgsIDIwMTEsIGF0IDIwOjM2 LCAicWlqdW44MyIgJmx0OzxhIGhyZWY9Im1haWx0bzpxaWp1bjgzQGdtYWlsLmNvbSI+cWlqdW44 M0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj5EZWFyIFNpciw8YnI+PGJyPkl0J3MgcmVhbGx5IHZlcnkg cGxlYXN1cmUgZm9yIG1lIHRvIHdyaXRlIHRvIHlvdSBmb3IgYXNraW5nIHNvbWUgcXVlc3Rpb25z IGFib3V0IG9hdXRoLXYyLTIyIGFzIGZvbGxvd3MuPGJyPjxicj5JbiBzZWN0aW9uIDIuMyAoQ2xp ZW50IEF1dGhlbnRpY2F0aW9uKSwgaXQgaXMgcmVjb21tZW5kZWQgdG8gdXNlIHRoZSBIVFRQIEJh c2ljDQogICBhdXRoZW50aWNhdGlvbiBzY2hlbWUgPGJyPmxpa2UgIkF1dGhvcml6YXRpb246IEJh c2ljIGN6WkNhR1JTYTNGME16cG5XREZtUW1GME0ySlciLCB3aGljaCBpcyBpbmNsdWRlZCBvZiAi dXNlcl9pZCIgYW5kIDxicj4icGFzc3dvcmQiIGFzIGRlZmluZWQgaW4gWzxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzI2MTciIHRpdGxlPSImcXVvdDtIVFRQIEF1dGhlbnRp Y2F0aW9uOiBCYXNpYyBhbmQgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNhdGlvbiZxdW90OyI+UkZD MjYxNzwvYT5dLCBpbnN0ZWFkIG9mIHVzaW5nIHRoZSBwYXJhbWV0ZXJzIG9mICJjbGllbnRfaWQi IGFuZCAiY2xpZW50X3NlY3JldCIgaW4gPGJyPg0KSFRUUCByZXF1ZXN0IGJvZHkuIDxicj5JIHdh bnQgdG8ga25vdywgPGJyPigxKS4gd2hldGhlciAidXNlcl9pZCIgZXF1YWxzIHRvICJjbGllbnRf aWQiLCBhbmQgInBhc3N3b3JkIiBlcXVhbHMgdG8gImNsaWVudF9zZWNyZXQiLiA8YnI+KDIpLiBh bmQgd2hldGhlciBpdCBpcyBhbGxvd2VkIHRvIHVzZSBib3RoIG9mIHRoZSZuYnNwOyBIVFRQIEJh c2ljDQogICBhdXRoZW50aWNhdGlvbiBzY2hlbWUgYW5kIHRoZQ0KICAgY2xpZW50IDxicj5jcmVk ZW50aWFscyBpbiB0aGUgcmVxdWVzdCBib2R5IGF0IHRoZSBzYW1lIHRpbWUuPGJyPjxicj5Mb29r aW5nIGZvcndhcmQgdG8gaGVhcmluZyBmcm9tIHlvdS48YnI+PGJyPllvdXJzLCBzaW5jZXJlbHk8 YnI+UWlqdW4gWmhhbmc8YnI+PGJyPg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_AD5D14C6DB18416386C5441956EC6617hueniversecom_-- From mscurtescu@google.com Wed Oct 19 10:24:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9211E80CA for ; Wed, 19 Oct 2011 10:24:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSyJUA73ReIg for ; Wed, 19 Oct 2011 10:24:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5932011E80C9 for ; Wed, 19 Oct 2011 10:24:20 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p9JHOJum023935 for ; Wed, 19 Oct 2011 10:24:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319045059; bh=azW4eb/+5CJjquZYiwZmxXnP6cw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=iP75HT29ct381KwRwLNIVaN3r24iKMbHuAu/tK8aut7nzaEU+JYBuFbkvIg0SP/lI SpwBvG/W8+Dn5TkFZG+Ew== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=Ql+85gH5L8qoqsbfcFEEiLAgwVJj35Iv9roIhX/6pMFQgs0KEp+B8E3Hp0Og0AXS1 zWR+pwYTrzv0pIYNKmAqQ== Received: from yxl11 (yxl11.prod.google.com [10.190.3.203]) by wpaz33.hot.corp.google.com with ESMTP id p9JHLqGu008580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 19 Oct 2011 10:24:18 -0700 Received: by yxl11 with SMTP id 11so2835649yxl.9 for ; Wed, 19 Oct 2011 10:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=AsZabyxK3SQ87GFKfndO16GQjoyIyGzh7ERN54cfMWk=; b=Jz9BtcT1QPXbvkTBeyQAxuYxpo7osnNKLaGunX1vU3W2M9fvGpsIunEOnCv187z7EF 4s2LOtJj3tk8YuX/QJIw== Received: by 10.101.163.33 with SMTP id q33mr1723566ano.145.1319045054368; Wed, 19 Oct 2011 10:24:14 -0700 (PDT) Received: by 10.101.163.33 with SMTP id q33mr1723559ano.145.1319045054099; Wed, 19 Oct 2011 10:24:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.14 with HTTP; Wed, 19 Oct 2011 10:23:54 -0700 (PDT) In-Reply-To: <4E9DABDA.9060306@gmx.de> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9D8414.4030107@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B9314@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9DABDA.9060306@gmx.de> From: Marius Scurtescu Date: Wed, 19 Oct 2011 10:23:54 -0700 Message-ID: To: Julian Reschke 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] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:24:21 -0000 Marius On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke wro= te: > On 2011-10-18 17:38, Eran Hammer-Lahav wrote: >> >> Space is allowed inside a quoted string and is already not allowed insid= e >> each scope string. >> >> EHL >> ... > > a) yes. > > b) well: > > =A0 The value of the scope parameter is expressed as a list of space- > =A0 delimited, case sensitive strings. =A0The strings are defined by the > =A0 authorization server. =A0If the value contains multiple space-delimit= ed > =A0 strings, their order does not matter, and each string adds an > =A0 additional access range to the requested scope. > > That certainly implies that you can't have a space inside a token, but it > could be clearer. > > Optimally, state the character repertoire precisely: > > =A0scopetokenchar =3D =A0%x21 / %x23-5B / %x5D-7E > =A0; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII > > ? Is this covering all characters allowed in a URI? Why not define scopes as a list of URIs? > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From Michael.Jones@microsoft.com Wed Oct 19 10:27:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A6321F8B63 for ; Wed, 19 Oct 2011 10:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT9kX+kX10i5 for ; Wed, 19 Oct 2011 10:26:59 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id D559621F8B46 for ; Wed, 19 Oct 2011 10:26:59 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Oct 2011 10:26:59 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 10:26:59 -0700 From: Mike Jones To: Marius Scurtescu , Julian Reschke Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyOhEX2MoapwDAFQeCnbrefR2l5FA== Date: Wed, 19 Oct 2011 17:26:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24A747@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:27:00 -0000 Yes, it covers all the characters legal in URIs. Per earlier discussion on= the list, scopes are not restricted to being URIs, as existing practice in= cludes scope elements that are not URIs such as "email" "profile", and "ope= nid". -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= arius Scurtescu Sent: Wednesday, October 19, 2011 10:24 AM To: Julian Reschke Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions Marius On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke wro= te: > On 2011-10-18 17:38, Eran Hammer-Lahav wrote: >> >> Space is allowed inside a quoted string and is already not allowed=20 >> inside each scope string. >> >> EHL >> ... > > a) yes. > > b) well: > > =A0 The value of the scope parameter is expressed as a list of space- > =A0 delimited, case sensitive strings. =A0The strings are defined by the > =A0 authorization server. =A0If the value contains multiple=20 > space-delimited > =A0 strings, their order does not matter, and each string adds an > =A0 additional access range to the requested scope. > > That certainly implies that you can't have a space inside a token, but=20 > it could be clearer. > > Optimally, state the character repertoire precisely: > > =A0scopetokenchar =3D =A0%x21 / %x23-5B / %x5D-7E > =A0; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII > > ? Is this covering all characters allowed in a URI? Why not define scopes as = a list of URIs? > > Best regards, Julian > _______________________________________________ > 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 mscurtescu@google.com Wed Oct 19 10:31:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C8921F8C1B for ; Wed, 19 Oct 2011 10:31:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE1AWpu8+KEH for ; Wed, 19 Oct 2011 10:31:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C12CD21F84CF for ; Wed, 19 Oct 2011 10:31:10 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p9JHV9ig031842 for ; Wed, 19 Oct 2011 10:31:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319045470; bh=91vaxjg/Afz63uzdWhEceuEEmCw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=xs4bSaj0meS74MlQE2dFW62jCWuU3XXz+BAyxe0KauZWT5tyBFB9ZllVDijZ6dVc2 6aJShns8PzxZeDTkexl2Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=CzUqRcEPCNrKOTJKBJ3Mu3Qj+ay081B5jo0rWCneSmk3p2y6GdMaTe85w7ZheuCrk 9R5TB1Yn1BO7rdDklWoJw== Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by wpaz29.hot.corp.google.com with ESMTP id p9JHM3SV029334 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 19 Oct 2011 10:31:08 -0700 Received: by vws18 with SMTP id 18so2322071vws.9 for ; Wed, 19 Oct 2011 10:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=oGSFq4wb0y7n/q4LpZFk7+hqdG6WdMkDb/BtvzEEIcA=; b=LZrKtuB5c/kaN4NXsgD+2JbOKkPpDxcx+uj8r1n2b/lI5NTr18zwdBc92rncLiLRzY Rd3rhhxiRO7ey1wdHo0Q== Received: by 10.100.17.30 with SMTP id 30mr1725374anq.79.1319045468264; Wed, 19 Oct 2011 10:31:08 -0700 (PDT) Received: by 10.100.17.30 with SMTP id 30mr1725368anq.79.1319045468117; Wed, 19 Oct 2011 10:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.14 with HTTP; Wed, 19 Oct 2011 10:30:47 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24A747@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C24A747@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Wed, 19 Oct 2011 10:30:47 -0700 Message-ID: To: Mike Jones 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] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:31:12 -0000 On Wed, Oct 19, 2011 at 10:26 AM, Mike Jones wrote: > Yes, it covers all the characters legal in URIs. =A0Per earlier discussio= n on the list, scopes are not restricted to being URIs, as existing practic= e includes scope elements that are not URIs such as "email" "profile", and = "openid". All those simple words are URIs. They are relative URIs (just the path), but URIs nonetheless. Marius > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Marius Scurtescu > Sent: Wednesday, October 19, 2011 10:24 AM > To: Julian Reschke > Cc: OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Prop= osed Resolutions > > Marius > > > > On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke w= rote: >> On 2011-10-18 17:38, Eran Hammer-Lahav wrote: >>> >>> Space is allowed inside a quoted string and is already not allowed >>> inside each scope string. >>> >>> EHL >>> ... >> >> a) yes. >> >> b) well: >> >> =A0 The value of the scope parameter is expressed as a list of space- >> =A0 delimited, case sensitive strings. =A0The strings are defined by the >> =A0 authorization server. =A0If the value contains multiple >> space-delimited >> =A0 strings, their order does not matter, and each string adds an >> =A0 additional access range to the requested scope. >> >> That certainly implies that you can't have a space inside a token, but >> it could be clearer. >> >> Optimally, state the character repertoire precisely: >> >> =A0scopetokenchar =3D =A0%x21 / %x23-5B / %x5D-7E >> =A0; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII >> >> ? > > Is this covering all characters allowed in a URI? Why not define scopes a= s a list of URIs? > >> >> Best regards, Julian >> _______________________________________________ >> 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 Wed Oct 19 10:38:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D7B11E80AA for ; Wed, 19 Oct 2011 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYfwhUOTdPuy for ; Wed, 19 Oct 2011 10:38:10 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id CB2B821F8AA8 for ; Wed, 19 Oct 2011 10:38:09 -0700 (PDT) Received: (qmail 8112 invoked from network); 19 Oct 2011 17:38:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Oct 2011 17:38:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 19 Oct 2011 10:37:52 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , Mike Jones Date: Wed, 19 Oct 2011 10:37:45 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AcyOhOb3g/TR3CRHRq2vcVSflBdr8wAANHtg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452631E8F4C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C24A747@TK5EX14MBXC283.redmond.corp.microsoft.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:38:11 -0000 I don't think defining them as URI's is helpful here. But the set must be i= nclusive of URI characters. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Wednesday, October 19, 2011 10:31 AM > To: Mike Jones > Cc: OAuth WG > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > Proposed Resolutions >=20 > On Wed, Oct 19, 2011 at 10:26 AM, Mike Jones > wrote: > > Yes, it covers all the characters legal in URIs. =A0Per earlier discuss= ion on the > list, scopes are not restricted to being URIs, as existing practice inclu= des > scope elements that are not URIs such as "email" "profile", and "openid". >=20 > All those simple words are URIs. They are relative URIs (just the path), = but > URIs nonetheless. >=20 > Marius >=20 > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Marius Scurtescu > > Sent: Wednesday, October 19, 2011 10:24 AM > > To: Julian Reschke > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > > Proposed Resolutions > > > > Marius > > > > > > > > On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke > wrote: > >> On 2011-10-18 17:38, Eran Hammer-Lahav wrote: > >>> > >>> Space is allowed inside a quoted string and is already not allowed > >>> inside each scope string. > >>> > >>> EHL > >>> ... > >> > >> a) yes. > >> > >> b) well: > >> > >> =A0 The value of the scope parameter is expressed as a list of space- > >> =A0 delimited, case sensitive strings. =A0The strings are defined by t= he > >> =A0 authorization server. =A0If the value contains multiple > >> space-delimited > >> =A0 strings, their order does not matter, and each string adds an > >> =A0 additional access range to the requested scope. > >> > >> That certainly implies that you can't have a space inside a token, > >> but it could be clearer. > >> > >> Optimally, state the character repertoire precisely: > >> > >> =A0scopetokenchar =3D =A0%x21 / %x23-5B / %x5D-7E > >> =A0; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII > >> > >> ? > > > > Is this covering all characters allowed in a URI? Why not define scopes= as a > list of URIs? > > > >> > >> Best regards, Julian > >> _______________________________________________ > >> 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 julian.reschke@gmx.de Wed Oct 19 11:01:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5821F8B39 for ; Wed, 19 Oct 2011 11:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwfmCRlenZay for ; Wed, 19 Oct 2011 11:01:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3DBC721F8B38 for ; Wed, 19 Oct 2011 11:01:05 -0700 (PDT) Received: (qmail invoked by alias); 19 Oct 2011 18:00:57 -0000 Received: from p5DCC3E45.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.62.69] by mail.gmx.net (mp069) with SMTP; 19 Oct 2011 20:00:57 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/xBLVozBLxiKrEn+7mf5ORjlUk1LhEMktJeXTLxN 0l5TMO0WnGno4R Message-ID: <4E9F1054.4040302@gmx.de> Date: Wed, 19 Oct 2011 20:00:52 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Marius Scurtescu References: <4E1F6AAD24975D4BA5B16804296739435C24A747@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:01:07 -0000 On 2011-10-19 19:30, Marius Scurtescu wrote: > On Wed, Oct 19, 2011 at 10:26 AM, Mike Jones > wrote: >> Yes, it covers all the characters legal in URIs. Per earlier discussion on the list, scopes are not restricted to being URIs, as existing practice includes scope elements that are not URIs such as "email" "profile", and "openid". > > All those simple words are URIs. They are relative URIs (just the > path), but URIs nonetheless. > ... Nope. -- they are URI references. Best regards, Julian From wmills@yahoo-inc.com Wed Oct 19 11:15:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5CF1F0C67 for ; Wed, 19 Oct 2011 11:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.273 X-Spam-Level: X-Spam-Status: No, score=-17.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQi-hBupoP7H for ; Wed, 19 Oct 2011 11:15:59 -0700 (PDT) Received: from nm38-vm5.bullet.mail.ne1.yahoo.com (nm38-vm5.bullet.mail.ne1.yahoo.com [98.138.229.149]) by ietfa.amsl.com (Postfix) with SMTP id C32951F0C49 for ; Wed, 19 Oct 2011 11:15:58 -0700 (PDT) Received: from [98.138.90.56] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 19 Oct 2011 18:15:58 -0000 Received: from [98.138.89.250] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 19 Oct 2011 18:15:58 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 19 Oct 2011 18:15:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 125966.14066.bm@omp1042.mail.ne1.yahoo.com Received: (qmail 78258 invoked by uid 60001); 19 Oct 2011 18:15:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1319048157; bh=Zjwyj0lTd440FUgxkGLFczmLqAw0bTnrkxjv5sgtuvg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RYcqUFduQSU+4X0cBAp7DBd0rkq1QjbRlbmVrwxi/HRa2EE19KqO202nikj/7HVZEOdGLiQzbby+NUVazMeddouBwwLxpGQl56HuAsta0pZm1yINJbY12fKFdGEvKLEu6Gp/kcjn/xj2v17lyk3ofjOh7CuoCtqEX/Hgg8vSV2g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CRRdTvtyEnGvenmysX0fFb8v7263W948oVTEnv5CX1mPe7RWD/KOaoTSIW9ifg52lOk9iWjTUaQIH4Nq1c4wqcAEonBXpyIq3SA/oDR31WZwD41jEYATBf1bG/OlWgFUAVH19VIEZSv4+BHH/4suXbuLqZRS1gLV2/ThMw1qy9E=; X-YMail-OSG: L2RoIDQVM1l7s2dt5enquRIl29cCPtEFqcEd27KX4BnQYt. 7dciS.4qkZ9vanfSyYXapK1I_B5aJbCc9VAQH5Fq9z5FynC0aNVQu4BvMLZ5 ivBOhDZz6VFxdtsBpjCtJ3bqRf3heBI6tIetnH9Ayrr75Lkr_btbCXJGzn6n AaHHgIbkm0k0BXrbCKEq17FYUiMZq9A6gzcQLRJCl5MAdK0QwKZgAZM5h37q .4S.eWJkCG9oR81cyOIG6S0ZG_wyJXJQcEfw1VuMjyhRsG0mdYqI.fabLdL9 4DsB.tysYIn9mJAoNWFaWpMUCaKaAUkOX1MZ.e6iUDhoVxGyPR28qHDGeLIn 8LjDxNxIkLBOp0VwIHnukj6S_BoE_85raukaik4lLpRNJ.mY69zQ5gqpRrsg Dz5A3xfupd6U2d9zfLZ6lxsVGgvjLxutyyw-- Received: from [209.131.62.113] by web31802.mail.mud.yahoo.com via HTTP; Wed, 19 Oct 2011 11:15:57 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9D8414.4030107@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B9314@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9DABDA.9060306@gmx.de> Message-ID: <1319048157.41134.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Wed, 19 Oct 2011 11:15:57 -0700 (PDT) From: William Mills To: Marius Scurtescu , Julian Reschke In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-969897623-1319048157=:41134" Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:16:00 -0000 --0-969897623-1319048157=:41134 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > Is this covering all characters allowed in a URI? Why =0A=0A> not defines= copes as a list of URIs?=0A=0AI'd rather not do this because people will pr= esume unless we add even more text to explain it that they need to have the= form scheme://host/path or some such.=A0 It's an opportunity to bloat scop= es far out of proportion to what is actually needed.=0A=0A=0A=0A___________= _____________________=0AFrom: Marius Scurtescu =0ATo= : Julian Reschke =0ACc: OAuth WG =0A= Sent: Wednesday, October 19, 2011 10:23 AM=0ASubject: Re: [OAUTH-WG] draft-= ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions=0A=0AMarius=0A= =0A=0A=0AOn Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke wrote:=0A> On 2011-10-18 17:38, Eran Hammer-Lahav wrote:=0A>>=0A>> Sp= ace is allowed inside a quoted string and is already not allowed inside=0A>= > each scope string.=0A>>=0A>> EHL=0A>> ...=0A>=0A> a) yes.=0A>=0A> b) well= :=0A>=0A> =A0 The value of the scope parameter is expressed as a list of sp= ace-=0A> =A0 delimited, case sensitive strings. =A0The strings are defined = by the=0A> =A0 authorization server. =A0If the value contains multiple spac= e-delimited=0A> =A0 strings, their order does not matter, and each string a= dds an=0A> =A0 additional access range to the requested scope.=0A>=0A> That= certainly implies that you can't have a space inside a token, but it=0A> c= ould be clearer.=0A>=0A> Optimally, state the character repertoire precisel= y:=0A>=0A> =A0scopetokenchar =3D =A0%x21 / %x23-5B / %x5D-7E=0A> =A0; HTTPb= is P1 qdtext except whitespace, restricted to US-ASCII=0A>=0A> ?=0A=0AIs th= is covering all characters allowed in a URI? Why not define=0Ascopes as a l= ist of URIs?=0A=0A>=0A> Best regards, Julian=0A> __________________________= _____________________=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https:/= /www.ietf.org/mailman/listinfo/oauth=0A>=0A________________________________= _______________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.or= g/mailman/listinfo/oauth --0-969897623-1319048157=:41134 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> Is this covering all characters allowed in a URI? Why
> not define scopes as a list of URIs?

= I'd rather not do this because people will presume unless we add even more = text to explain it that they need to have the form scheme://host/path or so= me such.  It's an opportunity to bloat scopes far out of proportion to= what is actually needed.

From: Marius Scurtescu <mscurtescu@google.c= om>
To: Julian Resch= ke <julian.reschke@gmx.de>
Cc:= OAuth WG <oauth@ietf.org>
Sent: Wednesday, October 19, 2011 10:23 AM
Subject: Re: [OAUTH-WG] draft-ietf= -oauth-v2-bearer-09: Open Issues & Proposed Resolutions

M= arius



On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2011-10-18 17:38, Eran= Hammer-Lahav wrote:
>>
>> Space is allowed inside a quot= ed string and is already not allowed inside
>> each scope string.<= br>>>
>> EHL
>> ...
>
> a) yes.
>=
> b) well:
>
>   The value of the scope parameter i= s expressed as a list of space-
>   delimited, case sensitive strings.  The strings are defined by the
>   authorization= server.  If the value contains multiple space-delimited
>  = ; strings, their order does not matter, and each string adds an
> &nb= sp; additional access range to the requested scope.
>
> That ce= rtainly implies that you can't have a space inside a token, but it
> = could be clearer.
>
> Optimally, state the character repertoire= precisely:
>
>  scopetokenchar =3D  %x21 / %x23-5B /= %x5D-7E
>  ; HTTPbis P1 qdtext except whitespace, restricted to= US-ASCII
>
> ?

Is this covering all characters allowed = in a URI? Why not define
scopes as a list of URIs?

>
> B= est regards, Julian
> _______________________________________________=
> OAuth mailing list
> OAuth@ietf.org
> htt= ps://www.ietf.org/mailman/listinfo/oauth
>
___________________= ____________________________
OAuth mailing list
OAuth@ietf.org
https:/= /www.ietf.org/mailman/listinfo/oauth


--0-969897623-1319048157=:41134-- From mscurtescu@google.com Wed Oct 19 11:24:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219FC1F0C49 for ; Wed, 19 Oct 2011 11:24:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26Jt7K31EGcr for ; Wed, 19 Oct 2011 11:24:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 53BF11F0C6F for ; Wed, 19 Oct 2011 11:24:18 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p9JIOH99029124 for ; Wed, 19 Oct 2011 11:24:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319048657; bh=5J/6GDYNXOPrIdOgxzNTLwosxaE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Cs9jWIohntOt9+zfGSfNAAORjLvw8fnnjf4darveV+5toB1ekJ7/+6kzBQUvmOIki CMVPqYcQnTNJR2ObfuCGw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=cwmjm6YEOfTpJCKvFpP/UnvhcI63v1nyTjTIfaCCf4+h+40bltfqjZCMJEC8bR8cN KDJXdNYF2mEXyKJhcSgaQ== Received: from ywm39 (ywm39.prod.google.com [10.192.13.39]) by hpaq1.eem.corp.google.com with ESMTP id p9JINeM2009206 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 19 Oct 2011 11:24:16 -0700 Received: by ywm39 with SMTP id 39so2989748ywm.1 for ; Wed, 19 Oct 2011 11:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=HTsOi5ENShEFIgM2XGBVnd8hyP18YSI49svwtZ8VHT4=; b=XFu0t4R5JYejg51dpdEoqDuDSN+ZzRDE3KGi75aIL9YI7dqKAFbu4kOYsixwpkOAJq tNkfi5TWmyhmbmW6KqmA== Received: by 10.100.240.2 with SMTP id n2mr1782473anh.101.1319048651369; Wed, 19 Oct 2011 11:24:11 -0700 (PDT) Received: by 10.100.240.2 with SMTP id n2mr1782465anh.101.1319048651193; Wed, 19 Oct 2011 11:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.14 with HTTP; Wed, 19 Oct 2011 11:23:51 -0700 (PDT) In-Reply-To: <1319048157.41134.YahooMailNeo@web31802.mail.mud.yahoo.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9D8414.4030107@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B9314@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9DABDA.9060306@gmx.de> <1319048157.41134.YahooMailNeo@web31802.mail.mud.yahoo.com> From: Marius Scurtescu Date: Wed, 19 Oct 2011 11:23:51 -0700 Message-ID: To: William Mills 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] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:24:19 -0000 On Wed, Oct 19, 2011 at 11:15 AM, William Mills wrot= e: >> Is this covering all characters allowed in a URI? Why >> not define scopes as a list of URIs? > I'd rather not do this because people will presume unless we add even mor= e > text to explain it that they need to have the form scheme://host/path or > some such. Which is not necessarily a bad thing. It allows systems to scale and interoperate. > It's an opportunity to bloat scopes far out of proportion to > what is actually needed. > > ________________________________ > From: Marius Scurtescu > To: Julian Reschke > Cc: OAuth WG > Sent: Wednesday, October 19, 2011 10:23 AM > Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & > Proposed Resolutions > > Marius > > > > On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke > wrote: >> On 2011-10-18 17:38, Eran Hammer-Lahav wrote: >>> >>> Space is allowed inside a quoted string and is already not allowed insi= de >>> each scope string. >>> >>> EHL >>> ... >> >> a) yes. >> >> b) well: >> >> =A0 The value of the scope parameter is expressed as a list of space- >> =A0 delimited, case sensitive strings. =A0The strings are defined by the >> =A0 authorization server. =A0If the value contains multiple space-delimi= ted >> =A0 strings, their order does not matter, and each string adds an >> =A0 additional access range to the requested scope. >> >> That certainly implies that you can't have a space inside a token, but i= t >> could be clearer. >> >> Optimally, state the character repertoire precisely: >> >> =A0scopetokenchar =3D =A0%x21 / %x23-5B / %x5D-7E >> =A0; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII >> >> ? > > Is this covering all characters allowed in a URI? Why not define > scopes as a list of URIs? > >> >> Best regards, Julian >> _______________________________________________ >> 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 Wed Oct 19 11:52:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0970C21F8B7F for ; Wed, 19 Oct 2011 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.338 X-Spam-Level: X-Spam-Status: No, score=-17.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj68NeBJ0b2H for ; Wed, 19 Oct 2011 11:52:30 -0700 (PDT) Received: from nm37-vm7.bullet.mail.bf1.yahoo.com (nm37-vm7.bullet.mail.bf1.yahoo.com [72.30.238.207]) by ietfa.amsl.com (Postfix) with SMTP id 5F5FE21F8B77 for ; Wed, 19 Oct 2011 11:52:29 -0700 (PDT) Received: from [98.139.215.140] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 19 Oct 2011 18:52:24 -0000 Received: from [98.139.212.246] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 19 Oct 2011 18:52:24 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 19 Oct 2011 18:52:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 930318.91955.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 59527 invoked by uid 60001); 19 Oct 2011 18:52:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1319050344; bh=/J5Td8TlUP9yH5FdIIy32jrThwAim3UaaW1X/wl2s5w=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BC9mifRYs29X0wubAlTjEnYn70Dl2RZ4QEWcrGmjMiw3Ait2VX4Dy+SXZeqBb3LdbVVuXDcQ1nwznWaXGUltyOmRp4xV5CuI3eToOcrWDhAhWHgXxQLS03Xpw9vMYjDdtJhOj3WRWpuWE2AwRAfZ06DI6O8ImhJR3Nw/hfRUVaQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IV94bIJynexK/CPHc2ZGBj8ZcWllUbTasiCUjdHy5fL2UUFRWZ+j8Ol/s4qKk+yIKgLgIv6mPt3k3wxnVqJeeLGm2V9SaFyP34PYWQ5PfDAi+sSzdrlJbf2ZtB5TCQf/ofjtAENqBwxx6lSJRri4qGQBPGzaPohQnwLpJZxFUh4=; X-YMail-OSG: KR_qmxEVM1kksZ6wGUzphJB.u1PL0SPBoRZHXvNRvFa2xzw klj3mG6rWMP8etz25Tp6yWBwj12ZYOcBJ6PC85S5LjxV8seHugpv8jzo3EZZ KbLG24c.WpZJdIdnwePa9QQz6_6y96IqzP6RMFhITxeEiyPAF8yd06m.NMF7 FWYWmXk7DttzaAz_O72Vz_V5lGI51ctSUJvfkFCE8zagRpv2JNuGj8f4Devk iUeRl_5tQtkrcKpHIKjbigvQSoPFYKjNX36z_kfYazpG9_c3Gdbba2TzVBo3 YjPyG8WWypgj2L3V60xBWVzjprJcIeZ8CUH_XPF1vTxtOfVAUOXB9ZGzV6F8 g_0O3jrPFwpq8Xcfxbyiu2KPMJP6gfqTnuMmJLVULlV3GeKh3RrMdPoaMKJM IQZT0CKm6DWBMYsUshFymGEiG5BaomEGlUQ-- Received: from [209.131.62.113] by web31806.mail.mud.yahoo.com via HTTP; Wed, 19 Oct 2011 11:52:24 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9D8414.4030107@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B9314@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E9DABDA.9060306@gmx.de> <1319048157.41134.YahooMailNeo@web31802.mail.mud.yahoo.com> Message-ID: <1319050344.13534.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 19 Oct 2011 11:52:24 -0700 (PDT) From: William Mills To: Marius Scurtescu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1811930852-1319050344=:13534" Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:52:33 -0000 --0-1811930852-1319050344=:13534 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm not saying we should not make URIs valid scopes.=A0 I'm saying that I t= hink it's confusing and unnecessary to state that scopes are URIs.=A0 I'd b= e much happier if we say "The definition of scope allows URIs to be used if= needed." or some such.=0A=0A=0A=0A________________________________=0AFrom:= Marius Scurtescu =0ATo: William Mills =0ACc: Julian Reschke ; OAuth WG =0ASent: Wednesday, October 19, 2011 11:23 AM=0ASubject: Re: [OAUTH-W= G] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions=0A=0AO= n Wed, Oct 19, 2011 at 11:15 AM, William Mills wrote= :=0A>> Is this covering all characters allowed in a URI? Why=0A>> not defin= e scopes as a list of URIs?=0A> I'd rather not do this because people will = presume unless we add even more=0A> text to explain it that they need to ha= ve the form scheme://host/path or=0A> some such.=0A=0AWhich is not necessar= ily a bad thing. It allows systems to scale and=0Ainteroperate.=0A=0A> It's= an opportunity to bloat scopes far out of proportion to=0A> what is actual= ly needed.=0A>=0A> ________________________________=0A> From: Marius Scurte= scu =0A> To: Julian Reschke = =0A> Cc: OAuth WG =0A> Sent: Wednesday, October 19, 2011 10= :23 AM=0A> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issu= es &=0A> Proposed Resolutions=0A>=0A> Marius=0A>=0A>=0A>=0A> On Tue, Oct 18= , 2011 at 9:39 AM, Julian Reschke =0A> wrote:=0A>> O= n 2011-10-18 17:38, Eran Hammer-Lahav wrote:=0A>>>=0A>>> Space is allowed i= nside a quoted string and is already not allowed inside=0A>>> each scope st= ring.=0A>>>=0A>>> EHL=0A>>> ...=0A>>=0A>> a) yes.=0A>>=0A>> b) well:=0A>>= =0A>> =A0 The value of the scope parameter is expressed as a list of space-= =0A>> =A0 delimited, case sensitive strings. =A0The strings are defined by = the=0A>> =A0 authorization server. =A0If the value contains multiple space-= delimited=0A>> =A0 strings, their order does not matter, and each string ad= ds an=0A>> =A0 additional access range to the requested scope.=0A>>=0A>> Th= at certainly implies that you can't have a space inside a token, but it=0A>= > could be clearer.=0A>>=0A>> Optimally, state the character repertoire pre= cisely:=0A>>=0A>> =A0scopetokenchar =3D =A0%x21 / %x23-5B / %x5D-7E=0A>> = =A0; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII=0A>>=0A>> = ?=0A>=0A> Is this covering all characters allowed in a URI? Why not define= =0A> scopes as a list of URIs?=0A>=0A>>=0A>> Best regards, Julian=0A>> ____= ___________________________________________=0A>> OAuth mailing list=0A>> OA= uth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A>>=0A> ____= ___________________________________________=0A> OAuth mailing list=0A> OAut= h@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> --0-1811930852-1319050344=:13534 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not saying we should not make URIs valid scopes.  I'm saying tha= t I think it's confusing and unnecessary to state that scopes are URIs.&nbs= p; I'd be much happier if we say "The definition of scope allows URIs to be= used if needed." or some such.

<= span style=3D"font-weight:bold;">From: Marius Scurtescu <mscu= rtescu@google.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Julian Reschke <julian.reschke@gmx.de>; OA= uth WG <oauth@ietf.org>
Sent: Wednesday, October 19, 2011 11:23 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09:= Open Issues & Proposed Resolutions

On Wed, Oct 19, 2011 = at 11:15 AM, William Mills <wmills@yahoo-inc.com> wrote:
= >> Is this covering all characters allowed in a URI? Why
>> = not define scopes as a list of URIs?
> I'd rather not do this because= people will presume unless we add even more
> text to explain it tha= t they need to have the form scheme://host/path or
> some such.
Which is not necessarily a bad thing. It allows systems to scale and
i= nteroperate.

> It's an opportunity to bloat scopes far out of pro= portion to
> what is actually needed.
>
> ________________________________
> From: Marius Scurtescu <mscurtescu@google.com>
> To: Julian Reschke <julian= .reschke@gmx.de>
> Cc: OAuth WG <oauth@ietf.org>
> Se= nt: Wednesday, October 19, 2011 10:23 AM
> Subject: Re: [OAUTH-WG] dr= aft-ietf-oauth-v2-bearer-09: Open Issues &
> Proposed Resolutions=
>
> Marius
>
>
>
> On Tue, Oct 18, 201= 1 at 9:39 AM, Julian Reschke <julian.reschke@gmx.de>
&g= t; wrote:
>> On 2011-10-18 17:38, Eran Hammer-Lahav wrote:
>= >>
>>> Space is allowed inside a quoted string and is alr= eady not allowed inside
>>> each scope string.
>>>
>&= gt;> EHL
>>> ...
>>
>> a) yes.
>>=
>> b) well:
>>
>>   The value of the scope= parameter is expressed as a list of space-
>>   delimited, c= ase sensitive strings.  The strings are defined by the
>> &nb= sp; authorization server.  If the value contains multiple space-delimi= ted
>>   strings, their order does not matter, and each strin= g adds an
>>   additional access range to the requested scope= .
>>
>> That certainly implies that you can't have a spac= e inside a token, but it
>> could be clearer.
>>
>&= gt; Optimally, state the character repertoire precisely:
>>
>= ;>  scopetokenchar =3D  %x21 / %x23-5B / %x5D-7E
>> &= nbsp;; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII
>>
>> ?
>
> Is this covering all ch= aracters allowed in a URI? Why not define
> scopes as a list of URIs?=
>
>>
>> Best regards, Julian
>> _________= ______________________________________
>> OAuth mailing list
&g= t;> = OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
&= gt; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mail= man/listinfo/oauth
>
>
>


--0-1811930852-1319050344=:13534-- From bcampbell@pingidentity.com Wed Oct 19 14:58:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D42F21F8B30 for ; Wed, 19 Oct 2011 14:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVfwClBdCXSd for ; Wed, 19 Oct 2011 14:58:55 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id BEE9E21F8B2A for ; Wed, 19 Oct 2011 14:58:54 -0700 (PDT) Received: from mail-yx0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP; Wed, 19 Oct 2011 14:58:54 PDT Received: by mail-yx0-f176.google.com with SMTP id 30so2581727yxk.7 for ; Wed, 19 Oct 2011 14:58:53 -0700 (PDT) Received: by 10.147.116.9 with SMTP id t9mr1910678yam.5.1319061533118; Wed, 19 Oct 2011 14:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.125.6 with HTTP; Wed, 19 Oct 2011 14:58:23 -0700 (PDT) From: Brian Campbell Date: Wed, 19 Oct 2011 15:58:23 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba Subject: [OAUTH-WG] Status and next steps on Assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:58:55 -0000 A few of us had a chance to meet face to face this morning at IIW 13 in Mountain View and talked a bit about the assertions document. I wanted to try and (very quickly) summarize that and also talk about the some next steps for these documents. This is partly a summary and partly a reminder of things to be done. The "OAuth 2.0 Assertion Profile" http://tools.ietf.org/html/draft-ietf-oauth-assertions-00 Hannes and Barry expressed concern about some of the wording (and possibly the SAML one as well?) saying that it could potentially be misleading or confusing regarding the actual security properties implied or provided by the profile. Hannes was going to take a crack at proposing some new text. This draft is due for an update and there have been some comments on it over the last few months. I found http://www.ietf.org/mail-archive/web/oauth/current/msg07186.html which are some general comments from Yaron and http://www.ietf.org/mail-archive/web/oauth/current/msg07173.html which is from me about the need to do parameter registration in this doc. I thought there were some additional comments but I can't seem to find them. Personally, given the treatment of client_id in draft-ietf-oauth-v2-22, I think that this draft needs to rework its handling of client_id. It should probably just be omitted completely from section 4.2. "Using Assertions as Authorization Grants" and made optional or even forbidden in section 4.1. "Using Assertions for Client Authentication" "An IETF URN Sub-Namespace for OAuth" http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-00 I think this short document is ready to go on to whatever is next. "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0" http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-08 I believe this document is also ready to go. Although it depends on the previous two documents so they should probably progress together as a group. The only comment I'm aware of on it came from a cross posting at the OASIS SSTC and while I acknowledge what was said, I don't believe it can be addressed. I can provide more detail, if anyone is interested. Hannes said he thought there might be some editorial issues with it or perhaps it contained incorrect URI(s). He wasn't sure if he was working against the latest draft, however, so is planning on double checking and providing comments if appropriate. "JSON Web Token (JWT) Bearer Profile for OAuth 2.0" http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 Mike is going to update this draft to be an instance of draft-ietf-oauth-assertions-00 similar to what draft-ietf-oauth-saml2-bearer-08 does. From internet-drafts@ietf.org Wed Oct 19 15:46:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D57B11E80BB; Wed, 19 Oct 2011 15:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hvcrcw67sDH; Wed, 19 Oct 2011 15:46:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291BC11E808A; Wed, 19 Oct 2011 15:46:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111019224658.19672.37933.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2011 15:46:58 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:46:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-10.txt Pages : 18 Date : 2011-10-19 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get ac= cess to granted resources (without demonstrating possession of a cryptographic key). To prevent misuse, the bearer token MUST be protected from disclosure in storage and in transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-10.txt From jricher@mitre.org Wed Oct 19 16:14:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C37421F8B47 for ; Wed, 19 Oct 2011 16:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J15HxAquuR11 for ; Wed, 19 Oct 2011 16:14:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F34E621F8A69 for ; Wed, 19 Oct 2011 16:13:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3E58921B0997 for ; Wed, 19 Oct 2011 19:13:59 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 393A421B02A4 for ; Wed, 19 Oct 2011 19:13:59 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.101]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Wed, 19 Oct 2011 19:13:58 -0400 From: "Richer, Justin P." To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-10.txt Thread-Index: AQHMjrEECk3lmFAtlkyM2VxvCEkh9pWESopc Date: Wed, 19 Oct 2011 23:13:57 +0000 Message-ID: References: <20111019224658.19672.37933.idtracker@ietfa.amsl.com> In-Reply-To: <20111019224658.19672.37933.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:14:01 -0000 Minor typo: missing period at the end of the paragraph of section 2.=0A= =0A= -- Justin=0A= =0A= ________________________________________=0A= From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of internet= -drafts@ietf.org [internet-drafts@ietf.org]=0A= Sent: Wednesday, October 19, 2011 6:46 PM=0A= To: i-d-announce@ietf.org=0A= Cc: oauth@ietf.org=0A= Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-10.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF.=0A= =0A= Title : The OAuth 2.0 Authorization Protocol: Bearer Toke= ns=0A= Author(s) : Michael B. Jones=0A= Dick Hardt=0A= David Recordon=0A= Filename : draft-ietf-oauth-v2-bearer-10.txt=0A= Pages : 18=0A= Date : 2011-10-19=0A= =0A= This specification describes how to use bearer tokens in HTTP=0A= requests to access OAuth 2.0 protected resources. Any party in=0A= possession of a bearer token (a "bearer") can use it to get ac= cess to=0A= granted resources (without demonstrating possession of a=0A= cryptographic key). To prevent misuse, the bearer token MUST be=0A= protected from disclosure in storage and in transport.=0A= =0A= =0A= A URL for this Internet-Draft is:=0A= http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-10.txt=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= This Internet-Draft can be retrieved at:=0A= ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-10.txt=0A= _______________________________________________=0A= OAuth mailing list=0A= OAuth@ietf.org=0A= https://www.ietf.org/mailman/listinfo/oauth=0A= From Michael.Jones@microsoft.com Wed Oct 19 16:38:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C25111E8098 for ; Wed, 19 Oct 2011 16:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.955 X-Spam-Level: X-Spam-Status: No, score=-9.955 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgNAJ3Cm7Svm for ; Wed, 19 Oct 2011 16:38:03 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0A75A11E808A for ; Wed, 19 Oct 2011 16:38:03 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Oct 2011 16:38:02 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 16:38:02 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -10 Thread-Index: AcyOuBvrce+R9JZJS5GdKjqOZuv3Gw== Date: Wed, 19 Oct 2011 23:38:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C24B1CATK5EX14MBXC283r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:38:04 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C24B1CATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 10 o= f the OAuth 2.0 Bearer Token Specification has been published, which incorporates consen= sus decisions reached since Working Group Last Call feedback. It closes al= l open issues. It contains the following changes: * Removed the #auth-param option from Authorization header syntax (l= eaving only the b64token syntax). * Restricted the scope value character set to %x21 / %x23-5B / %x5D-= 7E (printable ASCII characters excluding double-quote and backslash). Indic= ated that scope is intended for programmatic use and is not meant to be dis= played to end users. * Restricted the character set for error_description strings to SP /= VCHAR and indicated that they are not meant to be displayed to end users. * Included more description in the Abstract, since Hannes Tschofenig= indicated that the RFC editor would require this. * Changed "Access Grant" to "Authorization Grant", as was done in th= e core spec. * Simplified the introduction to the Authenticated Requests section. The draft is available at these locations: * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-10 * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-10.= pdf * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-10.= txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-10.= xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-10.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-10.pdf * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-10.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-10.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will= point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will = point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will = point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will = point to new versions as they are posted) * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion = repository, with html, pdf, txt, and html versions available) -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435C24B1CATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 10 of the OA= uth 2.0 Bearer Token Specification has been published, which incorporat= es consensus decisions reached since Working Group Last Call feedback. = ; It closes all open issues.  It contains the following changes:

·    &= nbsp;   Removed= the #auth-param option from Authorization header syntax (leaving only the = b64token syntax).

·    &= nbsp;   Restric= ted the scope value character set to %x21 / %x23-5B / %x5D-7E (printable ASCII characte= rs excluding double-quote and backslash). Indicated that scope is intended fo= r programmatic use and is not meant to be displayed to end users.

·    &= nbsp;   Restric= ted the character set for error_description strings to SP / VCHAR and indicated that they are not meant to be displayed to end users.

·    &= nbsp;   Include= d more description in the Abstract, since Hannes Tschofenig indicated that = the RFC editor would require this.

·    &= nbsp;   Changed= "Access Grant" to "Authorization Grant", as was done i= n the core spec.

·    &= nbsp;   Simplif= ied the introduction to the Authenticated Requests section.

 

The draft is available at these locations:

·        http://tools.ietf.org/html/draft-ietf-oauth-= v2-bearer-10

·        http://www.ietf.org/internet-drafts/draft-ie= tf-oauth-v2-bearer-10.pdf

·        http://www.ietf.org/internet-drafts/draft-ie= tf-oauth-v2-bearer-10.txt

·        http://www.ietf.org/internet-drafts/draft-ie= tf-oauth-v2-bearer-10.xml

·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-10.html

·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-10.pdf

·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-10.txt

·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-10.xml

·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer.html (will point to new versions as they are posted)=

·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer.pdf (will point to new versions as they are posted)<= /p>

·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer.txt (will point to new versions as they are posted)<= /p>

·        http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer.xml (will point to new versions as they are posted)<= /p>

·        http://svn.openid.net/repos/specifications/o= auth/2.0/ (Subversion repository, with html, pdf, txt, and html versions av= ailable)

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435C24B1CATK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Wed Oct 19 16:57:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB011E80AF for ; Wed, 19 Oct 2011 16:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.984 X-Spam-Level: X-Spam-Status: No, score=-9.984 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCmKCxyUnsa1 for ; Wed, 19 Oct 2011 16:57:52 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B521C11E8095 for ; Wed, 19 Oct 2011 16:57:52 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Oct 2011 16:57:52 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 16:57:51 -0700 From: Mike Jones To: Justin Richer , "Anganes, Amanda L" Thread-Topic: [OAUTH-WG] Bearer Token Last Call Comments Thread-Index: AcyOuuIGob2s/4J+RN6XsYxNdEm67w== Date: Wed, 19 Oct 2011 23:57:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24B250@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C24B250TK5EX14MBXC283r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer Token Last Call Comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:57:53 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C24B250TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgdXNlZnVsIGZlZWRiYWNrLCBKdXN0aW4gYW5kIEFtYW5kYS4gIEFjdGlv bnMgdGFrZW4gaW4gcmVzcG9uc2UgaW4gZHJhZnQgMTAgYXJlIGRlc2NyaWJlZCBpbmxpbmUuDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnXTxtYWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVo YWxmIE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IEZyaWRheSwgQXVndXN0IDEyLCAyMDExIDExOjMy IEFNDQpUbzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KQ2M6IEFuZ2Fu ZXMsIEFtYW5kYSBMDQpTdWJqZWN0OiBbT0FVVEgtV0ddIEJlYXJlciBUb2tlbiBMYXN0IENhbGwg Q29tbWVudHMNCg0KDQoNCjEuMzogVGhpcyBkcmFmdCBzdGlsbCB1c2VzIHRoZSB0ZXJtICJhY2Nl c3MgZ3JhbnQiIHdoZXJlIHRoZSBjb3JlIG5vdyB1c2VzICJhdXRob3JpemF0aW9uIGdyYW50Ii4g Q2hhbmdlIGFsbCByZWZlcmVuY2VzIHRvICJhdXRob3JpemF0aW9uIGdyYW50IiBhbmQgcmVmZXJl bmNlIHNlY3Rpb24gMS40IGluIGNvcmUuIEFsc28sIHRvbyBtYW55IHBhcmVudGhldGljYWwgc3Rh dGVtZW50cyBpbiBvcGVuaW5nIHBhcmFncmFwaCAtLSBzdWdnZXN0ZWQgcmV3cml0ZSBvZiB0aGlz IGJpdDoNCg0KICAgICAgICAgICAgICAgQmVmb3JlIGEgY2xpZW50IGNhbiBhY2Nlc3MgYSBwcm90 ZWN0ZWQgcmVzb3VyY2UsIGl0IG11c3QgZmlyc3QNCg0KICAgICAgICAgICAgICAgb2J0YWluIGFu IGF1dGhvcml6YXRpb24gZ3JhbnQgW1tsaW5rIHRvIGNvcmUgUy4xLjRdXSBmcm9tIHRoZQ0KDQog ICAgICAgICAgICAgICByZXNvdXJjZSBvd25lciwgYW5kIHRoZW4gZXhjaGFuZ2UgdGhlIGF1dGhv cml6YXRpb24gZ3JhbnQgZm9yDQoNCiAgICAgICAgICAgICAgIGFuIGFjY2VzcyB0b2tlbi4gVGhl IGFjY2VzcyB0b2tlbiB0aGVuIHJlcHJlc2VudHMgdGhlIHNjb3BlLA0KDQogICAgICAgICAgICAg ICBkdXJhdGlvbiwgYW5kIG90aGVyIGFjY2VzcyBhdHRyaWJ1dGVzIGdyYW50ZWQgYnkgdGhlDQoN CiAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZ3JhbnQuDQoNCkRvbmUNCg0KDQoyOiAiLi4u U0hPVUxEIE5PVCBiZSB1c2VkIHVubGVzcyBubyBvdGhlci4uLiIgaXMgYSB0cmlwbGUgbmVnYXRp dmUgYW5kIHdoaWxlIHRlY2huaWNhbGx5IGNvcnJlY3QgaXQgaXMgYSBiaXQgaGVhZC1zcGlubnkg dG8gcmVhZC4gU3VnZ2VzdGVkDQoNCnJld3JpdGU6ICJEdWUgdG8gdGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIChTLjMpIGFzc29jaWF0ZWQgd2l0aCB0aGUgVVJJIG1ldGhvZCwgdGhpcyBtZXRo b2QgU0hPVUxEIE5PVCBiZSB1c2VkIHVubGVzcyBpdCBpcyB0aGUgb25seSBmZWFzaWJsZSBtZXRo b2QuIg0KDQpEb25lDQoNCg0KMi4xLzIuMi8yLjM6IEludHJvZHVjdG9yeSB0ZXh0IGlzIG5vbi1w YXJhbGxlbC4gU3VnZ2VzdCBjaGFuZ2luZyBpbnRybyB0byAyLjEgdG8gcGFyYWxsZWwgMi4yIGFu ZCAyLjMsIHdpdGggYSAiV2hlbiBpbmNsdWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBpbiB0aGUgQXV0 aG9yaXphdGlvbiBoZWFkZXIsIHRoZSBjbGllbnQgLi4uIiBjb25zdHJ1Y3QuDQoNCkRvbmUNCg0K DQoyLjI6ICJ1bmxlc3MgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIGFyZSBtZXQiIGlzIGFtYmln dW91cy4gQWxsIGNvbmRpdGlvbnMgYXJlIG1ldD8gQXQgbGVhc3Qgb25lPw0KDQpOb3cgcmVhZHMg 4oCcdW5sZXNzIGFsbCBvZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIG1ldOKAnS4NCg0K DQoyLjM6IEFyZSB0aGVyZSBjb25kaXRpb25zIGZvciB0aGlzIHVzZSBhcyB3ZWxsLCB0byBtYXRj aCAyLjI/DQoNCkp1c3QgdGhlIHN0YXRlbWVudCBhYm91dCDigJxTSE9VTEQgTk9UIGJlIHVzZWQg dW5sZXNzIGl0IGlzIHRoZSBvbmx5IGZlYXNpYmxlIG1ldGhvZOKAnS4NCg0KDQoyLjIvMi4zOiBB ZGQgbm9ybWF0aXZlIGxhbmd1YWdlIHRvOiAiVGhlIGVudGl0eS1ib2R5IE1BWSBpbmNsdWRlIG90 aGVyIHJlcXVlc3Qgc3BlY2lmaWMgcGFyYW1ldGVycy4gSW4gd2hpY2ggY2FzZS4uLiIgKHNpbWls YXIgaW4gMi4zJ3MgcmVxdWVzdA0KDQpVUkkpDQoNCkRvbmUNCg0KDQpNaWdodCBiZSB1c2VmdWwg dG8gaGF2ZSB0aGUgZXhhbXBsZSBzaG93IGFuIGFkZGl0aW9uYWwgcGFyYW1ldGVyLg0KDQpOb3Qg ZG9uZSwgYXMgdGhlIGFkZGl0aW9uYWwgcGFyYW1ldGVyIGNvdWxkIGFsc28gY29uZnVzZSBkZXZl bG9wZXJzIHJlYWRpbmcgdGhlIHNwZWNpZmljYXRpb24uDQoNCg0KMi40OiBTaG91bGQgdGhpcyBi ZSBhIHRvcC1sZXZlbCBzZWN0aW9uPyBTaW5jZSBpdCdzIGRlYWxpbmcgd2l0aCB0aGUgZnJvbS10 aGUtc2VydmVyIGJpdCBpbnN0ZWFkIG9mIHRoZSB0by10aGUtc2VydmVyIGJpdCB0aGF0IHRoZSBy ZXN0IG9mIDIuDQoNCmlzIGRlYWxpbmcgd2l0aC4NCg0KRG9uZQ0KDQoNCjMuMTogTWlzc2luZyB3 b3JkOiAiVG9rZW4gcmVkaXJlY3Q6ICBBbiBhdHRhY2tlciB1c2VzIHRoZSB0b2tlbiBnZW5lcmF0 ZWQgZm9yIGNvbnN1bXB0aW9uIGJ5IFtvbmVdIHJlc291cmNlIHNlcnZlciB0byBvYnRhaW4gYWNj ZXNzIHRvIGFub3RoZXIgcmVzb3VyY2Ugc2VydmVyLiINCg0KRG9uZQ0KDQoNCjM6IFRoZXJlJ3Mg YSBtaXggb2Ygbm9ybWF0aXZlIGFuZCBub24tbm9ybWF0aXZlIGxhbmd1YWdlIHRocm91Z2hvdXQg dGhpcyBzZWN0aW9uLCBhcyB3ZWxsIGFzIGEgbWl4IG9mIGltcGVyYXRpdmUgYW5kIGRlc2NyaXB0 aXZlIGxhbmd1YWdlLiBXZSBzdWdnZXN0IG1ha2luZyB0aGUgd2hvbGUgc2VjdGlvbiBub3JtYXRp dmUgYW5kIGltcGVyYXRpdmUgdG8gYmUgY29uc2lzdGVudC4gUGFydGljdWxhciBpbnN0YW5jZXM6 DQoNCg0KDQogIDMuMjogInRoZSBsaWZldGltZSBvZiB0aGUgdG9rZW4gTVVTVCBiZSBsaW1pdGVk 4oCdDQoNCkRvbmUNCg0KDQogIDMuMzogdmFsaWRhdGUgU1NMIGNlcnRpZmljYXRlIGNoYWluczog IlRoZSBjbGllbnQgTVVTVC4uLiINCg0KRG9uZQ0KDQoNCiAgMy4zOiBpc3N1ZSBzaG9ydCBsaXZl ZCBiZWFyZXIgdG9rZW5zOiBDaGFuZ2UgdG8gc29tZXRoaW5nIGxpa2UgIlRva2VuDQoNCiAgICAg ICAgICAgICAgIHNlcnZlcnMgU0hPVUxEIGlzc3VlIHNob3J0LWxpdmVkIChvbmUgaG91ciBvciBs ZXNzKSBiZWFyZXINCg0KICAgICAgICAgICAgICAgdG9rZW5zLCBwYXJ0aWN1bGFybHkgd2hlbiBp c3N1aW5nIHRva2VucyB0byBjbGllbnRzIHRoYXQgcnVuDQoNCiAgICAgICAgICAgICAgIHdpdGhp biBhIHdlYiBicm93c2VyIG9yIG90aGVyIGVudmlyb25tZW50cyB3aGVyZSBpbmZvcm1hdGlvbg0K DQogICAgICAgICAgICAgICBsZWFrYWdlIG1heSBvY2N1ci4gVXNpbmcgc2hvcnQtbGl2ZWQgYmVh cmVyIHRva2VucyBjYW4gcmVkdWNlDQoNCiAgICAgICAgICAgICAgIHRoZSBpbXBhY3Qgb2Ygb25l IG9mIHRoZW0gYmVpbmcgbGVha2VkLiINCg0KRG9uZQ0KDQoNCiAgMy4zOiBzY29wZWQgYmVhcmVy IHRva2VuczogIlRva2VuIHNlcnZlcnMgU0hPVUxEIGlzc3VlIGJlYXJlciB0b2tlbnMNCg0KICAg ICAgICAgICAgICAgdGhhdCBjb250YWluIGFuIGF1ZGllbmNlIHJlc3RyaWN0aW9uLi4uIg0KDQpE b25lDQoNCg0KICAzLjM6IGRvbid0IHBhc3M6ICJCZWFyZXIgdG9rZW5zIFNIT1VMRCBOT1QgYmUg cGFzc2VkIGluIHBhZ2UgVVJMcw0KDQogICAgICAgICAgICAgICAoZm9yIGV4YW1wbGUgYXMgcXVl cnkgc3RyaW5nIHBhcmFtZXRlcnMpLiBJbnN0ZWFkLCBiZWFyZXINCg0KICAgICAgICAgICAgICAg dG9rZW5zIFNIT1VMRCBiZSBwYXNzZWQgaW4gSFRUUCBtZXNzYWdlIGhlYWRlcnMgb3IgbWVzc2Fn ZQ0KDQogICAgICAgICAgICAgICBib2RpZXMgZm9yIHdoaWNoIGNvbmZpZGVudGlhbGl0eSBtZWFz dXJlcyBhcmUgdGFrZW4uIEJyb3dzZXJzLA0KDQogICAgICAgICAgICAgICB3ZWIgc2VydmVycywg YW5kIG90aGVyIHNvZnR3YXJlIG1heSBub3QgYWRlcXVhdGVseSBzZWN1cmUgVVJMcw0KDQogICAg ICAgICAgICAgICBpbiB0aGUgYnJvd3NlciBoaXN0b3J5LCB3ZWIgc2VydmVyIGxvZ3MsIGFuZCBv dGhlciBkYXRhDQoNCiAgICAgICAgICAgICAgIHN0cnVjdHVyZXMuIElmIGJlYXJlciB0b2tlbnMg YXJlIHBhc3NlZCBpbiBwYWdlIFVSTHMsIGF0dGFja2Vycw0KDQogICAgICAgICAgICAgICBtaWdo dCBiZSBhYmxlIHRvIHN0ZWFsIHRoZW0gZnJvbSB0aGUgaGlzdG9yeSBkYXRhLCBsb2dzLCBvcg0K DQogICAgICAgICAgICAgICBvdGhlciB1bnNlY3VyZWQgbG9jYXRpb25zLiINCg0KRG9uZQ0KDQoN Ci0tIEp1c3RpbiBSaWNoZXINCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739435C24B250TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRoZSB1c2Vm dWwgZmVlZGJhY2ssIEp1c3RpbiBhbmQgQW1hbmRhLiZuYnNwOyBBY3Rpb25zIHRha2VuIGluIHJl c3BvbnNlIGluIGRyYWZ0IDEwIGFyZSBkZXNjcmliZWQgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZ108L2E+IE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyPGJyPg0KU2VudDogRnJpZGF5LCBB dWd1c3QgMTIsIDIwMTEgMTE6MzIgQU08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQpDYzogQW5nYW5lcywgQW1hbmRhIEw8YnI+ DQpTdWJqZWN0OiBbT0FVVEgtV0ddIEJlYXJlciBUb2tlbiBMYXN0IENhbGwgQ29tbWVudHM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4xLjM6IFRoaXMgZHJhZnQgc3RpbGwgdXNlcyB0aGUgdGVybSAm cXVvdDthY2Nlc3MgZ3JhbnQmcXVvdDsgd2hlcmUgdGhlIGNvcmUgbm93IHVzZXMgJnF1b3Q7YXV0 aG9yaXphdGlvbiBncmFudCZxdW90Oy4gQ2hhbmdlIGFsbCByZWZlcmVuY2VzIHRvICZxdW90O2F1 dGhvcml6YXRpb24gZ3JhbnQmcXVvdDsgYW5kIHJlZmVyZW5jZSBzZWN0aW9uIDEuNCBpbiBjb3Jl LiBBbHNvLCB0b28gbWFueSBwYXJlbnRoZXRpY2FsDQogc3RhdGVtZW50cyBpbiBvcGVuaW5nIHBh cmFncmFwaCAtLSBzdWdnZXN0ZWQgcmV3cml0ZSBvZiB0aGlzIGJpdDogPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlZm9yZSBhIGNsaWVudCBjYW4gYWNjZXNzIGEgcHJvdGVj dGVkIHJlc291cmNlLCBpdCBtdXN0IGZpcnN0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgb2J0YWluIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgW1tsaW5rIHRvIGNvcmUgUy4x LjRdXSBmcm9tIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc291 cmNlIG93bmVyLCBhbmQgdGhlbiBleGNoYW5nZSB0aGUgYXV0aG9yaXphdGlvbiBncmFudCBmb3IN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbiBhY2Nlc3MgdG9rZW4uIFRo ZSBhY2Nlc3MgdG9rZW4gdGhlbiByZXByZXNlbnRzIHRoZSBzY29wZSwNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkdXJhdGlvbiwgYW5kIG90aGVyIGFjY2VzcyBhdHRyaWJ1 dGVzIGdyYW50ZWQgYnkgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YXV0aG9yaXphdGlvbiBncmFudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG9uZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MjogJnF1b3Q7Li4uU0hPVUxEIE5P VCBiZSB1c2VkIHVubGVzcyBubyBvdGhlci4uLiZxdW90OyBpcyBhIHRyaXBsZSBuZWdhdGl2ZSBh bmQgd2hpbGUgdGVjaG5pY2FsbHkgY29ycmVjdCBpdCBpcyBhIGJpdCBoZWFkLXNwaW5ueSB0byBy ZWFkLiBTdWdnZXN0ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5yZXdyaXRlOiAmcXVvdDtEdWUgdG8gdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIChTLjMpIGFzc29jaWF0ZWQgd2l0aCB0aGUgVVJJIG1ldGhvZCwgdGhp cyBtZXRob2QgU0hPVUxEIE5PVCBiZSB1c2VkIHVubGVzcyBpdCBpcyB0aGUgb25seSBmZWFzaWJs ZSBtZXRob2QuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRvbmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjIuMS8yLjIvMi4zOiBJbnRyb2R1Y3Rvcnkg dGV4dCBpcyBub24tcGFyYWxsZWwuIFN1Z2dlc3QgY2hhbmdpbmcgaW50cm8gdG8gMi4xIHRvIHBh cmFsbGVsIDIuMiBhbmQgMi4zLCB3aXRoIGEgJnF1b3Q7V2hlbiBpbmNsdWRpbmcgdGhlIGFjY2Vz cyB0b2tlbiBpbiB0aGUgQXV0aG9yaXphdGlvbiBoZWFkZXIsIHRoZSBjbGllbnQgLi4uJnF1b3Q7 IGNvbnN0cnVjdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG9uZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Mi4yOiAmcXVvdDt1bmxlc3MgdGhlIGZvbGxvd2lu ZyBjb25kaXRpb25zIGFyZSBtZXQmcXVvdDsgaXMgYW1iaWd1b3VzLiBBbGwgY29uZGl0aW9ucyBh cmUgbWV0PyBBdCBsZWFzdCBvbmU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk5vdyBy ZWFkcyDigJx1bmxlc3MgYWxsIG9mIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUgbWV04oCd LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Mi4zOiBBcmUgdGhlcmUgY29u ZGl0aW9ucyBmb3IgdGhpcyB1c2UgYXMgd2VsbCwgdG8gbWF0Y2ggMi4yPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5KdXN0IHRoZSBzdGF0ZW1lbnQgYWJvdXQg4oCcU0hPVUxEIE5PVCBi ZSB1c2VkIHVubGVzcyBpdCBpcyB0aGUgb25seSBmZWFzaWJsZSBtZXRob2TigJ0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4yLjIvMi4zOiBBZGQgbm9ybWF0aXZlIGxhbmd1 YWdlIHRvOiAmcXVvdDtUaGUgZW50aXR5LWJvZHkgTUFZIGluY2x1ZGUgb3RoZXIgcmVxdWVzdCBz cGVjaWZpYyBwYXJhbWV0ZXJzLiBJbiB3aGljaCBjYXNlLi4uJnF1b3Q7IChzaW1pbGFyIGluIDIu MydzIHJlcXVlc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5VUkkpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRv bmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk1pZ2h0IGJlIHVzZWZ1bCB0 byBoYXZlIHRoZSBleGFtcGxlIHNob3cgYW4gYWRkaXRpb25hbCBwYXJhbWV0ZXIuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk5vdCBkb25lLCBhcyB0aGUgYWRkaXRpb25hbCBwYXJhbWV0 ZXIgY291bGQgYWxzbyBjb25mdXNlIGRldmVsb3BlcnMgcmVhZGluZyB0aGUgc3BlY2lmaWNhdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjIuNDogU2hvdWxkIHRoaXMg YmUgYSB0b3AtbGV2ZWwgc2VjdGlvbj8gU2luY2UgaXQncyBkZWFsaW5nIHdpdGggdGhlIGZyb20t dGhlLXNlcnZlciBiaXQgaW5zdGVhZCBvZiB0aGUgdG8tdGhlLXNlcnZlciBiaXQgdGhhdCB0aGUg cmVzdCBvZiAyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPmlzIGRlYWxpbmcgd2l0aC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+RG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+My4xOiBN aXNzaW5nIHdvcmQ6ICZxdW90O1Rva2VuIHJlZGlyZWN0OiZuYnNwOyBBbiBhdHRhY2tlciB1c2Vz IHRoZSB0b2tlbiBnZW5lcmF0ZWQgZm9yIGNvbnN1bXB0aW9uIGJ5IFtvbmVdIHJlc291cmNlIHNl cnZlciB0byBvYnRhaW4gYWNjZXNzIHRvIGFub3RoZXIgcmVzb3VyY2Ugc2VydmVyLiZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Eb25lPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4zOiBUaGVyZSdzIGEgbWl4IG9mIG5vcm1hdGl2ZSBhbmQgbm9uLW5vcm1h dGl2ZSBsYW5ndWFnZSB0aHJvdWdob3V0IHRoaXMgc2VjdGlvbiwgYXMgd2VsbCBhcyBhIG1peCBv ZiBpbXBlcmF0aXZlIGFuZCBkZXNjcmlwdGl2ZSBsYW5ndWFnZS4gV2Ugc3VnZ2VzdCBtYWtpbmcg dGhlIHdob2xlIHNlY3Rpb24gbm9ybWF0aXZlIGFuZCBpbXBlcmF0aXZlIHRvIGJlIGNvbnNpc3Rl bnQuDQogUGFydGljdWxhciBpbnN0YW5jZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 IDMuMjogJnF1b3Q7dGhlIGxpZmV0aW1lIG9mIHRoZSB0b2tlbiBNVVNUIGJlIGxpbWl0ZWTigJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7IDMuMzogdmFsaWRhdGUgU1NMIGNlcnRpZmljYXRlIGNoYWlu czogJnF1b3Q7VGhlIGNsaWVudCBNVVNULi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkRvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyAz LjM6IGlzc3VlIHNob3J0IGxpdmVkIGJlYXJlciB0b2tlbnM6IENoYW5nZSB0byBzb21ldGhpbmcg bGlrZSAmcXVvdDtUb2tlbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNl cnZlcnMgU0hPVUxEIGlzc3VlIHNob3J0LWxpdmVkIChvbmUgaG91ciBvciBsZXNzKSBiZWFyZXIN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b2tlbnMsIHBhcnRpY3VsYXJs eSB3aGVuIGlzc3VpbmcgdG9rZW5zIHRvIGNsaWVudHMgdGhhdCBydW4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRoaW4gYSB3ZWIgYnJvd3NlciBvciBvdGhlciBlbnZp cm9ubWVudHMgd2hlcmUgaW5mb3JtYXRpb24NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBsZWFrYWdlIG1heSBvY2N1ci4gVXNpbmcgc2hvcnQtbGl2ZWQgYmVhcmVyIHRva2Vu cyBjYW4gcmVkdWNlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGlt cGFjdCBvZiBvbmUgb2YgdGhlbSBiZWluZyBsZWFrZWQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkRvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyAzLjM6IHNjb3BlZCBiZWFyZXIgdG9rZW5zOiAmcXVvdDtUb2tlbiBzZXJ2ZXJzIFNIT1VM RCBpc3N1ZSBiZWFyZXIgdG9rZW5zDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdGhhdCBjb250YWluIGFuIGF1ZGllbmNlIHJlc3RyaWN0aW9uLi4uJnF1b3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyAzLjM6IGRvbid0IHBhc3M6ICZxdW90O0JlYXJlciB0b2tlbnMgU0hPVUxE IE5PVCBiZSBwYXNzZWQgaW4gcGFnZSBVUkxzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKGZvciBleGFtcGxlIGFzIHF1ZXJ5IHN0cmluZyBwYXJhbWV0ZXJzKS4gSW5zdGVh ZCwgYmVhcmVyDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9rZW5zIFNI T1VMRCBiZSBwYXNzZWQgaW4gSFRUUCBtZXNzYWdlIGhlYWRlcnMgb3IgbWVzc2FnZQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvZGllcyBmb3Igd2hpY2ggY29uZmlkZW50 aWFsaXR5IG1lYXN1cmVzIGFyZSB0YWtlbi4gQnJvd3NlcnMsDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgd2ViIHNlcnZlcnMsIGFuZCBvdGhlciBzb2Z0d2FyZSBtYXkgbm90 IGFkZXF1YXRlbHkgc2VjdXJlIFVSTHMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBpbiB0aGUgYnJvd3NlciBoaXN0b3J5LCB3ZWIgc2VydmVyIGxvZ3MsIGFuZCBvdGhlciBk YXRhDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RydWN0dXJlcy4gSWYg YmVhcmVyIHRva2VucyBhcmUgcGFzc2VkIGluIHBhZ2UgVVJMcywgYXR0YWNrZXJzDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWlnaHQgYmUgYWJsZSB0byBzdGVhbCB0aGVt IGZyb20gdGhlIGhpc3RvcnkgZGF0YSwgbG9ncywgb3INCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBvdGhlciB1bnNlY3VyZWQgbG9jYXRpb25zLiZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5Eb25lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4tLSBKdXN0aW4gUmljaGVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PQXV0aCBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5PQXV0aEBpZXRmLm9yZzwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739435C24B250TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Wed Oct 19 17:19:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BB311E80B9 for ; Wed, 19 Oct 2011 17:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.01 X-Spam-Level: X-Spam-Status: No, score=-10.01 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCq5wjetqnQ7 for ; Wed, 19 Oct 2011 17:19:09 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 96DB611E80AF for ; Wed, 19 Oct 2011 17:19:09 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Oct 2011 17:18:56 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 17:18:54 -0700 From: Mike Jones To: Hannes Tschofenig , Barry Leiba Thread-Topic: Request to close issue 26 Thread-Index: AcyOvdU7nj88CCwwRcGDfy2fsngVeQ== Date: Thu, 20 Oct 2011 00:18:53 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24B2C9@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C24B2C9TK5EX14MBXC283r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Request to close issue 26 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:19:10 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C24B2C9TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chairs, Can you please close issue 26 http://trac.tools.ietf.org/wg/oauth/trac/tick= et/26 based upon the resolution incorporated in the bearer token specificat= ion draft 10? Thank you, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435C24B2C9TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chairs,

 

Can you please close issue 26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 based upon the resol= ution incorporated in the bearer token specification draft 10?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thank you,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435C24B2C9TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Wed Oct 19 17:23:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E6611E80B3 for ; Wed, 19 Oct 2011 17:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+Pk-dm9nfbY for ; Wed, 19 Oct 2011 17:23:10 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 34B0811E80AF for ; Wed, 19 Oct 2011 17:23:10 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Oct 2011 17:23:10 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0339.002; Wed, 19 Oct 2011 17:23:10 -0700 From: Mike Jones To: Hannes Tschofenig , Barry Leiba Thread-Topic: Request to open issue restricting scope syntax in core spec Thread-Index: AcyOvmFYMgQ5qEvGSuK40mQ1oST/GA== Date: Thu, 20 Oct 2011 00:23:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24B2F9@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C24B2F9TK5EX14MBXC283r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Request to open issue restricting scope syntax in core spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:23:10 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C24B2F9TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chairs, Can you please open an issue for the core spec to incorporate the scope cha= racter restrictions from the bearer spec into the core spec? These restric= tions are: scope =3D "scope" "=3D" <"> scope-val *( SP scope-val ) <"> scope-val =3D 1*scope-val-char scope-val-char =3D %x21 / %x23-5B / %x5D-7E Thank you, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435C24B2F9TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chairs,

 

Can you please open an issue for the core spec to in= corporate the scope character restrictions from the bearer spec into the co= re spec?  These restrictions are:

 

  = ; scope           =3D &qu= ot;scope" "=3D" <"> scope-val *( SP scope-val ) &= lt;">

  = ; scope-val       =3D 1*scope-val-char

  = ; scope-val-char  =3D %x21 / %x23-5B / %x5D-7E

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thank you,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435C24B2F9TK5EX14MBXC283r_-- From trac+oauth@trac.tools.ietf.org Wed Oct 19 21:28:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A20021F8A80 for ; Wed, 19 Oct 2011 21:28:26 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-JQZv6cVj4U for ; Wed, 19 Oct 2011 21:28:26 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D496821F8A7B for ; Wed, 19 Oct 2011 21:28:22 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RGkEp-0007U2-5U; Thu, 20 Oct 2011 00:28:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-oauth-v2-bearer@tools.ietf.org, barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 20 Oct 2011 04:28:15 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/26#comment:1 Message-ID: <078.e3e20215037ea818a7cd0d5649398adf@trac.tools.ietf.org> References: <063.05a6468910b9273126be082130670b4e@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <063.05a6468910b9273126be082130670b4e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-oauth-v2-bearer@tools.ietf.org, barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111020042822.D496821F8A7B@ietfa.amsl.com> Resent-Date: Wed, 19 Oct 2011 21:28:22 -0700 (PDT) Resent-From: trac+oauth@trac.tools.ietf.org Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #26: scope-v percent-encoding X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 04:28:26 -0000 #26: scope-v percent-encoding Changes (by barryleiba@…): * status: new => closed * resolution: => fixed Comment: Resolved on mailing list, fixed in version -10 of the draft. -- -------------------------------+------------------------------------------- Reporter: barryleiba@… | Owner: draft-ietf-oauth-v2-bearer@… Type: defect | Status: closed Priority: major | Milestone: Deliver bearer token spec Component: v2-bearer | Version: Severity: Active WG | Resolution: fixed Document | Keywords: | -------------------------------+------------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Wed Oct 19 21:31:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5841221F85A7 for ; Wed, 19 Oct 2011 21:31:29 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6JakhqKqYHA for ; Wed, 19 Oct 2011 21:31:28 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7D21F8560 for ; Wed, 19 Oct 2011 21:31:28 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RGkHp-0002aq-QY; Thu, 20 Oct 2011 00:31:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 20 Oct 2011 04:31:21 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/27 Message-ID: <063.83fd11fe6a8ec29f6192110a9c9ada21@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #27: Incorporate bearer "scope" character restrictions into the base spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 04:31:29 -0000 #27: Incorporate bearer "scope" character restrictions into the base spec This is part of the resolution of issue #26, as discussed on the mailing list: Can you please open an issue for the core spec to incorporate the scope character restrictions from the bearer spec into the core spec? These restrictions are: scope = "scope" "=" <"> scope-val *( SP scope-val ) <"> scope-val = 1*scope-val-char scope-val-char = %x21 / %x23-5B / %x5D-7E -- --------------------------------+------------------------------------ Reporter: barryleiba@… | Owner: Type: task | Status: new Priority: minor | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------ Ticket URL: oauth From hannes.tschofenig@gmx.net Wed Oct 19 22:08:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ABA21F8496 for ; Wed, 19 Oct 2011 22:08:36 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOc1SKd0D1+t for ; Wed, 19 Oct 2011 22:08:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4015121F83EF for ; Wed, 19 Oct 2011 22:08:34 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 05:08:33 -0000 Received: from unknown (EHLO [10.2.227.250]) [12.229.246.2] by mail.gmx.net (mp021) with SMTP; 20 Oct 2011 07:08:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fRq40pNPfYviv2GDLFt8tQlsCW/TcimusMuhoNn FkTvpDm8MS1lwu From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2011 22:08:30 -0700 Message-Id: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 05:08:36 -0000 Hi all,=20 in preparation of the upcoming IETF meeting Barry and I would like to = start a re-chartering discussion. We both are currently attending the = Internet Identity Workshop and so we had the chance to solicit input = from the participants. This should serve as a discussion starter.=20 Potential future OAuth charter items (in random order):=20 ---------------- 1) Dynamic Client Registration Protocol Available document:=20 http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ 2) Token Revocation Available document:=20 http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ 3) UMA=20 Available document:=20 http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ 4) Client Instance Extension Available document: http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt 5) XML Encoding Available document: http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt 6) JSON Web Token Available document: http://tools.ietf.org/html/draft-jones-json-web-token-05 7) JSON Web Token (JWT) Bearer Profile Available document:=20 http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 8) User Experience Extension Available document: http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 9) Request by Reference Available document:=20 http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 10) Simple Web Discovery Available document:=20 http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 ---------------- We have the following questions:=20 a) Are you interested in any of the above-listed items? (as a reviewer, = co-author, implementer, or someone who would like to deploy). It is also = useful to know if you think that we shouldn't work on a specific item.=20= b) Are there other items you would like to see the group working on? Note: In case your document is expired please re-submit it.=20 Ciao Hannes & Barry From eran@hueniverse.com Wed Oct 19 22:55:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD5421F84BB for ; Wed, 19 Oct 2011 22:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VROdQSesTCoW for ; Wed, 19 Oct 2011 22:55:59 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 3096D21F84B7 for ; Wed, 19 Oct 2011 22:55:59 -0700 (PDT) Received: (qmail 22081 invoked from network); 20 Oct 2011 05:55:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Oct 2011 05:55:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 19 Oct 2011 22:55:55 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , OAuth WG Date: Wed, 19 Oct 2011 22:55:47 -0700 Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AcyO5lTUjPxGS0xhR6GN44cjaSEXnwAA2dSQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452631E9057@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> In-Reply-To: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@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] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 05:55:59 -0000 No-brainer, low-hanging-fruit: 2) Token Revocation 8) User Experience Extension Don't see the point, but simple enough not to care if plenty of others want= to see it included: 4) Client Instance Extension 5) XML Encoding 9) Request by Reference Now for the objectionable... 1) Dynamic Client Registration Protocol This is premature standardization and must be deferred until we have enough= real world experience and real world requirements. Since we don't have eno= ugh interoperable web protocols (e.g. sharing photos), there is little need= for dynamic client registration at this point. Doing this wrong would be e= xtremely costly. We have tried this multiple times with OAuth 1.0 and faile= d because there was no one at the table shipping real-world products that n= eeded this functionality. 3) UMA This is big enough, and complex enough, for its own working group and list = (which I thought it already had elsewhere). Does not belong here. It is a l= ayer above OAuth, not part of it. 6) JSON Web Token 7) JSON Web Token (JWT) Bearer Profile This is big enough for its own working group and list. It also overlaps wit= h the new JSON signature working group recently created. 10) Simple Web Discovery First, this clearly does not belong here. This is a classic Application are= a item, and should really be raised in the application area general WG. I'd= also point out that the IESG has recently approved the publication of host= -meta as a proposed standard and the latest version includes a JSON flavor = which makes this work redundant. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Wednesday, October 19, 2011 10:09 PM > To: OAuth WG > Subject: [OAUTH-WG] Rechartering >=20 > Hi all, >=20 > in preparation of the upcoming IETF meeting Barry and I would like to sta= rt a > re-chartering discussion. We both are currently attending the Internet > Identity Workshop and so we had the chance to solicit input from the > participants. This should serve as a discussion starter. >=20 > Potential future OAuth charter items (in random order): >=20 > ---------------- >=20 > 1) Dynamic Client Registration Protocol >=20 > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >=20 > 2) Token Revocation >=20 > Available document: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >=20 > 3) UMA >=20 > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >=20 > 4) Client Instance Extension >=20 > Available document: > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >=20 > 5) XML Encoding >=20 > Available document: > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >=20 > 6) JSON Web Token >=20 > Available document: > http://tools.ietf.org/html/draft-jones-json-web-token-05 >=20 > 7) JSON Web Token (JWT) Bearer Profile >=20 > Available document: > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >=20 > 8) User Experience Extension >=20 > Available document: > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >=20 > 9) Request by Reference >=20 > Available document: > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >=20 > 10) Simple Web Discovery >=20 > Available document: > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >=20 > ---------------- >=20 > We have the following questions: >=20 > a) Are you interested in any of the above-listed items? (as a reviewer, c= o- > author, implementer, or someone who would like to deploy). It is also use= ful > to know if you think that we shouldn't work on a specific item. >=20 > b) Are there other items you would like to see the group working on? >=20 > Note: In case your document is expired please re-submit it. >=20 > Ciao > Hannes & Barry >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Thu Oct 20 00:13:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A125E11E8083 for ; Thu, 20 Oct 2011 00:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeylYZj4+cnA for ; Thu, 20 Oct 2011 00:13:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3E93D21F8AD1 for ; Thu, 20 Oct 2011 00:13:02 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 07:13:01 -0000 Received: from p5DCC3E45.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.62.69] by mail.gmx.net (mp072) with SMTP; 20 Oct 2011 09:13:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/cCiwEwMPctor3hkGNIO+NOO3vixjgXX1c8AXr/K eTjKLttoNLpUim Message-ID: <4E9FC9FA.8030001@gmx.de> Date: Thu, 20 Oct 2011 09:12:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:13:04 -0000 On 2011-10-20 01:38, Mike Jones wrote: > Draft 10 > of the > OAuth 2.0 Bearer Token Specification > has been > published, which incorporates consensus decisions reached since Working > Group Last Call feedback. It closes all open issues. It contains the > following changes: > ... This is better. I still see problems though. Section 2.2 specifies to use application/x-www-form-urlencoded encoding, but doesn't mention the character encoding to use. This may be a non-issue now for scopes, but it would be for extension parameters. Section 2.4 still uses quoted parameters without using the quoted-string constructs. This leaves implementers in the dark about whether they can use existing quoted-string parsers or not. Best regards, Julian From Michael.Jones@microsoft.com Thu Oct 20 00:14:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6234B21F8AE1 for ; Thu, 20 Oct 2011 00:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrJ0HJgdlSDl for ; Thu, 20 Oct 2011 00:14:41 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB1F21F8AD2 for ; Thu, 20 Oct 2011 00:14:41 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 00:14:41 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 00:14:41 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 Thread-Index: AcyOuBvrce+R9JZJS5GdKjqOZuv3GwAekJcAAA6gPVA= Date: Thu, 20 Oct 2011 07:14:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> In-Reply-To: <4E9FC9FA.8030001@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:14:42 -0000 Can you recommend specific wording changes to address both issues? -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Thursday, October 20, 2011 12:13 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 On 2011-10-20 01:38, Mike Jones wrote: > Draft 10 > of=20 > the OAuth 2.0 Bearer Token Specification=20 > has=20 > been published, which incorporates consensus decisions reached since=20 > Working Group Last Call feedback. It closes all open issues. It=20 > contains the following changes: > ... This is better. I still see problems though. Section 2.2 specifies to use application/x-www-form-urlencoded encoding, bu= t doesn't mention the character encoding to use. This may be a non-issue no= w for scopes, but it would be for extension parameters. Section 2.4 still uses quoted parameters without using the quoted-string co= nstructs. This leaves implementers in the dark about whether they can use e= xisting quoted-string parsers or not. Best regards, Julian From julian.reschke@gmx.de Thu Oct 20 00:37:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B4621F889A for ; Thu, 20 Oct 2011 00:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.912 X-Spam-Level: X-Spam-Status: No, score=-103.912 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGgTXuuHAiCF for ; Thu, 20 Oct 2011 00:37:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6437421F8726 for ; Thu, 20 Oct 2011 00:37:12 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 07:37:10 -0000 Received: from p5DCC3E45.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.62.69] by mail.gmx.net (mp009) with SMTP; 20 Oct 2011 09:37:10 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+NekU7PeCN/quG8CIZGU5FmgROHhPEi/rebY4CZk 8rM2g0MkYapZ50 Message-ID: <4E9FCFA4.7050706@gmx.de> Date: Thu, 20 Oct 2011 09:37:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:37:18 -0000 On 2011-10-20 09:14, Mike Jones wrote: > Can you recommend specific wording changes to address both issues? 2.2: "The entity-body is encoded using the "application/x-www-form-urlencoded" media type (Section 17.13.4 of [W3C.REC-html401-19991224]), applied to the UTF-8 [RFC3629] encoded forms of the parameter values." Note 1: HTML4 ignores the encoding issue; this is a case where a reference to HTML5 would actually help in practice. Note 2: I prefer refs in the form of [REC-html] or [HTML] rather than [W3C.REC-html401-19991224]... 2.4: As stated earlier, just define all those parameters to be "token / quoted-string", and then constrain the values further separately, such as: "The value of the scope parameter, after potential quoted-string unquoting, contains a set of single-SP delimited scope values." Each scope value is restricted to scope-val-char = %x21 / %x23-5B / %x5D-7E ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII " etc. Best regards, Julian From Michael.Jones@microsoft.com Thu Oct 20 00:41:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7865D21F8ACC for ; Thu, 20 Oct 2011 00:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.079 X-Spam-Level: X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra6lIfHxqnlP for ; Thu, 20 Oct 2011 00:41:36 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9221F84D7 for ; Thu, 20 Oct 2011 00:41:36 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 00:41:35 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 00:41:35 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 Thread-Index: AcyOuBvrce+R9JZJS5GdKjqOZuv3GwAekJcAAA6gPVD//5G+AIAAdPAw Date: Thu, 20 Oct 2011 07:41:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24CBB6@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FCFA4.7050706@gmx.de> In-Reply-To: <4E9FCFA4.7050706@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:41:36 -0000 Your proposed wording for 2.4 misses the point: \ MUST NOT occur at all in= the input string. No quoting may occur. Care to suggest other wording that recognizes this point but still addresse= s the issue you raise? -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Thursday, October 20, 2011 12:37 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 On 2011-10-20 09:14, Mike Jones wrote: > Can you recommend specific wording changes to address both issues? 2.2: "The entity-body is encoded using the "application/x-www-form-urlencod= ed" media type (Section 17.13.4 of [W3C.REC-html401-19991224]), applied to = the UTF-8 [RFC3629] encoded forms of the parameter values." Note 1: HTML4 ignores the encoding issue; this is a case where a reference = to HTML5 would actually help in practice. Note 2: I prefer refs in the form of [REC-html] or [HTML] rather than [W3C.= REC-html401-19991224]... 2.4: As stated earlier, just define all those parameters to be "token /=20 quoted-string", and then constrain the values further separately, such as: "The value of the scope parameter, after potential quoted-string=20 unquoting, contains a set of single-SP delimited scope values." Each=20 scope value is restricted to scope-val-char =3D %x21 / %x23-5B / %x5D-7E ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII " etc. Best regards, Julian From julian.reschke@gmx.de Thu Oct 20 01:05:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D0421F8C0C for ; Thu, 20 Oct 2011 01:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.834 X-Spam-Level: X-Spam-Status: No, score=-103.834 tagged_above=-999 required=5 tests=[AWL=-1.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtrBmm0g6Emr for ; Thu, 20 Oct 2011 01:05:28 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 494FF21F8B00 for ; Thu, 20 Oct 2011 01:05:28 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 08:05:25 -0000 Received: from p5DCC3E45.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.62.69] by mail.gmx.net (mp052) with SMTP; 20 Oct 2011 10:05:25 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18S6187qFISv8AzbAqt61ezPCYM36GMYP5YRgcNjv J2X5CuIiq2ZGvo Message-ID: <4E9FD642.9070100@gmx.de> Date: Thu, 20 Oct 2011 10:05:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FCFA4.7050706@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CBB6@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24CBB6@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 08:05:29 -0000 On 2011-10-20 09:41, Mike Jones wrote: > Your proposed wording for 2.4 misses the point: \ MUST NOT occur at all in the input string. No quoting may occur. > ... No, it doesn't miss the point. You need to tell implementers whether they can use a quoted-string processor. Those processors will accept all the values you want to support, plus values that contain "\c" (representing "c"). Is this ok, or are recipients supposed to reject these values? Furthermore, it's not clear what recipients are supposed to do with values that are not quoted, for instance for scope. The ABNF makes them illegal, but I promise you that many recipients will accept them nevertheless (unless you manage them to become draconian using a very good test suite). See for a test case checking this for the realm parameter. It's already bad for many existing headers, please let's do things right with new ones. Best regards, Julian From julian.reschke@gmx.de Thu Oct 20 01:11:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B27C21F8573 for ; Thu, 20 Oct 2011 01:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.766 X-Spam-Level: X-Spam-Status: No, score=-103.766 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyZpFrBuIbM8 for ; Thu, 20 Oct 2011 01:11:00 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3F3CD21F8586 for ; Thu, 20 Oct 2011 01:11:00 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 08:10:55 -0000 Received: from p5DCC3E45.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.62.69] by mail.gmx.net (mp025) with SMTP; 20 Oct 2011 10:10:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18nVWZV+pMnYewlijXbV9fzZnGnTL7/DWpnhGTulx dIh6ahz3Wyvzxh Message-ID: <4E9FD785.1010708@gmx.de> Date: Thu, 20 Oct 2011 10:10:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FCFA4.7050706@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CBB6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FD642.9070100@gmx.de> In-Reply-To: <4E9FD642.9070100@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 08:11:01 -0000 On 2011-10-20 10:05, Julian Reschke wrote: > On 2011-10-20 09:41, Mike Jones wrote: >> Your proposed wording for 2.4 misses the point: \ MUST NOT occur at >> all in the input string. No quoting may occur. > > ... > > No, it doesn't miss the point. > > You need to tell implementers whether they can use a quoted-string > processor. Those processors will accept all the values you want to > support, plus values that contain "\c" (representing "c"). Is this ok, > or are recipients supposed to reject these values? > > Furthermore, it's not clear what recipients are supposed to do with > values that are not quoted, for instance for scope. The ABNF makes them > illegal, but I promise you that many recipients will accept them > nevertheless (unless you manage them to become draconian using a very > good test suite). > > See for a test > case checking this for the realm parameter. It's already bad for many > existing headers, please let's do things right with new ones. > > Best regards, Julian ...finally, the syntax for the WWW-Authenticate header field is defined by HTTPbis, not the OAuth spec. Recipients need to process the header field using a generic parser, and only after doing so can delegate to an OAuth-specific component for interpretation of the OAuth-specific semantics. Translation: a recipient that supports multiple authentication schemes is unlikely to implement an OAuth-specific *parser* for the header field. Best regards, Julian From julian.reschke@gmx.de Thu Oct 20 01:45:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FC721F848A for ; Thu, 20 Oct 2011 01:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.704 X-Spam-Level: X-Spam-Status: No, score=-103.704 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvwzO9yfUZc7 for ; Thu, 20 Oct 2011 01:45:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3760821F8BBC for ; Thu, 20 Oct 2011 01:45:41 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 08:45:39 -0000 Received: from p5DCC3E45.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.62.69] by mail.gmx.net (mp062) with SMTP; 20 Oct 2011 10:45:39 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+7GMV6bsW7YOUi06LkpWLs1YEdRE0qdjZKopnuIE /zR3vjFULqI+v3 Message-ID: <4E9FDFAF.20505@gmx.de> Date: Thu, 20 Oct 2011 10:45:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] choice of credentials syntax, was: OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 08:45:42 -0000 On 2011-10-20 01:38, Mike Jones wrote: > ... > ·Removed the #auth-param option from Authorization header syntax > (leaving only the b64token syntax). > ... I recommend that adding a rational, such as: "The b64token syntax was chosen over an extensible parameter syntax (see [HTTPbisP7], Section 2.3.1) due to compatibility concerns with early implementations. If in the future, additional fields will be needed, a new authentication scheme will have to be defined". (I think this captures what lead to the choice, and helps other readers understand why the spec isn't following the recommendations in the HTTP Authentication spec). Best regards, Julian From tonynad@microsoft.com Thu Oct 20 06:49:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFB121F8BE9 for ; Thu, 20 Oct 2011 06:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vySAS+uuTymL for ; Thu, 20 Oct 2011 06:49:33 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B047221F8BE7 for ; Thu, 20 Oct 2011 06:49:33 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 06:49:33 -0700 Received: from VA3EHSOBE010.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.339.2; Thu, 20 Oct 2011 06:49:33 -0700 Received: from mail87-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Thu, 20 Oct 2011 13:49:32 +0000 Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3-R.bigfish.com (Postfix) with ESMTP id 3D93D1D041F for ; Thu, 20 Oct 2011 13:49:32 +0000 (UTC) X-SpamScore: -32 X-BigFish: PS-32(zz9371K542M14ffOzz1202h1082kzz1033IL8275dhz31h2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT015.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail87-va3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT015.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3 (MessageSwitch) id 1319118571985142_26398; Thu, 20 Oct 2011 13:49:31 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.242]) by mail87-va3.bigfish.com (Postfix) with ESMTP id D5B60D30056; Thu, 20 Oct 2011 13:49:31 +0000 (UTC) Received: from SN2PRD0302HT015.namprd03.prod.outlook.com (207.46.4.139) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 20 Oct 2011 13:49:27 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.4.67]) by SN2PRD0302HT015.namprd03.prod.outlook.com ([10.27.90.241]) with mapi id 14.01.0225.071; Thu, 20 Oct 2011 13:49:26 +0000 From: Anthony Nadalin To: Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMjub7tsSnzwxIKk2nsnZNOeFJupWFPxcw Date: Thu, 20 Oct 2011 13:49:26 +0000 Message-ID: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> In-Reply-To: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.43.172.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT015.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMX.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:49:34 -0000 If scoped right I don't see any issues with any of these proposed items fit= ting into this WG, the question will be do we have the band width to work o= n all these items, as some are big and some are fairly small and contained.= May have to have some prioritized list of where people think these fit.=20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Wednesday, October 19, 2011 10:09 PM To: OAuth WG Subject: [OAUTH-WG] Rechartering Hi all,=20 in preparation of the upcoming IETF meeting Barry and I would like to start= a re-chartering discussion. We both are currently attending the Internet = Identity Workshop and so we had the chance to solicit input from the partic= ipants. This should serve as a discussion starter.=20 Potential future OAuth charter items (in random order):=20 ---------------- 1) Dynamic Client Registration Protocol Available document:=20 http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ 2) Token Revocation Available document:=20 http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ 3) UMA=20 Available document:=20 http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ 4) Client Instance Extension Available document: http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt 5) XML Encoding Available document: http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt 6) JSON Web Token Available document: http://tools.ietf.org/html/draft-jones-json-web-token-05 7) JSON Web Token (JWT) Bearer Profile Available document:=20 http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 8) User Experience Extension Available document: http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 9) Request by Reference Available document:=20 http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 10) Simple Web Discovery Available document:=20 http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 ---------------- We have the following questions:=20 a) Are you interested in any of the above-listed items? (as a reviewer, co-= author, implementer, or someone who would like to deploy). It is also usefu= l to know if you think that we shouldn't work on a specific item.=20 b) Are there other items you would like to see the group working on? Note: In case your document is expired please re-submit it.=20 Ciao Hannes & Barry _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Thu Oct 20 08:33:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E465E21F8C2D for ; Thu, 20 Oct 2011 08:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRGaOH1ubj7T for ; Thu, 20 Oct 2011 08:33:33 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 648E621F8C1E for ; Thu, 20 Oct 2011 08:33:33 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 08:33:33 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 08:33:32 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 Thread-Index: AcyOuBvrce+R9JZJS5GdKjqOZuv3GwAekJcAAA6gPVD//5G+AIAAdPAw//+S9AD///kYEA== Date: Thu, 20 Oct 2011 15:33:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24D2C4@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FCFA4.7050706@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CBB6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FD642.9070100@gmx.de> In-Reply-To: <4E9FD642.9070100@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:33:34 -0000 By design, implementations can use existing quoted-string parsers, as these= accept and correctly process all legal scope values. The spec is silent on what to do with illegal values, such as those contain= ing \ or those not surrounded by ". Conforming implementations will not pr= oduce such values, and so there's no actual problem in practice, whether yo= u use an off-the-shelf parameter parser or one specific to the Bearer schem= e. Thanks for sweating the details, by the way. The spec is better for it. Best wishes, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Thursday, October 20, 2011 1:05 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 On 2011-10-20 09:41, Mike Jones wrote: > Your proposed wording for 2.4 misses the point: \ MUST NOT occur at all = in the input string. No quoting may occur. > ... No, it doesn't miss the point. You need to tell implementers whether they can use a quoted-string processo= r. Those processors will accept all the values you want to support, plus va= lues that contain "\c" (representing "c"). Is this ok, or are recipients su= pposed to reject these values? Furthermore, it's not clear what recipients are supposed to do with values = that are not quoted, for instance for scope. The ABNF makes them illegal, b= ut I promise you that many recipients will accept them nevertheless (unless= you manage them to become draconian using a very good test suite). See for a test case= checking this for the realm parameter. It's already bad for many existing = headers, please let's do things right with new ones. Best regards, Julian From wmills@yahoo-inc.com Thu Oct 20 08:36:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CCC21F8C71 for ; Thu, 20 Oct 2011 08:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.398 X-Spam-Level: X-Spam-Status: No, score=-17.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPm2Yp3GlRMf for ; Thu, 20 Oct 2011 08:36:30 -0700 (PDT) Received: from nm32-vm3.bullet.mail.ne1.yahoo.com (nm32-vm3.bullet.mail.ne1.yahoo.com [98.138.229.51]) by ietfa.amsl.com (Postfix) with SMTP id 902EE21F8C6E for ; Thu, 20 Oct 2011 08:36:30 -0700 (PDT) Received: from [98.138.90.51] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 20 Oct 2011 15:36:22 -0000 Received: from [98.138.87.7] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 20 Oct 2011 15:36:22 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 20 Oct 2011 15:36:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 766531.86338.bm@omp1007.mail.ne1.yahoo.com Received: (qmail 80873 invoked by uid 60001); 20 Oct 2011 15:36:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1319124982; bh=AC8aGze6BwvTVIALVaW5RJoSjL1qvuWNYjWDSBfOdac=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hyIJ9Ih90Z5/jY5MTKyL+5P7ialhgVqhrlhmz2fiX+apG7S+v6f0JoeKNjSASJIqrHlq8/wp778JgPV85yJe8+UzDcGttX3Au4+HJJZUndshbEAhLyhrC15eHG8vRxl7oh89dL2K/dSP/Mm4F03JbE4YXtevKjuEd+xjbQaSBRo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=egxMfxPK1D1Exl7EY1rAN97Y7vRZnQXCHCuIcK12jPWJmaTRlo+A7tHCygRUzjitqZNndUdz6KYPjakSkNx2F1ziRnoTC0jhi9hryizuP503mKiOH6q/9jYWF5630JIHwW3s8dAT/lM8bFAAfeOMLnnJtEq5k60RFOuURoHMsD8=; X-YMail-OSG: CgIUH6IVM1k8I3IHVtk9TFw0skCxJRBmxUiqZGKWXJHYld7 S.Z.nxzP4y02mikf6wkqZGaxqbeVZN_RbhJdqSuZJvAUJezWYjlxuSP2komu Ixt4fMYPd6jDEe4qhZOMDfiISnC9dKx0O7i90l0QIYE2RZVcwhBAHqDQYsXR Xs3IGLy3hQK0xiteqJ61TQrRRiqyVxl9x_5qTvWbTtcLVjhRFSQU7aJ5pZyq nAGKMlX2FX5EAvYD1SV4EwD5Xzz.kr.fhqAJMOZF3tYT9tt5V2dgnN1irCWj 9iMC2q4PDIhJ5_1kYesMmCfin_KZjXDt6KOnW_d8Y4FHBZJk5Fw3YJHTzkMw JfCi5PRvYk8Za8KZsuF.ifs2MDQy7Hda_gjtgAK7GmAnanX7F6hGnmTF8UUT JDqOiBjhvf9Q- Received: from [99.31.212.42] by web31812.mail.mud.yahoo.com via HTTP; Thu, 20 Oct 2011 08:36:22 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.325013 References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FCFA4.7050706@gmx.de> Message-ID: <1319124982.70621.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 20 Oct 2011 08:36:22 -0700 (PDT) From: William Mills To: Julian Reschke , Mike Jones In-Reply-To: <4E9FCFA4.7050706@gmx.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1663701383-1319124982=:70621" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:36:31 -0000 --0-1663701383-1319124982=:70621 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Shouldn't the scope definition here refer to the scope definition in the co= re spec?=0A=0A=0A=0A________________________________=0AFrom: Julian Reschke= =0ATo: Mike Jones =0AC= c: "oauth@ietf.org" =0ASent: Thursday, October 20, 2011 12:= 37 AM=0ASubject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft = -10=0A=0AOn 2011-10-20 09:14, Mike Jones wrote:=0A> Can you recommend speci= fic wording changes to address both issues?=0A=0A=0A2.2: "The entity-body i= s encoded using the "application/x-www-form-urlencoded" media type (Section= 17.13.4 of [W3C.REC-html401-19991224]), applied to the UTF-8 [RFC3629] enc= oded forms of the parameter values."=0A=0ANote 1: HTML4 ignores the encodin= g issue; this is a case where a reference to HTML5 would actually help in p= ractice.=0A=0ANote 2: I prefer refs in the form of [REC-html] or [HTML] rat= her than [W3C.REC-html401-19991224]...=0A=0A=0A2.4: As stated earlier, just= define all those parameters to be "token / quoted-string", and then constr= ain the values further separately, such as:=0A=0A"The value of the scope pa= rameter, after potential quoted-string unquoting, contains a set of single-= SP delimited scope values." Each scope value is restricted to=0A=0A=A0 scop= e-val-char=A0 =3D %x21 / %x23-5B / %x5D-7E=0A=A0 ; HTTPbis P1 qdtext except= whitespace, restricted to US-ASCII=0A"=0A=0Aetc.=0A=0ABest regards, Julian= =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1663701383-1319124982=:70621 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Shouldn't the scope definition here refer to the scope definition in the = core spec?

From: Julian Reschke <julian.reschke@gmx.de>
= To: Mike Jones <Michael= .Jones@microsoft.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, October 20, 2011 12:37 AM
Subject: Re: [OAUTH-WG] OAuth 2.0= Bearer Token Specification Draft -10

=0AOn 2011-10-20 09:14, Mike Jones w= rote:
> Can you recommend specific wording changes to address both is= sues?


2.2: "The entity-body is encoded using the "application/x-= www-form-urlencoded" media type (Section 17.13.4 of [W3C.REC-html401-199912= 24]), applied to the UTF-8 [RFC3629] encoded forms of the parameter values.= "

Note 1: HTML4 ignores the encoding issue; this is a case where a r= eference to HTML5 would actually help in practice.

Note 2: I prefer = refs in the form of [REC-html] or [HTML] rather than [W3C.REC-html401-19991= 224]...


2.4: As stated earlier, just define all those parameters= to be "token / quoted-string", and then constrain the values further separ= ately, such as:

"The value of the scope parameter, after potential q= uoted-string unquoting, contains a set of single-SP delimited scope values.= " Each scope value is restricted to

  scope-val-char  =3D = %x21 / %x23-5B / %x5D-7E
  ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII
"

et= c.

Best regards, Julian
_________________________________________= ______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth


--0-1663701383-1319124982=:70621-- From julian.reschke@gmx.de Thu Oct 20 08:46:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8070121F8C59 for ; Thu, 20 Oct 2011 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.062 X-Spam-Level: X-Spam-Status: No, score=-103.062 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYJDD5qp-3oI for ; Thu, 20 Oct 2011 08:46:34 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 915BE21F8B86 for ; Thu, 20 Oct 2011 08:46:27 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 15:46:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 20 Oct 2011 17:46:26 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Rgd092UMRUbMBebmIv/Edt9U4vSvpIcLFNWw51G y6u3ewYp1GkWw0 Message-ID: <4EA0424E.8000604@gmx.de> Date: Thu, 20 Oct 2011 17:46:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FCFA4.7050706@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CBB6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FD642.9070100@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24D2C4@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24D2C4@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:46:35 -0000 On 2011-10-20 17:33, Mike Jones wrote: > By design, implementations can use existing quoted-string parsers, as these accept and correctly process all legal scope values. > > The spec is silent on what to do with illegal values, such as those containing \ or those not surrounded by ". Conforming implementations will not produce such values, and so there's no actual problem in practice, whether you use an off-the-shelf parameter parser or one specific to the Bearer scheme. > ... Conforming implementations can produce WWW-Authenticate header fields containing quoted-strings containing escapes. This is under the jurisdiction of the HTTP spec, not the OAuth spec. OAuth can profile the legal values *just* for the OAuth scheme, but consumers will still need to be able to process a header field that contains multiple challenges from schemes != OAuth, and to do so, they *have* to use a proper parser. Consider the following challenge: WWW-Authenticate: foo realm="x", title="my \"test\" site", oauth realm="y" A component that handles WWW-Authenticate absolutely has to rely on predictable syntax for quoted strings. It doesn't make any sense to special-case OAuth params just because escaping isn't needed. This makes things harder and more likely to fail, not simpler. Best regards, Julian From barryleiba.mailing.lists@gmail.com Thu Oct 20 09:05:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C821F8CE2 for ; Thu, 20 Oct 2011 09:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1y1HFyYOeRB for ; Thu, 20 Oct 2011 09:05:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3ADB21F8CDF for ; Thu, 20 Oct 2011 09:05:06 -0700 (PDT) Received: by gyh20 with SMTP id 20so3562868gyh.31 for ; Thu, 20 Oct 2011 09:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=emz4zE63YGsDAGGtEJyWJrnLtGXI5vk6o0ov3L9itzc=; b=F//NLWVzDxUlWlkM9Z9TuhE4072SkWy9AJa06+gxiO9KIKOkd7exmVG533qYhPhT6O nidLbqX8yrpe9I4adYXEYTxYApIgmsmxYa0gRvZXvAss7lPSptHpkRp3dVIGx2baRuTM xgm4W/xx0GGrXX52jpoq5GcpZ/P8rot7wu09I= MIME-Version: 1.0 Received: by 10.236.77.104 with SMTP id c68mr16587405yhe.69.1319126706420; Thu, 20 Oct 2011 09:05:06 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.33.6 with HTTP; Thu, 20 Oct 2011 09:05:06 -0700 (PDT) In-Reply-To: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> Date: Thu, 20 Oct 2011 12:05:06 -0400 X-Google-Sender-Auth: bwxZVDZ2R1_ly5OKCzMcVMK9atA Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:05:07 -0000 > do we have the band width to work on all these items, as some are > big and some are fairly small and contained. May have to have some > prioritized list of where people think these fit. Yes, exactly. And one of the things we'd like to hear from all of you is what your priorities are... how you would prioritize the list. Barry, chair-like object From hannes.tschofenig@gmx.net Thu Oct 20 09:14:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D88521F8CE6 for ; Thu, 20 Oct 2011 09:14:35 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIQwReY30IT0 for ; Thu, 20 Oct 2011 09:14:34 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2088021F8CEE for ; Thu, 20 Oct 2011 09:14:33 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 16:14:32 -0000 Received: from unknown (EHLO [10.2.2.99]) [64.9.249.121] by mail.gmx.net (mp006) with SMTP; 20 Oct 2011 18:14:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18qFVk+5xMqjW5rCJSZ7d1z156zf1BPID/4tzc/SJ LZ9X0+PCAaGBX9 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Oct 2011 09:14:28 -0700 Message-Id: To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:14:35 -0000 Section 2 of draft-ietf-oauth-v2-bearer-10 describes three methods of = sending bearer access tokens in resource requests to resource servers, = namely 1) Authorization Request Headers (described in Section 2.1) 2) Form-Encoded Body Parameter (described in Section 2.2) =20 3) URI Query Parameter (described in Section 2.3) The specification recommends to use Authorization Request Headers and = discourages the other two methods.=20 Unfortunately, there is no background provided why we still describe = them.=20 Could someone provide text justifying why they are in there?=20 Ciao Hannes From jricher@mitre.org Thu Oct 20 09:21:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8030F21F8BE5 for ; Thu, 20 Oct 2011 09:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk3tGzgGjeeY for ; Thu, 20 Oct 2011 09:21:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2723221F86D0 for ; Thu, 20 Oct 2011 09:21:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6055A21B05BD; Thu, 20 Oct 2011 12:21:54 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4BE5221B05B6; Thu, 20 Oct 2011 12:21:54 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.101]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Thu, 20 Oct 2011 12:21:54 -0400 From: "Richer, Justin P." To: Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-10 Thread-Index: AQHMj0N2DhJlWBqWNEiFbBpUGDKMbZWFaR+k Date: Thu, 20 Oct 2011 16:21:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:21:58 -0000 I don't think we need text in the spec itself, but I do have explanation: = =0A= =0A= 1) It's very common current practice=0A= 2) In many cases, the client doesn't have access to the headers in any appr= eciable way=0A= 3) A URL with all parameters including authorization is a powerful artifact= which can be passed around between systems as a unit (this is something I = wish the MAC token spec allowed as well)=0A= =0A= -- Justin=0A= ________________________________________=0A= From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Hannes T= schofenig [hannes.tschofenig@gmx.net]=0A= Sent: Thursday, October 20, 2011 12:14 PM=0A= To: OAuth WG=0A= Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-10=0A= =0A= Section 2 of draft-ietf-oauth-v2-bearer-10 describes three methods of sendi= ng bearer access tokens in resource requests to resource servers, namely=0A= 1) Authorization Request Headers (described in Section 2.1)=0A= 2) Form-Encoded Body Parameter (described in Section 2.2)=0A= 3) URI Query Parameter (described in Section 2.3)=0A= =0A= The specification recommends to use Authorization Request Headers and disco= urages the other two methods.=0A= Unfortunately, there is no background provided why we still describe them.= =0A= =0A= Could someone provide text justifying why they are in there?=0A= =0A= Ciao=0A= Hannes=0A= =0A= _______________________________________________=0A= OAuth mailing list=0A= OAuth@ietf.org=0A= https://www.ietf.org/mailman/listinfo/oauth=0A= From jricher@mitre.org Thu Oct 20 09:30:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD1C21F89BA for ; Thu, 20 Oct 2011 09:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FJmUmhWYAYx for ; Thu, 20 Oct 2011 09:30:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0279E21F86AA for ; Thu, 20 Oct 2011 09:30:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A95DA21B05F9; Thu, 20 Oct 2011 12:30:41 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9F78621B05BD; Thu, 20 Oct 2011 12:30:41 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.101]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Thu, 20 Oct 2011 12:30:41 -0400 From: "Richer, Justin P." To: Barry Leiba , OAuth WG Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMjuZUxOCzG5jjVkyNkG8gNxk6H5WFg2oAgAAl6AD//8HAeA== Date: Thu, 20 Oct 2011 16:30:40 +0000 Message-ID: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:30:42 -0000 I think it will be true that the whole working group won't be focusing on a= ll documents at the same time, much in the same way that different subsets = of our current WG have focused on things like the security document or SAML= bindings. In this fashion, I believe we'll be able to pull expertise from = different sectors to produce a family of documents that live in an ecosyste= m around OAuth. =0A= =0A= For many of these documents, even though they're not directly OAuth pieces = (like JWT), but where else should they live? This may not be The Way That I= ETF Does It (I'm honestly not sure), but in my opinion, as long as each doc= ument has a dedicated editor and at least some interaction/support with the= group we can handle many of these smaller items.=0A= =0A= -- Justin=0A= ________________________________________=0A= From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Barry Le= iba [barryleiba@computer.org]=0A= Sent: Thursday, October 20, 2011 12:05 PM=0A= To: OAuth WG=0A= Subject: Re: [OAUTH-WG] Rechartering=0A= =0A= > do we have the band width to work on all these items, as some are=0A= > big and some are fairly small and contained. May have to have some=0A= > prioritized list of where people think these fit.=0A= =0A= Yes, exactly. And one of the things we'd like to hear from all of you=0A= is what your priorities are... how you would prioritize the list.=0A= =0A= Barry, chair-like object=0A= _______________________________________________=0A= OAuth mailing list=0A= OAuth@ietf.org=0A= https://www.ietf.org/mailman/listinfo/oauth=0A= From Hannes.Tschofenig@gmx.net Thu Oct 20 10:21:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4250321F8C2B for ; Thu, 20 Oct 2011 10:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.49 X-Spam-Level: X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb3Mi7RKAb7m for ; Thu, 20 Oct 2011 10:21:50 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9524D21F8C1E for ; Thu, 20 Oct 2011 10:21:50 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 17:21:48 -0000 Received: from unknown (EHLO [10.2.2.99]) [64.9.249.121] by mail.gmx.net (mp043) with SMTP; 20 Oct 2011 19:21:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX199Pydleyl9S9mYJW0Zn0WAxS0g48xIf/UuiGdxqS dAjlzg9Q7tN3Vn From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Oct 2011 10:14:18 -0700 Message-Id: <4FDBF97E-D5A8-4DA4-91C2-1E24111CC254@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Nits in draft-ietf-oauth-v2-bearer-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:21:51 -0000 Julian checked the ABNF in draft-ietf-oauth-v2-bearer-10 using = http://trac.tools.ietf.org/wg/httpbis/trac/browser/abnfparser/bap and = noticed that we should replace <"> with DQUOTE. From Hannes.Tschofenig@gmx.net Thu Oct 20 10:24:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C206B21F8C35 for ; Thu, 20 Oct 2011 10:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwmaxfOkEE8z for ; Thu, 20 Oct 2011 10:24:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 217C421F8C2D for ; Thu, 20 Oct 2011 10:24:03 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 17:24:02 -0000 Received: from unknown (EHLO [10.2.2.99]) [64.9.249.121] by mail.gmx.net (mp003) with SMTP; 20 Oct 2011 19:24:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19NsftBOfBNjXHwif/Y0O+d7JRZomlD3L9kJaBVXq XE1bufWYlnmys7 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 20 Oct 2011 10:18:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> , To: "Richer, Justin P." X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG , Barry Leiba Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:24:05 -0000 Certainly not everyone needs to pay attention to everything. We are, = however, trying to determine whether there is a critical mass of = interested persons for a given item in terms of reviews, document = authors, implementers, and deployers.=20 I do not see a problem at all with working on JWT within the OAuth = working group. I thought that we had already decided in the past that = the JSON signature & encryption work would go into JOES (earlier WOES) = and the home for JWT is the OAuth working group. The area directors may = have a different opinion but for the moment this is my working = assumption.=20 Ciao Hannes On Oct 20, 2011, at 9:30 AM, Richer, Justin P. wrote: > I think it will be true that the whole working group won't be focusing = on all documents at the same time, much in the same way that different = subsets of our current WG have focused on things like the security = document or SAML bindings. In this fashion, I believe we'll be able to = pull expertise from different sectors to produce a family of documents = that live in an ecosystem around OAuth.=20 >=20 > For many of these documents, even though they're not directly OAuth = pieces (like JWT), but where else should they live? This may not be The = Way That IETF Does It (I'm honestly not sure), but in my opinion, as = long as each document has a dedicated editor and at least some = interaction/support with the group we can handle many of these smaller = items. >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of = Barry Leiba [barryleiba@computer.org] > Sent: Thursday, October 20, 2011 12:05 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering >=20 >> do we have the band width to work on all these items, as some are >> big and some are fairly small and contained. May have to have some >> prioritized list of where people think these fit. >=20 > Yes, exactly. And one of the things we'd like to hear from all of you > is what your priorities are... how you would prioritize the list. >=20 > Barry, chair-like object > _______________________________________________ > 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 Thu Oct 20 10:44:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C1B21F8C1D for ; Thu, 20 Oct 2011 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeUTVoyIt+UV for ; Thu, 20 Oct 2011 10:44:03 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id E7AE021F8C11 for ; Thu, 20 Oct 2011 10:44:02 -0700 (PDT) Received: (qmail 9105 invoked from network); 20 Oct 2011 17:40:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Oct 2011 17:40:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 20 Oct 2011 10:40:18 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig , "Richer, Justin P." Date: Thu, 20 Oct 2011 10:40:08 -0700 Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AcyPTRpjT/0VlDtkQzOw3EG7tyHe8wAAhdrw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452631E911E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.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: Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:44:03 -0000 Who is "we had already decided"? This was not discussed on this list. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Thursday, October 20, 2011 10:19 AM > To: Richer, Justin P. > Cc: OAuth WG; Barry Leiba > Subject: Re: [OAUTH-WG] Rechartering >=20 > Certainly not everyone needs to pay attention to everything. We are, > however, trying to determine whether there is a critical mass of interest= ed > persons for a given item in terms of reviews, document authors, > implementers, and deployers. >=20 > I do not see a problem at all with working on JWT within the OAuth workin= g > group. I thought that we had already decided in the past that the JSON > signature & encryption work would go into JOES (earlier WOES) and the > home for JWT is the OAuth working group. The area directors may have a > different opinion but for the moment this is my working assumption. >=20 > Ciao > Hannes >=20 >=20 > On Oct 20, 2011, at 9:30 AM, Richer, Justin P. wrote: >=20 > > I think it will be true that the whole working group won't be focusing = on all > documents at the same time, much in the same way that different subsets o= f > our current WG have focused on things like the security document or SAML > bindings. In this fashion, I believe we'll be able to pull expertise from > different sectors to produce a family of documents that live in an ecosys= tem > around OAuth. > > > > For many of these documents, even though they're not directly OAuth > pieces (like JWT), but where else should they live? This may not be The W= ay > That IETF Does It (I'm honestly not sure), but in my opinion, as long as = each > document has a dedicated editor and at least some interaction/support wit= h > the group we can handle many of these smaller items. > > > > -- Justin > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of > > Barry Leiba [barryleiba@computer.org] > > Sent: Thursday, October 20, 2011 12:05 PM > > To: OAuth WG > > Subject: Re: [OAUTH-WG] Rechartering > > > >> do we have the band width to work on all these items, as some are big > >> and some are fairly small and contained. May have to have some > >> prioritized list of where people think these fit. > > > > Yes, exactly. And one of the things we'd like to hear from all of you > > is what your priorities are... how you would prioritize the list. > > > > Barry, chair-like object > > _______________________________________________ > > 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 eran@hueniverse.com Thu Oct 20 10:58:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32E721F8BA6 for ; Thu, 20 Oct 2011 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79rNxcl50Xuj for ; Thu, 20 Oct 2011 10:58:21 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 471E721F8B74 for ; Thu, 20 Oct 2011 10:58:12 -0700 (PDT) Received: (qmail 20560 invoked from network); 20 Oct 2011 17:58:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Oct 2011 17:58:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 20 Oct 2011 10:58:05 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." , Barry Leiba , OAuth WG Date: Thu, 20 Oct 2011 10:57:56 -0700 Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMjuZUxOCzG5jjVkyNkG8gNxk6H5WFg2oAgAAl6AD//8HAeIAAFcWg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452631E9128@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.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 Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:58:21 -0000 This is not how the IETF, or for that matter, any standards body operates. = Working groups must be focused with a clearly defined purpose. For example,= JWT is a large enough effort and clear enough to form a working group toda= y - just go ahead and propose it. JWT has OAuth binding but it is not part = of OAuth. JWT to OAuth is what WebDAV is to HTTP. It is not enough to have critical mass for each document if there isn't a s= ignificant overlap in audience across each. Trying to do too much at the sa= me times creates list noise and really forces those with day jobs not dedic= ated to standards to leave the WG. Bundling efforts makes sense when they are small enough and can be finished= in a short period of time. Some of these documents can also live on the li= st but not become official WG documents. Take a look at HTTPbis - they have= a clear charter and set of documents but the list is discussing about a do= zen of other individual submissions, some from the editors and chair of the= WG, without any problem or heavy handed process. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Richer, Justin P. > Sent: Thursday, October 20, 2011 9:31 AM > To: Barry Leiba; OAuth WG > Subject: Re: [OAUTH-WG] Rechartering >=20 > I think it will be true that the whole working group won't be focusing on= all > documents at the same time, much in the same way that different subsets o= f > our current WG have focused on things like the security document or SAML > bindings. In this fashion, I believe we'll be able to pull expertise from > different sectors to produce a family of documents that live in an ecosys= tem > around OAuth. >=20 > For many of these documents, even though they're not directly OAuth > pieces (like JWT), but where else should they live? This may not be The W= ay > That IETF Does It (I'm honestly not sure), but in my opinion, as long as = each > document has a dedicated editor and at least some interaction/support wit= h > the group we can handle many of these smaller items. >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Barry > Leiba [barryleiba@computer.org] > Sent: Thursday, October 20, 2011 12:05 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering >=20 > > do we have the band width to work on all these items, as some are big > > and some are fairly small and contained. May have to have some > > prioritized list of where people think these fit. >=20 > Yes, exactly. And one of the things we'd like to hear from all of you is= what > your priorities are... how you would prioritize the list. >=20 > Barry, chair-like object > _______________________________________________ > 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 Michael.Jones@microsoft.com Thu Oct 20 11:38:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E91721F8BBE for ; Thu, 20 Oct 2011 11:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.115 X-Spam-Level: X-Spam-Status: No, score=-10.115 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhXvPBkmfAjB for ; Thu, 20 Oct 2011 11:38:49 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 7821C21F8BBA for ; Thu, 20 Oct 2011 11:38:49 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 11:38:49 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 11:38:48 -0700 From: Mike Jones To: William Mills , Julian Reschke Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 Thread-Index: AcyOuBvrce+R9JZJS5GdKjqOZuv3GwAekJcAAA6gPVD//5G+AIAAheYAgABEsFA= Date: Thu, 20 Oct 2011 18:38:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24D8F2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FCFA4.7050706@gmx.de> <1319124982.70621.YahooMailNeo@web31812.mail.mud.yahoo.com> In-Reply-To: <1319124982.70621.YahooMailNeo@web31812.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C24D8F2TK5EX14MBXC283r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:38:50 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C24D8F2TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That would make sense once issue 27 is incorporated into the core spec. -- Mike From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Thursday, October 20, 2011 8:36 AM To: Julian Reschke; Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 Shouldn't the scope definition here refer to the scope definition in the co= re spec? ________________________________ From: Julian Reschke > To: Mike Jones > Cc: "oauth@ietf.org" > Sent: Thursday, October 20, 2011 12:37 AM Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10 On 2011-10-20 09:14, Mike Jones wrote: > Can you recommend specific wording changes to address both issues? 2.2: "The entity-body is encoded using the "application/x-www-form-urlencod= ed" media type (Section 17.13.4 of [W3C.REC-html401-19991224]), applied to = the UTF-8 [RFC3629] encoded forms of the parameter values." Note 1: HTML4 ignores the encoding issue; this is a case where a reference = to HTML5 would actually help in practice. Note 2: I prefer refs in the form of [REC-html] or [HTML] rather than [W3C.= REC-html401-19991224]... 2.4: As stated earlier, just define all those parameters to be "token / quo= ted-string", and then constrain the values further separately, such as: "The value of the scope parameter, after potential quoted-string unquoting,= contains a set of single-SP delimited scope values." Each scope value is r= estricted to scope-val-char =3D %x21 / %x23-5B / %x5D-7E ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII " etc. Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435C24D8F2TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That would make sense onc= e issue 27 is incorporated into the core spec.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: William = Mills [mailto:wmills@yahoo-inc.com]
Sent: Thursday, October 20, 2011 8:36 AM
To: Julian Reschke; Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -= 10

 

Shouldn't the scope definition here = refer to the scope definition in the core spec?

 

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">From: Julian Reschk= e <julian.reschke@gmx.de>= ;
To: Mike Jones <Mi= chael.Jones@microsoft.com>
Cc: "oauth@ietf.org"= <oauth@ietf.org>
Sent: Thursday, October 20, 2011 12:37 AM
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -= 10

On 2011-10-20 09:14, Mike Jones wrote:
> Can you recommend specific wording changes to address both issues?


2.2: "The entity-body is encoded using the "application/x-www-for= m-urlencoded" media type (Section 17.13.4 of [W3C.REC-html401-19991224= ]), applied to the UTF-8 [RFC3629] encoded forms of the parameter values.&q= uot;

Note 1: HTML4 ignores the encoding issue; this is a case where a reference = to HTML5 would actually help in practice.

Note 2: I prefer refs in the form of [REC-html] or [HTML] rather than [W3C.= REC-html401-19991224]...


2.4: As stated earlier, just define all those parameters to be "token = / quoted-string", and then constrain the values further separately, su= ch as:

"The value of the scope parameter, after potential quoted-string unquo= ting, contains a set of single-SP delimited scope values." Each scope = value is restricted to

  scope-val-char  =3D %x21 / %x23-5B / %x5D-7E
  ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII
"

etc.

Best regards, Julian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B16804296739435C24D8F2TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Thu Oct 20 12:12:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6224F21F8AD9 for ; Thu, 20 Oct 2011 12:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDO9Mp73B+xT for ; Thu, 20 Oct 2011 12:12:03 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id AB89B21F8AD1 for ; Thu, 20 Oct 2011 12:12:03 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 12:11:43 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 12:11:43 -0700 From: Mike Jones To: Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMjuZXC/llWGbx10K50cRi4wxHDZWFlltg Date: Thu, 20 Oct 2011 19:11:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24DA48@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> In-Reply-To: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:12:04 -0000 Thanks, Hannes. Here's my prioritized list of new work: 1. JSON Web Token (JWT) 2. Simple Web Discovery (SWD) 3. JSON Web Token (JWT) Bearer Token Profile 4. Token Revocation My prioritized list of existing work items to complete after the core and b= earer specs are: A. Assertions Specification B. SAML Bearer Token Profile I am ambivalent about whether the working group takes on most of the other = work items. Responding to Eran's comments on SWD versus host-meta, these specs have sig= nificantly different goals and use substantially different mechanisms with = different privacy characteristics. Also, if you compare the relative compl= exity of the example at http://tools.ietf.org/html/draft-hammer-hostmeta-17= #appendix-A versus the example at http://tools.ietf.org/html/draft-jones-si= mple-web-discovery-01#section-1, you can see why SWD was chosen for use in = OpenID Connect to discover OAuth authorization and resource server endpoint= s. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Wednesday, October 19, 2011 10:09 PM To: OAuth WG Subject: [OAUTH-WG] Rechartering Hi all,=20 in preparation of the upcoming IETF meeting Barry and I would like to start= a re-chartering discussion. We both are currently attending the Internet = Identity Workshop and so we had the chance to solicit input from the partic= ipants. This should serve as a discussion starter.=20 Potential future OAuth charter items (in random order):=20 ---------------- 1) Dynamic Client Registration Protocol Available document:=20 http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ 2) Token Revocation Available document:=20 http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ 3) UMA=20 Available document:=20 http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ 4) Client Instance Extension Available document: http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt 5) XML Encoding Available document: http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt 6) JSON Web Token Available document: http://tools.ietf.org/html/draft-jones-json-web-token-05 7) JSON Web Token (JWT) Bearer Profile Available document:=20 http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 8) User Experience Extension Available document: http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 9) Request by Reference Available document:=20 http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 10) Simple Web Discovery Available document:=20 http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 ---------------- We have the following questions:=20 a) Are you interested in any of the above-listed items? (as a reviewer, co-= author, implementer, or someone who would like to deploy). It is also usefu= l to know if you think that we shouldn't work on a specific item.=20 b) Are there other items you would like to see the group working on? Note: In case your document is expired please re-submit it.=20 Ciao Hannes & Barry _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Hannes.Tschofenig@gmx.net Thu Oct 20 12:40:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BB41F0C5C for ; Thu, 20 Oct 2011 12:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.018 X-Spam-Level: X-Spam-Status: No, score=-102.018 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRskjcPMBHss for ; Thu, 20 Oct 2011 12:40:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B89C81F0C3D for ; Thu, 20 Oct 2011 12:40:21 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 19:40:18 -0000 Received: from unknown (EHLO [10.2.2.99]) [64.9.249.121] by mail.gmx.net (mp069) with SMTP; 20 Oct 2011 21:40:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18IQYAY6cQIPaQ6cQsIxRKdfeRkH0+DK6eDDTSr9H n1q/BZHc5cp021 From: Hannes Tschofenig Content-Type: multipart/alternative; boundary=Apple-Mail-1--617483507 Date: Thu, 20 Oct 2011 12:40:16 -0700 Message-Id: <4731B0D6-6898-4A41-9B03-25222E967A8C@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-assertions-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:40:24 -0000 --Apple-Mail-1--617483507 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 at the Internet Identity Workshop this week Barry and I had a chance to = meet Chuck, Mike, and Brian to talk about the content of = draft-ietf-oauth-assertions-00.=20 The specification provides an abstract description for two features, = namely=20 a) assertion usage as client credentials, and b) assertion usage as authorization grants Let me focus on (a) in this mail.=20 In attempting to judge the security features I noticed that I got the = impression that the description could be improved. Here is an attempt to = describe the features to see whether other members have the share my = understanding. =20 Model 1: Self-Crafted Assertion=20 In this model the client creates an assertion and signs it before = sending it to the Authorization Server in a client authentication = exchange. ({Assertion}Client means that the Assertion is signed with the = private key of the client.) Of course, the authorization server has to either know the symmetric key = or to be able to verify the digital signature (based on a shared trust = anchor, or by trusting the public key itself). +--------+ | | {Assertion}Client +---------------+ | |------------------->| Authorization | | Client | | Server | | |<-------------------| | | | +---------------+ +--------+ Model 2: STS issued Assertion In this model the client obtains an assertion from another entity; we = use the term STS here.=20 STS, as the issuer of the assertion, signs it. The client, on the other = hand, only passes the assertion forward to the authorization server.=20 +--------+ | | ,>| Secure | / | Token | ,' , | Server | / / | (STS) | ,' / +--------+ / ,' ,' / {Assertion}STS / v +--------+ | | {Assertion}STS +---------------+ | |------------------->| Authorization | | Client | | Server | | |<-------------------| | | | +---------------+ +--------+ Model 3: Co-Signed Assertion In this third model STS creates and signs an assertion before it sends = it to the client. The client instead of just passing it on to the AS it = also uses a secret to sign it. By doing this the client demonstrates = that it knows a secret (that is potentially associated with the = assertion itself).=20 +--------+ | | ,>| Secure | / | Token | ,' , | Server | / / | (STS) | ,' / +--------+ / ,' ,' / {Assertion}STS / v +--------+ | | {{Assertion}STS}Client +---------------+ | |------------------------>| Authorization | | Client | | Server | | |<------------------------| | | | +---------------+ +--------+ =46rom our discussions I understood that Model 1 & 2 are currently in = focus of the description but model 3 isn't. The security properties for = model 1 and model 2 are quite different: in model 2 the provided = security is not so much different from the client password mechanism = described in Section 2.3.1 of the OAuth core specification. The client = essentially sends a secret around. The secret here is the assertion. = Without proper protection an adversary who is able to see that assertion = is able perform a replay attack. The content of the assertion may allow = the replay window to be reduced though.=20 Let me know if your understanding is the same as mine. If so, then I = could propose some text on how to get the security claims in the = document fixed.=20 Ciao Hannes --Apple-Mail-1--617483507 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all, 

at the Internet Identity = Workshop this week Barry and I had a chance to meet Chuck, Mike, and = Brian to talk about the content of = draft-ietf-oauth-assertions-00. 

The specification provides = an abstract description for two features, namely 
a) assertion = usage as client credentials, and
b) assertion usage as authorization = grants

Let me focus on (a) in this mail. 

In = attempting to judge the security features I noticed that I got the = impression that the description could be improved. Here is an = attempt to describe the features to see whether other members have the = share my understanding.  

Model 1: Self-Crafted = Assertion 

In this model the client creates an assertion and = signs it before sending it to the Authorization Server in a = client authentication exchange. ({Assertion}Client means that the = Assertion is signed with the private key of the client.)
Of course, = the authorization server has to either know the symmetric key or to be = able to verify the digital signature (based on a shared trust = anchor, or by trusting the public key itself).

    =  +--------+
     |        | = {Assertion}Client  +---------------+
     | =        |------------------->| Authorization = |
     | Client |           =          |     Server   =  |
     |       =  |<-------------------|           =     |
     |        | =                   =  +---------------+
     +--------+

Model = 2: STS issued Assertion

In this model the client obtains an = assertion from another entity; we use the term STS here. 
STS, = as the issuer of the assertion, signs it. The client, on the other hand, = only passes the assertion forward to the authorization = server. 
                =  +--------+
              =    |        |
      =          ,>| Secure |
    =           /  |  Token |
  =           ,' , | Server |
    =        /  /  | (STS)  |
  =        ,'  /   +--------+
    =     /  ,'
      ,'  / =  {Assertion}STS
     /   v
  =  +--------+
   |        | =  {Assertion}STS    +---------------+
   | =        |------------------->| Authorization = |
   | Client |             =        |     Server   =  |
   |       =  |<-------------------|           =     |
   |        |   =                 =  +---------------+
   +--------+

Model 3: = Co-Signed Assertion

In this third model STS creates and signs an = assertion before it sends it to the client. The client instead of = just passing it on to the AS it also uses a secret to sign it. By = doing this the client demonstrates that it knows a secret (that is = potentially associated with the assertion itself). 

  =               =  +--------+
              =    |        |
      =          ,>| Secure |
    =           /  |  Token |
  =           ,' , | Server |
    =        /  /  | (STS)  |
  =        ,'  /   +--------+
    =     /  ,'
      ,'  / =  {Assertion}STS
     /   v
  =  +--------+
   |        | = {{Assertion}STS}Client  +---------------+
   |   =      |------------------------>| Authorization = |
   | Client |             =             |     Server   =  |
   |       =  |<------------------------|           =     |
   |        |   =                     =   +---------------+
   +--------+

=46rom our = discussions I understood that Model 1 & 2 are currently in focus of = the description but model 3 isn't. The security properties for = model 1 and model 2 are quite different: in model 2 the provided = security is not so much different from the client password = mechanism described in Section 2.3.1 of the OAuth core specification. = The client essentially sends a secret around. The secret here is = the assertion. Without proper protection an adversary who is = able to see that assertion is able perform a replay attack. The = content of the assertion may allow the replay window to be reduced = though. 

Let me know if your understanding is the same as = mine. If so, then I could propose some text on how to get the = security claims in the document = fixed. 

Ciao
Hannes




= --Apple-Mail-1--617483507-- From eran@hueniverse.com Thu Oct 20 12:42:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC49D21F89BA for ; Thu, 20 Oct 2011 12:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbOXQN7V0z6z for ; Thu, 20 Oct 2011 12:42:38 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 19AA221F88A0 for ; Thu, 20 Oct 2011 12:42:38 -0700 (PDT) Received: (qmail 19891 invoked from network); 20 Oct 2011 19:42:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Oct 2011 19:42:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 20 Oct 2011 12:42:36 -0700 From: Eran Hammer-Lahav To: Mike Jones , Hannes Tschofenig , OAuth WG Date: Thu, 20 Oct 2011 12:42:26 -0700 Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMjuZXC/llWGbx10K50cRi4wxHDZWFlltggAAMDYA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452631E9186@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C24DA48@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24DA48@TK5EX14MBXC283.redmond.corp.microsoft.com> 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] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:42:38 -0000 What possible rational is there for SWD to belong in the OAuth working grou= p and in the security area? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Thursday, October 20, 2011 12:12 PM > To: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] Rechartering >=20 > Thanks, Hannes. Here's my prioritized list of new work: >=20 > 1. JSON Web Token (JWT) > 2. Simple Web Discovery (SWD) > 3. JSON Web Token (JWT) Bearer Token Profile > 4. Token Revocation >=20 > My prioritized list of existing work items to complete after the core and > bearer specs are: >=20 > A. Assertions Specification > B. SAML Bearer Token Profile >=20 > I am ambivalent about whether the working group takes on most of the > other work items. >=20 > Responding to Eran's comments on SWD versus host-meta, these specs have > significantly different goals and use substantially different mechanisms = with > different privacy characteristics. Also, if you compare the relative com= plexity > of the example at http://tools.ietf.org/html/draft-hammer-hostmeta- > 17#appendix-A versus the example at http://tools.ietf.org/html/draft-jone= s- > simple-web-discovery-01#section-1, you can see why SWD was chosen for > use in OpenID Connect to discover OAuth authorization and resource server > endpoints. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Wednesday, October 19, 2011 10:09 PM > To: OAuth WG > Subject: [OAUTH-WG] Rechartering >=20 > Hi all, >=20 > in preparation of the upcoming IETF meeting Barry and I would like to sta= rt a > re-chartering discussion. We both are currently attending the Internet > Identity Workshop and so we had the chance to solicit input from the > participants. This should serve as a discussion starter. >=20 > Potential future OAuth charter items (in random order): >=20 > ---------------- >=20 > 1) Dynamic Client Registration Protocol >=20 > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >=20 > 2) Token Revocation >=20 > Available document: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >=20 > 3) UMA >=20 > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >=20 > 4) Client Instance Extension >=20 > Available document: > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >=20 > 5) XML Encoding >=20 > Available document: > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >=20 > 6) JSON Web Token >=20 > Available document: > http://tools.ietf.org/html/draft-jones-json-web-token-05 >=20 > 7) JSON Web Token (JWT) Bearer Profile >=20 > Available document: > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >=20 > 8) User Experience Extension >=20 > Available document: > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >=20 > 9) Request by Reference >=20 > Available document: > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >=20 > 10) Simple Web Discovery >=20 > Available document: > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >=20 > ---------------- >=20 > We have the following questions: >=20 > a) Are you interested in any of the above-listed items? (as a reviewer, c= o- > author, implementer, or someone who would like to deploy). It is also use= ful > to know if you think that we shouldn't work on a specific item. >=20 > b) Are there other items you would like to see the group working on? >=20 > Note: In case your document is expired please re-submit it. >=20 > Ciao > Hannes & Barry >=20 > _______________________________________________ > 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 Michael.Jones@microsoft.com Thu Oct 20 12:45:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFBB21F84DF for ; Thu, 20 Oct 2011 12:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onEqxqhetUG5 for ; Thu, 20 Oct 2011 12:45:42 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id D4A6C21F84C2 for ; Thu, 20 Oct 2011 12:45:42 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 12:45:42 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 12:45:42 -0700 From: Mike Jones To: Eran Hammer-Lahav , Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMjuZXC/llWGbx10K50cRi4wxHDZWFlltggAAMDYCAAAEiUA== Date: Thu, 20 Oct 2011 19:45:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24DBA0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C24DA48@TK5EX14MBXC283.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723452631E9186@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452631E9186@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:45:43 -0000 Because it's intended for (and used for) discovery of OAuth endpoints... -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Thursday, October 20, 2011 12:42 PM To: Mike Jones; Hannes Tschofenig; OAuth WG Subject: RE: [OAUTH-WG] Rechartering What possible rational is there for SWD to belong in the OAuth working grou= p and in the security area? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Mike Jones > Sent: Thursday, October 20, 2011 12:12 PM > To: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] Rechartering >=20 > Thanks, Hannes. Here's my prioritized list of new work: >=20 > 1. JSON Web Token (JWT) > 2. Simple Web Discovery (SWD) > 3. JSON Web Token (JWT) Bearer Token Profile 4. Token Revocation >=20 > My prioritized list of existing work items to complete after the core=20 > and bearer specs are: >=20 > A. Assertions Specification > B. SAML Bearer Token Profile >=20 > I am ambivalent about whether the working group takes on most of the=20 > other work items. >=20 > Responding to Eran's comments on SWD versus host-meta, these specs=20 > have significantly different goals and use substantially different=20 > mechanisms with different privacy characteristics. Also, if you=20 > compare the relative complexity of the example at=20 > http://tools.ietf.org/html/draft-hammer-hostmeta- > 17#appendix-A versus the example at=20 > http://tools.ietf.org/html/draft-jones- > simple-web-discovery-01#section-1, you can see why SWD was chosen for=20 > use in OpenID Connect to discover OAuth authorization and resource=20 > server endpoints. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Hannes Tschofenig > Sent: Wednesday, October 19, 2011 10:09 PM > To: OAuth WG > Subject: [OAUTH-WG] Rechartering >=20 > Hi all, >=20 > in preparation of the upcoming IETF meeting Barry and I would like to=20 > start a re-chartering discussion. We both are currently attending the=20 > Internet Identity Workshop and so we had the chance to solicit input=20 > from the participants. This should serve as a discussion starter. >=20 > Potential future OAuth charter items (in random order): >=20 > ---------------- >=20 > 1) Dynamic Client Registration Protocol >=20 > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >=20 > 2) Token Revocation >=20 > Available document: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >=20 > 3) UMA >=20 > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >=20 > 4) Client Instance Extension >=20 > Available document: > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >=20 > 5) XML Encoding >=20 > Available document: > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >=20 > 6) JSON Web Token >=20 > Available document: > http://tools.ietf.org/html/draft-jones-json-web-token-05 >=20 > 7) JSON Web Token (JWT) Bearer Profile >=20 > Available document: > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >=20 > 8) User Experience Extension >=20 > Available document: > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >=20 > 9) Request by Reference >=20 > Available document: > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >=20 > 10) Simple Web Discovery >=20 > Available document: > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >=20 > ---------------- >=20 > We have the following questions: >=20 > a) Are you interested in any of the above-listed items? (as a=20 > reviewer, co- author, implementer, or someone who would like to=20 > deploy). It is also useful to know if you think that we shouldn't work on= a specific item. >=20 > b) Are there other items you would like to see the group working on? >=20 > Note: In case your document is expired please re-submit it. >=20 > Ciao > Hannes & Barry >=20 > _______________________________________________ > 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 eran@hueniverse.com Thu Oct 20 12:52:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922D511E809C for ; Thu, 20 Oct 2011 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViOdvnOmGjqv for ; Thu, 20 Oct 2011 12:52:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A78B611E8083 for ; Thu, 20 Oct 2011 12:52:32 -0700 (PDT) Received: (qmail 32468 invoked from network); 20 Oct 2011 19:52:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Oct 2011 19:52:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 20 Oct 2011 12:52:15 -0700 From: Eran Hammer-Lahav To: Mike Jones , Hannes Tschofenig , OAuth WG Date: Thu, 20 Oct 2011 12:52:06 -0700 Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMjuZXC/llWGbx10K50cRi4wxHDZWFlltggAAMDYCAAAEiUIAAALEQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452631E918F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C24DA48@TK5EX14MBXC283.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723452631E9186@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739435C24DBA0@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24DBA0@TK5EX14MBXC283.redmond.corp.microsoft.com> 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] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:52:33 -0000 We also use HTTP, but we don't discuss it here. OAuth discovery, automation, cross-vendor interop, and dynamic client regis= tration are all part of one big topic. Before we can discuss any particular= drafts or proposals, we must first understand the problem space, collect u= se cases and requirements, and figure out what we are trying to solve. Then= we can decide if this is big enough for a new working group or not and cha= rter the work. Once the WG starts working on it, it can decide based on the= requirements which technologies to use and SWD can be one option. However, even if an OAuth-related effort decides to use SWD, it is still no= t the place to work on it. SWD is clearly an Application area work and shou= ld be discussed there. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, October 20, 2011 12:46 PM > To: Eran Hammer-Lahav; Hannes Tschofenig; OAuth WG > Subject: RE: [OAUTH-WG] Rechartering >=20 > Because it's intended for (and used for) discovery of OAuth endpoints... >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Thursday, October 20, 2011 12:42 PM > To: Mike Jones; Hannes Tschofenig; OAuth WG > Subject: RE: [OAUTH-WG] Rechartering >=20 > What possible rational is there for SWD to belong in the OAuth working gr= oup > and in the security area? >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Mike Jones > > Sent: Thursday, October 20, 2011 12:12 PM > > To: Hannes Tschofenig; OAuth WG > > Subject: Re: [OAUTH-WG] Rechartering > > > > Thanks, Hannes. Here's my prioritized list of new work: > > > > 1. JSON Web Token (JWT) > > 2. Simple Web Discovery (SWD) > > 3. JSON Web Token (JWT) Bearer Token Profile 4. Token Revocation > > > > My prioritized list of existing work items to complete after the core > > and bearer specs are: > > > > A. Assertions Specification > > B. SAML Bearer Token Profile > > > > I am ambivalent about whether the working group takes on most of the > > other work items. > > > > Responding to Eran's comments on SWD versus host-meta, these specs > > have significantly different goals and use substantially different > > mechanisms with different privacy characteristics. Also, if you > > compare the relative complexity of the example at > > http://tools.ietf.org/html/draft-hammer-hostmeta- > > 17#appendix-A versus the example at > > http://tools.ietf.org/html/draft-jones- > > simple-web-discovery-01#section-1, you can see why SWD was chosen for > > use in OpenID Connect to discover OAuth authorization and resource > > server endpoints. > > > > -- Mike > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Hannes Tschofenig > > Sent: Wednesday, October 19, 2011 10:09 PM > > To: OAuth WG > > Subject: [OAUTH-WG] Rechartering > > > > Hi all, > > > > in preparation of the upcoming IETF meeting Barry and I would like to > > start a re-chartering discussion. We both are currently attending the > > Internet Identity Workshop and so we had the chance to solicit input > > from the participants. This should serve as a discussion starter. > > > > Potential future OAuth charter items (in random order): > > > > ---------------- > > > > 1) Dynamic Client Registration Protocol > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > > > 2) Token Revocation > > > > Available document: > > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > > > 3) UMA > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > > > 4) Client Instance Extension > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > > > 5) XML Encoding > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > > > 6) JSON Web Token > > > > Available document: > > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > > > 7) JSON Web Token (JWT) Bearer Profile > > > > Available document: > > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > > > 8) User Experience Extension > > > > Available document: > > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > > > 9) Request by Reference > > > > Available document: > > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > > > 10) Simple Web Discovery > > > > Available document: > > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > > > ---------------- > > > > We have the following questions: > > > > a) Are you interested in any of the above-listed items? (as a > > reviewer, co- author, implementer, or someone who would like to > > deploy). It is also useful to know if you think that we shouldn't work = on a > specific item. > > > > b) Are there other items you would like to see the group working on? > > > > Note: In case your document is expired please re-submit it. > > > > Ciao > > Hannes & Barry > > > > _______________________________________________ > > 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 Michael.Jones@microsoft.com Thu Oct 20 12:57:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AC611E8083 for ; Thu, 20 Oct 2011 12:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.162 X-Spam-Level: X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEiP-fu2Btgq for ; Thu, 20 Oct 2011 12:57:54 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 650F611E807F for ; Thu, 20 Oct 2011 12:57:54 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 12:57:53 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 12:57:53 -0700 From: Mike Jones To: Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] draft-ietf-oauth-assertions-00 Thread-Index: AQHMj2AlcNKYt36f6UyBQEjMWfoUf5WFpfBA Date: Thu, 20 Oct 2011 19:57:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24DBE4@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4731B0D6-6898-4A41-9B03-25222E967A8C@gmx.net> In-Reply-To: <4731B0D6-6898-4A41-9B03-25222E967A8C@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C24DBE4TK5EX14MBXC283r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:57:55 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C24DBE4TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the useful write-up, Hannes. FYI, the Assertion ID specified in the Assertion Metamodel is used to prevent r= eplay attacks. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Thursday, October 20, 2011 12:40 PM To: OAuth WG Subject: [OAUTH-WG] draft-ietf-oauth-assertions-00 Hi all, at the Internet Identity Workshop this week Barry and I had a chance to mee= t Chuck, Mike, and Brian to talk about the content of draft-ietf-oauth-asse= rtions-00. The specification provides an abstract description for two features, namely a) assertion usage as client credentials, and b) assertion usage as authorization grants Let me focus on (a) in this mail. In attempting to judge the security features I noticed that I got the impre= ssion that the description could be improved. Here is an attempt to describ= e the features to see whether other members have the share my understanding= . Model 1: Self-Crafted Assertion In this model the client creates an assertion and signs it before sending i= t to the Authorization Server in a client authentication exchange. ({Assert= ion}Client means that the Assertion is signed with the private key of the c= lient.) Of course, the authorization server has to either know the symmetric key or= to be able to verify the digital signature (based on a shared trust anchor= , or by trusting the public key itself). +--------+ | | {Assertion}Client +---------------+ | |------------------->| Authorization | | Client | | Server | | |<-------------------| | | | +---------------+ +--------+ Model 2: STS issued Assertion In this model the client obtains an assertion from another entity; we use t= he term STS here. STS, as the issuer of the assertion, signs it. The client, on the other han= d, only passes the assertion forward to the authorization server. +--------+ | | ,>| Secure | / | Token | ,' , | Server | / / | (STS) | ,' / +--------+ / ,' ,' / {Assertion}STS / v +--------+ | | {Assertion}STS +---------------+ | |------------------->| Authorization | | Client | | Server | | |<-------------------| | | | +---------------+ +--------+ Model 3: Co-Signed Assertion In this third model STS creates and signs an assertion before it sends it t= o the client. The client instead of just passing it on to the AS it also us= es a secret to sign it. By doing this the client demonstrates that it knows= a secret (that is potentially associated with the assertion itself). +--------+ | | ,>| Secure | / | Token | ,' , | Server | / / | (STS) | ,' / +--------+ / ,' ,' / {Assertion}STS / v +--------+ | | {{Assertion}STS}Client +---------------+ | |------------------------>| Authorization | | Client | | Server | | |<------------------------| | | | +---------------+ +--------+ >From our discussions I understood that Model 1 & 2 are currently in focus o= f the description but model 3 isn't. The security properties for model 1 an= d model 2 are quite different: in model 2 the provided security is not so m= uch different from the client password mechanism described in Section 2.3.1= of the OAuth core specification. The client essentially sends a secret aro= und. The secret here is the assertion. Without proper protection an adversa= ry who is able to see that assertion is able perform a replay attack. The c= ontent of the assertion may allow the replay window to be reduced though. Let me know if your understanding is the same as mine. If so, then I could = propose some text on how to get the security claims in the document fixed. Ciao Hannes --_000_4E1F6AAD24975D4BA5B16804296739435C24DBE4TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the useful wri= te-up, Hannes.

 <= /p>

FYI, the Assertion ID specified in the Assertion Metamodel is used to prevent replay attacks.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, October 20, 2011 12:40 PM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-assertions-00=

 

Hi all, 

at the Internet Identity Workshop this week Barry and I had a chance to mee= t Chuck, Mike, and Brian to talk about the content of draft-ietf-oauth= -assertions-00. 

The specification provides an abstract description for two features, namely=  
a) assertion usage as client credentials, and
b) assertion usage as authorization grants

Let me focus on (a) in this mail. 

In attempting to judge the security features I noticed that I got the impre= ssion that the description could be improved. Here is an attempt to de= scribe the features to see whether other members have the share my understa= nding.  

Model 1: Self-Crafted Assertion 

In this model the client creates an assertion and signs it before sending i= t to the Authorization Server in a client authentication exchange. ({A= ssertion}Client means that the Assertion is signed with the private key of = the client.)
Of course, the authorization server has to either know the symmetric key or= to be able to verify the digital signature (based on a shared trust a= nchor, or by trusting the public key itself).

     +--------+
     |        | {Assertion}Client  = +---------------+
     |        |------------------->| = Authorization |
     | Client |             &n= bsp;      |     Server    |
     |        |<-------------------| =               |
     |        |       &nb= sp;            +---------------+
     +--------+

Model 2: STS issued Assertion

In this model the client obtains an assertion from another entity; we use t= he term STS here. 
STS, as the issuer of the assertion, signs it. The client, on the other han= d, only passes the assertion forward to the authorization server. = ;
                 +--------= +
                 |   &nbs= p;    |
               ,>| Secure |
              /  |  Token |             ,' , | Server |
           /  /  | (STS)  |          ,'  /   +--------+
        /  ,'
      ,'  /  {Assertion}STS
     /   v
   +--------+
   |        |  {Assertion}STS   &nb= sp;+---------------+
   |        |------------------->| Authori= zation |
   | Client |               &n= bsp;    |     Server    |
   |        |<-------------------|   =             |
   |        |         &nb= sp;          +---------------+
   +--------+

Model 3: Co-Signed Assertion

In this third model STS creates and signs an assertion before it sends it t= o the client. The client instead of just passing it on to the AS it al= so uses a secret to sign it. By doing this the client demonstrates that it = knows a secret (that is potentially associated with the assertion itself). 

                 +--------= +
                 |   &nbs= p;    |
               ,>| Secure |
              /  |  Token |             ,' , | Server |
           /  /  | (STS)  |          ,'  /   +--------+
        /  ,'
      ,'  /  {Assertion}STS
     /   v
   +--------+
   |        | {{Assertion}STS}Client  &#= 43;---------------+
   |        |------------------------>| Au= thorization |
   | Client |               &n= bsp;         |     Server    |
   |        |<------------------------| &n= bsp;             |
   |        |         &nb= sp;               +---------------&#= 43;
   +--------+

>From our discussions I understood that Model 1 & 2 are currently in foc= us of the description but model 3 isn't. The security properties for m= odel 1 and model 2 are quite different: in model 2 the provided security is= not so much different from the client password mechanism described in Section 2.3.1 of the OAuth core specification. The = client essentially sends a secret around. The secret here is the asser= tion. Without proper protection an adversary who is able to see that a= ssertion is able perform a replay attack. The content of the assertion may allow the replay window to be reduce= d though. 

Let me know if your understanding is the same as mine. If so, then I could = propose some text on how to get the security claims in the document fi= xed. 

Ciao
Hannes



--_000_4E1F6AAD24975D4BA5B16804296739435C24DBE4TK5EX14MBXC283r_-- From hannes.tschofenig@gmx.net Thu Oct 20 13:25:27 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEDF11E8090 for ; Thu, 20 Oct 2011 13:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqbNEBIVoXhQ for ; Thu, 20 Oct 2011 13:25:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4ADB211E807F for ; Thu, 20 Oct 2011 13:25:26 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 20:25:24 -0000 Received: from unknown (EHLO [10.2.2.99]) [64.9.249.121] by mail.gmx.net (mp013) with SMTP; 20 Oct 2011 22:25:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18dUhs7I3Ydbu0v7l8UMUgKPmqUxmCow2rCtXAOfS pawhv6j+xqoQaf Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452631E9186@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 20 Oct 2011 13:25:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C24DA48@TK5EX14MBXC283.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723452631E9186@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:25:27 -0000 There are various factors that play a role here, such as=20 * where work first got proposed, * where the expertise is,=20 * where the main audience is,=20 * etc.=20 We will definitely talk to our AD but it is already a good start to hear = whether there is interest in a specific item in general. If there is no = interest then any other question goes away pretty quickly. =20 Ciao Hannes On Oct 20, 2011, at 12:42 PM, Eran Hammer-Lahav wrote: > What possible rational is there for SWD to belong in the OAuth working = group and in the security area? >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Mike Jones >> Sent: Thursday, October 20, 2011 12:12 PM >> To: Hannes Tschofenig; OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >>=20 >> Thanks, Hannes. Here's my prioritized list of new work: >>=20 >> 1. JSON Web Token (JWT) >> 2. Simple Web Discovery (SWD) >> 3. JSON Web Token (JWT) Bearer Token Profile >> 4. Token Revocation >>=20 >> My prioritized list of existing work items to complete after the core = and >> bearer specs are: >>=20 >> A. Assertions Specification >> B. SAML Bearer Token Profile >>=20 >> I am ambivalent about whether the working group takes on most of the >> other work items. >>=20 >> Responding to Eran's comments on SWD versus host-meta, these specs = have >> significantly different goals and use substantially different = mechanisms with >> different privacy characteristics. Also, if you compare the relative = complexity >> of the example at http://tools.ietf.org/html/draft-hammer-hostmeta- >> 17#appendix-A versus the example at = http://tools.ietf.org/html/draft-jones- >> simple-web-discovery-01#section-1, you can see why SWD was chosen for >> use in OpenID Connect to discover OAuth authorization and resource = server >> endpoints. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Hannes Tschofenig >> Sent: Wednesday, October 19, 2011 10:09 PM >> To: OAuth WG >> Subject: [OAUTH-WG] Rechartering >>=20 >> Hi all, >>=20 >> in preparation of the upcoming IETF meeting Barry and I would like to = start a >> re-chartering discussion. We both are currently attending the = Internet >> Identity Workshop and so we had the chance to solicit input from the >> participants. This should serve as a discussion starter. >>=20 >> Potential future OAuth charter items (in random order): >>=20 >> ---------------- >>=20 >> 1) Dynamic Client Registration Protocol >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>=20 >> 2) Token Revocation >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>=20 >> 3) UMA >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>=20 >> 4) Client Instance Extension >>=20 >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>=20 >> 5) XML Encoding >>=20 >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>=20 >> 6) JSON Web Token >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>=20 >> 7) JSON Web Token (JWT) Bearer Profile >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>=20 >> 8) User Experience Extension >>=20 >> Available document: >> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>=20 >> 9) Request by Reference >>=20 >> Available document: >> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>=20 >> 10) Simple Web Discovery >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>=20 >> ---------------- >>=20 >> We have the following questions: >>=20 >> a) Are you interested in any of the above-listed items? (as a = reviewer, co- >> author, implementer, or someone who would like to deploy). It is also = useful >> to know if you think that we shouldn't work on a specific item. >>=20 >> b) Are there other items you would like to see the group working on? >>=20 >> Note: In case your document is expired please re-submit it. >>=20 >> Ciao >> Hannes & Barry >>=20 >> _______________________________________________ >> 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 Hannes.Tschofenig@gmx.net Thu Oct 20 13:51:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D5C21F85D1 for ; Thu, 20 Oct 2011 13:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3iG4eeKlesk for ; Thu, 20 Oct 2011 13:51:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 52B5A21F86FF for ; Thu, 20 Oct 2011 13:51:39 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2011 20:51:34 -0000 Received: from unknown (EHLO [10.2.2.99]) [64.9.249.121] by mail.gmx.net (mp072) with SMTP; 20 Oct 2011 22:51:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX188LeBdLcQ8cZwgm+Q43SEarWr0l4F2buHRhrGLbm 38sWSUu9oeedh3 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C24DBE4@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 20 Oct 2011 13:51:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71635468-71D7-4A50-9201-264EA23956F6@gmx.net> References: <4731B0D6-6898-4A41-9B03-25222E967A8C@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C24DBE4@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:51:40 -0000 > FYI, the Assertion ID specified in the Assertion Metamodel is used to = prevent replay attacks. There are various ways to prevent replays and having unique identifiers = is one possibility. Timestamps are another one.=20 In model 2 for it to work the client would have to request a new = assertion from the STS every time before it presents something to the = AS.=20 While this is theoretically possible I doubt it will be done in = practice. Consequently, there will be a certain time window for replay = attacks. Depending on the application requirements that may well be = fine.=20 In model 1 it is very likely that one would do this. In that case, = however, the security is similar (but not the same) as the HMAC based = spec (when shared secrets and HMACs are used) with the only difference = that the HMAC spec is far less verbose than constructing an assertion = with self-constructed info.=20 Ciao Hannes > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Hannes Tschofenig > Sent: Thursday, October 20, 2011 12:40 PM > To: OAuth WG > Subject: [OAUTH-WG] draft-ietf-oauth-assertions-00 > =20 > Hi all,=20 >=20 > at the Internet Identity Workshop this week Barry and I had a chance = to meet Chuck, Mike, and Brian to talk about the content of = draft-ietf-oauth-assertions-00.=20 >=20 > The specification provides an abstract description for two features, = namely=20 > a) assertion usage as client credentials, and > b) assertion usage as authorization grants >=20 > Let me focus on (a) in this mail.=20 >=20 > In attempting to judge the security features I noticed that I got the = impression that the description could be improved. Here is an attempt to = describe the features to see whether other members have the share my = understanding. =20 >=20 > Model 1: Self-Crafted Assertion=20 >=20 > In this model the client creates an assertion and signs it before = sending it to the Authorization Server in a client authentication = exchange. ({Assertion}Client means that the Assertion is signed with the = private key of the client.) > Of course, the authorization server has to either know the symmetric = key or to be able to verify the digital signature (based on a shared = trust anchor, or by trusting the public key itself). >=20 > +--------+ > | | {Assertion}Client +---------------+ > | |------------------->| Authorization | > | Client | | Server | > | |<-------------------| | > | | +---------------+ > +--------+ >=20 > Model 2: STS issued Assertion >=20 > In this model the client obtains an assertion from another entity; we = use the term STS here.=20 > STS, as the issuer of the assertion, signs it. The client, on the = other hand, only passes the assertion forward to the authorization = server.=20 > +--------+ > | | > ,>| Secure | > / | Token | > ,' , | Server | > / / | (STS) | > ,' / +--------+ > / ,' > ,' / {Assertion}STS > / v > +--------+ > | | {Assertion}STS +---------------+ > | |------------------->| Authorization | > | Client | | Server | > | |<-------------------| | > | | +---------------+ > +--------+ >=20 > Model 3: Co-Signed Assertion >=20 > In this third model STS creates and signs an assertion before it sends = it to the client. The client instead of just passing it on to the AS it = also uses a secret to sign it. By doing this the client demonstrates = that it knows a secret (that is potentially associated with the = assertion itself).=20 >=20 > +--------+ > | | > ,>| Secure | > / | Token | > ,' , | Server | > / / | (STS) | > ,' / +--------+ > / ,' > ,' / {Assertion}STS > / v > +--------+ > | | {{Assertion}STS}Client +---------------+ > | |------------------------>| Authorization | > | Client | | Server | > | |<------------------------| | > | | +---------------+ > +--------+ >=20 > =46rom our discussions I understood that Model 1 & 2 are currently in = focus of the description but model 3 isn't. The security properties for = model 1 and model 2 are quite different: in model 2 the provided = security is not so much different from the client password mechanism = described in Section 2.3.1 of the OAuth core specification. The client = essentially sends a secret around. The secret here is the assertion. = Without proper protection an adversary who is able to see that assertion = is able perform a replay attack. The content of the assertion may allow = the replay window to be reduced though.=20 >=20 > Let me know if your understanding is the same as mine. If so, then I = could propose some text on how to get the security claims in the = document fixed.=20 >=20 > Ciao > Hannes >=20 >=20 >=20 >=20 From igor.faynberg@alcatel-lucent.com Thu Oct 20 14:28:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6420211E809D for ; Thu, 20 Oct 2011 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLGh2RCTgJ5u for ; Thu, 20 Oct 2011 14:28:45 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C3F0111E809C for ; Thu, 20 Oct 2011 14:28:45 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p9KLSjEO018504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Oct 2011 16:28:45 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9KLSiTS026458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Oct 2011 16:28:45 -0500 Received: from [135.244.224.238] (faynberg.lra.lucent.com [135.244.224.238] (may be forged)) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9KLShCR026274; Thu, 20 Oct 2011 16:28:44 -0500 (CDT) Message-ID: <4EA0928B.5030601@alcatel-lucent.com> Date: Thu, 20 Oct 2011 17:28:43 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 21:28:46 -0000 I agree. To this end, are we going to have a rechartering discussion? I would very much support that. We have a number of things waiting, discovery being one of them. Igor On 10/20/2011 1:18 PM, Hannes Tschofenig wrote: > the past that the JSON signature& encryption work would go into JOES (earlier WOES) and the home for JWT is the OAuth From torsten@lodderstedt.net Thu Oct 20 15:56:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C11221F8ACE for ; Thu, 20 Oct 2011 15:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OvUPZpPaHbh for ; Thu, 20 Oct 2011 15:56:39 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF8221F8ACA for ; Thu, 20 Oct 2011 15:56:38 -0700 (PDT) Received: from [80.67.16.114] (helo=webmailfront01.ispgateway.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RH1XR-00049w-2V; Fri, 21 Oct 2011 00:56:37 +0200 Received: from proxy2.t-online.net (proxy2.t-online.net [195.243.113.251]) by webmail.df.eu (Horde Framework) with HTTP; Fri, 21 Oct 2011 00:56:37 +0200 Date: Fri, 21 Oct 2011 00:56:37 +0200 Message-ID: <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> From: Torsten Lodderstedt To: Hannes Tschofenig References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> In-Reply-To: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> User-Agent: Internet Messaging Program (IMP) H4 (5.0.14) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 22:56:40 -0000 Hi all, my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes. We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers. As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment. If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal. Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process. I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution. If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API. Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *): - Revocation (low hanging fruit since I-D is ready and implemented in some places) - Resource server notion* - Multiple access tokens* - Dynamic client registration 1) Dynamic Client Registration Protocol 4) Client Instance Extension - Discovery (10) Simple Web Discovery, probably other specs as well - (6) JSON Web Token - (7) JSON Web Token (JWT) Bearer Profile - 8) User Experience Extension - Device flow - 9) Request by Reference (depending resource server notion and multiple access tokens) regards, Torsten. Zitat von Hannes Tschofenig : > Hi all, > > in preparation of the upcoming IETF meeting Barry and I would like > to start a re-chartering discussion. We both are currently > attending the Internet Identity Workshop and so we had the chance to > solicit input from the participants. This should serve as a > discussion starter. > > Potential future OAuth charter items (in random order): > > ---------------- > > 1) Dynamic Client Registration Protocol > > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > 2) Token Revocation > > Available document: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > 3) UMA > > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > 4) Client Instance Extension > > Available document: > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > 5) XML Encoding > > Available document: > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > 6) JSON Web Token > > Available document: > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > 7) JSON Web Token (JWT) Bearer Profile > > Available document: > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > 8) User Experience Extension > > Available document: > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > 9) Request by Reference > > Available document: > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > 10) Simple Web Discovery > > Available document: > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > ---------------- > > We have the following questions: > > a) Are you interested in any of the above-listed items? (as a > reviewer, co-author, implementer, or someone who would like to > deploy). It is also useful to know if you think that we shouldn't > work on a specific item. > > b) Are there other items you would like to see the group working on? > > Note: In case your document is expired please re-submit it. > > Ciao > Hannes & Barry > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tadaforest@gmail.com Thu Oct 20 18:06:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D611E8099 for ; Thu, 20 Oct 2011 18:06:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gnn8BELyrnt for ; Thu, 20 Oct 2011 18:06:03 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6F11E8091 for ; Thu, 20 Oct 2011 18:06:03 -0700 (PDT) Received: by bkas6 with SMTP id s6so4789636bka.31 for ; Thu, 20 Oct 2011 18:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=PIOCFzaA4xNb6Ovd1WFWfE7J2qvZYLbLwbdrwnFo7ts=; b=obuwZfY/SlkNQQWMvuaqVqY8lzhaSgjNWsB+q3tUZOEHpYs0o7vSpDIXzJ4200qHoH Nd4BYq7Paj5onGpriNHXlsMOR1bIMFfizrks+xg5/OPfoK/MS5+HVH9Wq9mY9ou6Ojor LviCCmZWo6W9zoaKx9KaoDLFfRXnPJLAsT6ug= MIME-Version: 1.0 Received: by 10.204.148.68 with SMTP id o4mr9489889bkv.21.1319159161948; Thu, 20 Oct 2011 18:06:01 -0700 (PDT) Received: by 10.204.49.21 with HTTP; Thu, 20 Oct 2011 18:06:01 -0700 (PDT) Date: Thu, 20 Oct 2011 18:06:01 -0700 Message-ID: From: Forest To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Client credentials for native applications: seeking clarification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 01:10:21 -0000 Hi there. I've been considering OAuth 2 and its "client credentials" grant type for use with applications that run on televisions and other consumer devices. It is appealing mainly because it requires no built-in web browser and no cumbersome data entry for the user. (Similar to the Netflix device registration procedure.) However, I think I've run into a snag. Section 4.4 of draft-ietf-oauth-v2-22 says: "The client credentials grant type MUST only be used by confidential clients." Since Section 2.1 defines confidential clients as distinct from "clients executing on the resource owner's device", I have the impression that this forbids pretty much any device in the user's possession from using client credentials. (Except perhaps the rare gadget that embeds encrypted storage and physical safeguards against key discovery.) I suppose this would mean OAuth 2 is unsuitable for the task at hand. However, Section 10.1 says: "The authorization server MAY issue a client password or other credentials for a specific installation of a native application client on a specific device." This seems to contradict Section 4.4, although if I understand it correctly, it would allow me to use client credentials as I had hoped without violating the spec. That's encouraging. Maybe I can use OAuth 2 after all, so long as each installed instance of my application gets its own credentials. So, I could use some clarification on a few points: 1. Is that quote in Section 10.1 meant to be an exception to the one in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for the exception and to make it easier for OAuth 2 implementors to discover. 2. If it is not intended as an exception, meaning that apps running on consumer devices are not to be issued client credentials, what is the recommended alternative? Section 1.3.3 suggests resource owner password credentials when "other authorization grant types are not available", and using a "long-lived access token or refresh token". I suppose this approach would enable OAuth on devices that have no web browser, though it would create a usability problem by requiring users to enter their credentials using awkward, frustrating input devices (like 5-button remote controls). Perhaps more importantly, it begs the question of how storing a long-lived token is any more secure than storing client credentials. After all, both could grant access, both could be revoked, and both could be exposed just as easily. Which brings me to my third question: 3. From whom is a "confidential" client expected to keep its credentials secret? From the resource owner? (I suppose this would make sense for a server-side application trusted by many users, but it makes little sense for a consumer device, since a user is unlikely to give out his own device's credentials and could more easily give out his own password.) From other applications running on the same device? (This makes sense, but devices with sandboxed per-application storage would seem to warrant an exception from the "clients executing on the resource owner's device" generalization in Section 2.1.) From the world at large? (If this is the only level of confidentiality then I would think "clients executing on the resource owner's device" would easily qualify as confidential.) Thanks, all. I look forward to a better understanding of what is intended here. From torsten@lodderstedt.net Fri Oct 21 01:41:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C767621F8B19 for ; Fri, 21 Oct 2011 01:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsVS6YSM4hLI for ; Fri, 21 Oct 2011 01:41:31 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by ietfa.amsl.com (Postfix) with ESMTP id 659DE21F8B12 for ; Fri, 21 Oct 2011 01:41:30 -0700 (PDT) Received: from [80.187.111.55] (helo=nothing) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1RHAfC-0001qa-4V; Fri, 21 Oct 2011 10:41:29 +0200 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----5TRU9CL84I9VMTTB1PTMLBELQF48SP" From: Torsten Lodderstedt Date: Fri, 21 Oct 2011 10:38:40 +0200 To: Forest ,oauth@ietf.org Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] =?utf-8?q?Client_credentials_for_native_applications?= =?utf-8?q?=3A_seeking=09clarification?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 08:41:32 -0000 ------5TRU9CL84I9VMTTB1PTMLBELQF48SP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, there is no contradiction. The subtle difference lays in the word "instance". Using secrets for a software package (and all of its installations) is useless and therefore not allowed. If you are able to issue a distinct id/secret pair to every installation of your app, this is fine. For a the complete rationale pls. take a look into http://tools.ietf.org/html/draft-lodderstedt-oauth-security/. The question is whether you really want to authenticate the client or the user. For users, resource owner password is an option. I agree with you that the user experience is bad. You may consider to use another device (pc, smartphone) to perform the authorization flow. You may take a look onto the device flow proposal. Alternatively, you could utilize the code flow on the secondary device and ask the user to enter the code on the TV Set. regards, Torsten. Forest schrieb: Hi there. I've been considering OAuth 2 and its "client credentials" grant type for use with applications that run on televisions and other consumer devices. It is appealing mainly because it requires no built-in web browser and no cumbersome data entry for the user. (Similar to the Netflix device registration procedure.) However, I think I've run into a snag. Section 4.4 of draft-ietf-oauth-v2-22 says: "The client credentials grant type MUST only be used by confidential clients." Since Section 2.1 defines confidential clients as distinct from "clients executing on the resource owner's device", I have the impression that this forbids pretty much any device in the user's possession from using client credentials. (Except perhaps the rare gadget that embeds encrypted storage and physical safeguards against key discovery.) I suppose this would mean OAuth 2 is unsuitable for the task at hand. However, Section 10.1 says: "The authorization server MAY issue a client password or other credentials for a specific installation of a native application client on a specific device." This seems to contradict Section 4.4, although if I understand it correctly, it would allow me to use client credentials as I had hoped without violating the spec. That's encouraging. Maybe I can use OAuth 2 after all, so long as each installed instance of my application gets its own credentials. So, I could use some clarification on a few points: 1. Is that quote in Section 10.1 meant to be an exception to the one in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for the exception and to make it easier for OAuth 2 implementors to discover. 2. If it is not intended as an exception, meaning that apps running on consumer devices are not to be issued client credentials, what is the recommended alternative? Section 1.3.3 suggests resource owner password credentials when "other authorization grant types are not available", and using a "long-lived access token or refresh token". I suppose this approach would enable OAuth on devices that have no web browser, though it would create a usability problem by requiring users to enter their credentials using awkward, frustrating input devices (like 5-button remote controls). Perhaps more importantly, it begs the question of how storing a long-lived token is any more secure than storing client credentials. After all, both could grant access, both could be revoked, and both could be exposed just as easily. Which brings me to my third question: 3. From whom is a "confidential" client expected to keep its credentials secret? From the resource owner? (I suppose this would make sense for a server-side application trusted by many users, but it makes little sense for a consumer device, since a user is unlikely to give out his own device's credentials and could more easily give out his own password.) From other applications running on the same device? (This makes sense, but devices with sandboxed per-application storage would seem to warrant an exception from the "clients executing on the resource owner's device" generalization in Section 2.1.) From the world at large? (If this is the only level of confidentiality then I would think "clients executing on the resource owner's device" would easily qualify as confidential.) Thanks, all. I look forward to a better understanding of what is intended here. _____________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------5TRU9CL84I9VMTTB1PTMLBELQF48SP Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

there is no contradiction. The subtle difference lays in the word "instance". Using secrets for a software package (and all of its installations) is useless and therefore not allowed. If you are able to issue a distinct id/secret pair to every installation of your app, this is fine.

For a the complete rationale pls. take a look into http://tools.ietf.org/html/draft-lodderstedt-oauth-security/.

The question is whether you really want to authenticate the client or the user. For users, resource owner password is an option. I agree with you that the user experience is bad. You may consider to use another device (pc, smartphone) to perform the authorization flow. You may take a look onto the device flow proposal. Alternatively, you could utilize the code flow on the secondary device and ask the user to enter the code on the TV Set.

regards,
Torsten.




Forest <tadaforest@gmail.com> schrieb:
Hi there.

I've been considering OAuth 2 and its "client credentials" grant type
for use with applications that run on televisions and other consumer
devices.  It is appealing mainly because it requires no built-in web
browser and no cumbersome data entry for the user. (Similar to the
Netflix device registration procedure.)  However, I think I've run
into a snag.

Section 4.4 of draft-ietf-oauth-v2-22 says:
"The client credentials grant type MUST only be used by confidential clients."

Since Section 2.1 defines confidential clients as distinct from
"clients executing on the resource owner's device", I have the
impression that this forbids pretty much any device in the user's
possession from using client credentials.  (Except perhaps the rare
gadget that embeds encrypted storage and physical safeguards against
ke
 y
discovery.)  I suppose this would mean OAuth 2 is unsuitable for
the task at hand.

However, Section 10.1 says:
"The authorization server MAY issue a client password or other
credentials for a specific installation of a native application client
on a specific device."

This seems to contradict Section 4.4, although if I understand it
correctly, it would allow me to use client credentials as I had hoped
without violating the spec.  That's encouraging.  Maybe I can use
OAuth 2 after all, so long as each installed instance of my
application gets its own credentials.

So, I could use some clarification on a few points:

1. Is that quote in Section 10.1 meant to be an exception to the one
in Section 4.4?  If so, I would suggest rephrasing 4.4 to allow for
the exception and to make it easier for OAuth 2 implementors to
discover.

2. If it is not intended as an exception, meaning
  that
apps running on
consumer devices are not to be issued client credentials, what is the
recommended alternative?  Section 1.3.3 suggests resource owner
password credentials when "other authorization grant types are not
available", and using a "long-lived access token or refresh token".  I
suppose this approach would enable OAuth on devices that have no web
browser, though it would create a usability problem by requiring users
to enter their credentials using awkward, frustrating input devices
(like 5-button remote controls).  Perhaps more importantly, it begs
the question of how storing a long-lived token is any more secure than
storing client credentials.  After all, both could grant access, both
could be revoked, and both could be exposed just as easily.  Which
brings me to my third question:

3. From whom is a "confidential" client expected to keep its
credentials secret?  From the resource owner?  (I
suppose this would
make sense for a server-side application trusted by many users, but it
makes little sense for a consumer device, since a user is unlikely to
give out his own device's credentials and could more easily give out
his own password.)  From other applications running on the same
device?  (This makes sense, but devices with sandboxed per-application
storage would seem to warrant an exception from the "clients executing
on the resource owner's device" generalization in Section 2.1.)  From
the world at large?  (If this is the only level of confidentiality
then I would think "clients executing on the resource owner's device"
would easily qualify as confidential.)

Thanks, all.  I look forward to a better understanding of what is intended here.

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------5TRU9CL84I9VMTTB1PTMLBELQF48SP-- From hannes.tschofenig@gmx.net Fri Oct 21 07:00:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5A021F8C55 for ; Fri, 21 Oct 2011 07:00:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9GVLnvgUG2O for ; Fri, 21 Oct 2011 07:00:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C70A521F8C50 for ; Fri, 21 Oct 2011 07:00:11 -0700 (PDT) Received: (qmail invoked by alias); 21 Oct 2011 14:00:08 -0000 Received: from unknown (EHLO [10.2.227.250]) [12.229.246.2] by mail.gmx.net (mp006) with SMTP; 21 Oct 2011 16:00:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+6XEta52262EzzkSZBvLGEw9e96FQctnmEWa6lJ/ Xd/8L6dxsH+vWm From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2011 07:00:05 -0700 Message-Id: <9C2CB8C7-39F5-45A1-BDF4-1DE8BCB36F78@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Document Shepherd Write-Up for draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:00:13 -0000 While Mike is working on a small update for draft-ietf-oauth-v2-bearer = (to be re-submitted soon) I have been compiling the document shepherd = write-up.=20 This writeup will be attached to the draft when I send it to the IESG.=20= I thought I should share it with you just in case you have some = additional remarks. ---------- Document Shepherd Write-Up for (to-be-submitted) = draft-ietf-oauth-v2-bearer-11 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 The document shepherd is Hannes Tschofenig. I have personally reviewed = the=20 document and I think it is ready for going forward.=20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 The document received a number of reviews from the working group.=20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 The document was reviewed by Julian Reschke for HTTP related content.=20 Changes to the document have been made in response to his review.=20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20= has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 I have no concerns regarding this document.=20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 =20 There solid consensus behind this document.=20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20= discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 =20 Nobody had shown extreme discontent.=20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts = Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20= not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 I have verified the document. The RFC 2119 boilerplate warning is = incorrect.=20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 The references are split into normative and informative references. =20 There is one downref to RFC 2818.=20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 I have reviewed the IANA consideration section.=20 The documents adds new values into existing registry.=20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 The ABNF in the document was verified with=20 http://trac.tools.ietf.org/wg/httpbis/trac/browser/abnfparser/bap (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to granted resources (without demonstrating possession of a cryptographic key). To prevent misuse, the bearer token MUST be protected from disclosure in storage and in transport. =20 Working Group Summary=20 The working group decided to develop two types of mechanisms for=20 a client to access a protected resource. The second specification=20 is being worked on with draft-ietf-oauth-v2-http-mac-00. The=20 two specifications offer different security properties to allow deployments to meet their specific needs.=20 =20 Document Quality=20 =20 This specification is implemented, deployed and used by Microsoft=20 Access Control Service (ACS), Google Apps, Facebook Connect and the=20= Graph API, Salesforce, Mitre, and many others.=20 =20 Source code is available as well. For example=20 http://static.springsource.org/spring-security/oauth/ http://incubator.apache.org/projects/amber.html https://github.com/nov/rack-oauth2 + many more, including those listed at=20 https://github.com/teohm/teohm.github.com/wiki/OAuth=20 =20= From tadaforest@gmail.com Fri Oct 21 13:14:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5411211E80BF for ; Fri, 21 Oct 2011 13:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAuk6w0I33ri for ; Fri, 21 Oct 2011 13:14:51 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 346F411E809B for ; Fri, 21 Oct 2011 13:14:51 -0700 (PDT) Received: by bkas6 with SMTP id s6so6094448bka.31 for ; Fri, 21 Oct 2011 13:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jFV/aVsYhdPLTM5UkTwLHdTXzRE/cpHYA2AJzy8E1GM=; b=bN/rOddG7rllzB4+/2ruHA4gS0ZCM+S6saKsLLxpvDN47qdzsmOj++5dFCt4YMczMY zuZYy3E0jPXQEVqlNOUA0dc+0LQRgD6BeOicNmzoBpEcIAV2BsC9O16xi0XipEETWZyC UQuYbmQtk2qoG9K4KiFhz/s+bmyushZwdbbwk= MIME-Version: 1.0 Received: by 10.204.152.201 with SMTP id h9mr11461314bkw.99.1319228090290; Fri, 21 Oct 2011 13:14:50 -0700 (PDT) Received: by 10.204.49.21 with HTTP; Fri, 21 Oct 2011 13:14:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 13:14:50 -0700 Message-ID: From: Forest To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Client credentials for native applications: seeking clarification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:14:52 -0000 Thanks for the clarification. The subtle difference makes sense to me, and indeed was what prompted me to address this list in the first place. It *is* subtle, though, and the oauth-v2-22 draft doesn't even hint at it until six sections after a very clear "MUST" statement apparently forbidding this use of client credentials. I nearly walked away from OAuth 2 as soon as I read that bit in Section 4.4, and I suspect others would do exactly that. I only discovered the distinction because I happened to read an additional twelve discouraging pages past the apparent roadblock. So, for the sake of clarity in the working draft and in the hope of widespread adoption, I suggest that this subtle difference be stated alongside aforementioned MUST statement. I'll read the oauth-security rationale. Thanks for the link. I'm having trouble finding the current device flow proposal. The last mention of it I remember was an earlier oauth-v2 draft. Can you send me a current link? Cheers, Forest On Fri, Oct 21, 2011 at 01:38, Torsten Lodderstedt wrote: > Hi, > > there is no contradiction. The subtle difference lays in the word > "instance". Using secrets for a software package (and all of its > installations) is useless and therefore not allowed. If you are able to > issue a distinct id/secret pair to every installation of your app, this is > fine. > > For a the complete rationale pls. take a look into > http://tools.ietf.org/html/draft-lodderstedt-oauth-security/. > > The question is whether you really want to authenticate the client or the > user. For users, resource owner password is an option. I agree with you that > the user experience is bad. You may consider to use another device (pc, > smartphone) to perform the authorization flow. You may take a look onto the > device flow proposal. Alternatively, you could utilize the code flow on the > secondary device and ask the user to enter the code on the TV Set. > > regards, > Torsten. > > > > > Forest schrieb: >> >> Hi there. >> >> I've been considering OAuth 2 and its "client credentials" grant type >> for use with applications that run on televisions and other consumer >> devices. It is appealing mainly because it requires no built-in web >> browser and no cumbersome data entry for the user. (Similar to the >> Netflix device registration procedure.) However, I think I've run >> into a snag. >> >> Section 4.4 of draft-ietf-oauth-v2-22 says: >> "The client credentials grant type MUST only be used by confidential >> clients." >> >> Since Section 2.1 defines confidential clients as distinct from >> "clients executing on the resource owner's device", I have the >> impression that this forbids pretty much any device in the user's >> possession from using client credentials. (Except perhaps the rare >> gadget that embeds encrypted storage and physical safeguards against >> key >> discovery.) I suppose this would mean OAuth 2 is unsuitable for >> the task at hand. >> >> However, Section 10.1 says: >> "The authorization server MAY issue a client password or other >> credentials for a specific installation of a native application client >> on a specific device." >> >> This seems to contradict Section 4.4, although if I understand it >> correctly, it would allow me to use client credentials as I had hoped >> without violating the spec. That's encouraging. Maybe I can use >> OAuth 2 after all, so long as each installed instance of my >> application gets its own credentials. >> >> So, I could use some clarification on a few points: >> >> 1. Is that quote in Section 10.1 meant to be an exception to the one >> in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for >> the exception and to make it easier for OAuth 2 implementors to >> discover. >> >> 2. If it is not intended as an exception, meaning that >> apps running on >> consumer devices are not to be issued client credentials, what is the >> recommended alternative? Section 1.3.3 suggests resource owner >> password credentials when "other authorization grant types are not >> available", and using a "long-lived access token or refresh token". I >> suppose this approach would enable OAuth on devices that have no web >> browser, though it would create a usability problem by requiring users >> to enter their credentials using awkward, frustrating input devices >> (like 5-button remote controls). Perhaps more importantly, it begs >> the question of how storing a long-lived token is any more secure than >> storing client credentials. After all, both could grant access, both >> could be revoked, and both could be exposed just as easily. Which >> brings me to my third question: >> >> 3. From whom is a "confidential" client expected to keep its >> credentials secret? From the resource owner? (I >> suppose this would >> make sense for a server-side application trusted by many users, but it >> makes little sense for a consumer device, since a user is unlikely to >> give out his own device's credentials and could more easily give out >> his own password.) From other applications running on the same >> device? (This makes sense, but devices with sandboxed per-application >> storage would seem to warrant an exception from the "clients executing >> on the resource owner's device" generalization in Section 2.1.) From >> the world at large? (If this is the only level of confidentiality >> then I would think "clients executing on the resource owner's device" >> would easily qualify as confidential.) >> >> Thanks, all. I look forward to a better understanding of what is intended >> here. >> ________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Sat Oct 22 01:19:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9ED21F8AD6 for ; Sat, 22 Oct 2011 01:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SARE_HTML_A_BODY=0.742] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Dwaws5n7TmG for ; Sat, 22 Oct 2011 01:19:41 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by ietfa.amsl.com (Postfix) with ESMTP id ADE0421F8AAF for ; Sat, 22 Oct 2011 01:19:40 -0700 (PDT) Received: from [80.187.96.81] (helo=[10.211.0.120]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1RHWnm-0001BV-4e; Sat, 22 Oct 2011 10:19:38 +0200 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----O37YDG2I9J4JV8N5I7G5H0L56AP8UY" From: Torsten Lodderstedt Date: Sat, 22 Oct 2011 10:19:04 +0200 To: Forest Message-ID: <37d1e850-258b-48d6-9fc3-de1d44a39889@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Client credentials for native applications: seeking clarification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 08:19:42 -0000 ------O37YDG2I9J4JV8N5I7G5H0L56AP8UY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 Forest schrieb: Thanks for the clarification. The subtle difference makes sense to me, and indeed was what prompted me to address this list in the first place. It *is* subtle, though, and the oauth-v2-22 draft doesn't even hint at it until six sections after a very clear "MUST" statement apparently forbidding this use of client credentials. I nearly walked away from OAuth 2 as soon as I read that bit in Section 4.4, and I suspect others would do exactly that. I only discovered the distinction because I happened to read an additional twelve discouraging pages past the apparent roadblock. So, for the sake of clarity in the working draft and in the hope of widespread adoption, I suggest that this subtle difference be stated alongside aforementioned MUST statement. I'll read the oauth-security rationale. Thanks for the link. I'm having trouble finding the current device flow proposal. The last mention of it I remember was an earlier oauth-v2 draft. Can you send me a current link? Cheers, Forest On Fri, Oct 21, 2011 at 01:38, Torsten Lodderstedt wrote: > Hi, > > there is no contradiction. The subtle difference lays in the word > "instance". Using secrets for a software package (and all of its > installations) is useless and therefore not allowed. If you are able to > issue a distinct id/secret pair to every installation of your app, this is > fine. > > For a the complete rationale pls. take a look into > http://tools.ietf.org/html/draft-lodderstedt-oauth-security/. > > The question is whether you really want to authenticate the client or the > user. For users, resource owner password is an option. I agree with you that > the user experience is bad. You may consider to use another device (pc, > smartphone) to perform the authorization flow. You may take a look onto the > device flow proposal. Alternatively, you could utilize the code flow on the > secondary device and ask the user to enter the code on the TV Set. > > regards, > Torsten. > > > > > Forest schrieb: >> >> Hi there. >> >> I've been considering OAuth 2 and its "client credentials" grant type >> for use with applications that run on televisions and other consumer >> devices. It is appealing mainly because it requires no built-in web >> browser and no cumbersome data entry for the user. (Similar to the >> Netflix device registration procedure.) However, I think I've run >> into a snag. >> >> Section 4.4 of draft-ietf-oauth-v2-22 says: >> "The client credentials grant type MUST only be used by confidential >> clients." >> >> Since Section 2.1 defines confidential clients as distinct from >> "clients executing on the resource owner's device", I have the >> impression that this forbids pretty much any device in the user's >> possession from using client credentials. (Except perhaps the rare >> gadget that embeds encrypted storage and physical safeguards against >> key >> discovery.) I suppose this would mean OAuth 2 is unsuitable for >> the task at hand. >> >> However, Section 10.1 says: >> "The authorization server MAY issue a client password or other >> credentials for a specific installation of a native application client >> on a specific device." >> >> This seems to contradict Section 4.4, although if I understand it >> correctly, it would allow me to use client credentials as I had hoped >> without violating the spec. That's encouraging. Maybe I can use >> OAuth 2 after all, so long as each installed instance of my >> application gets its own credentials. >> >> So, I could use some clarification on a few points: >> >> 1. Is that quote in Section 10.1 meant to be an exception to the one >> in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for >> the exception and to make it easier for OAuth 2 implementors to >> discover. >> >> 2. If it is not intended as an exception, meaning that >> apps running on >> consumer devices are not to be issued client credentials, what is the >> recommended alternative? Section 1.3.3 suggests resource owner >> password credentials when "other authorization grant types are not >> available", and using a "long-lived access token or refresh token". I >> suppose this approach would enable OAuth on devices that have no web >> browser, though it would create a usability problem by requiring users >> to enter their credentials using awkward, frustrating input devices >> (like 5-button remote controls). Perhaps more importantly, it begs >> the question of how storing a long-lived token is any more secure than >> storing client credentials. After all, both could grant access, both >> could be revoked, and both could be exposed just as easily. Which >> brings me to my third question: >> >> 3. From whom is a "confidential" client expected to keep its >> credentials secret? From the resource owner? (I >> suppose this would >> make sense for a server-side application trusted by many users, but it >> makes little sense for a consumer device, since a user is unlikely to >> give out his own device's credentials and could more easily give out >> his own password.) From other applications running on the same >> device? (This makes sense, but devices with sandboxed per-application >> storage would seem to warrant an exception from the "clients executing >> on the resource owner's device" generalization in Section 2.1.) From >> the world at large? (If this is the only level of confidentiality >> then I would think "clients executing on the resource owner's device" >> would easily qualify as confidential.) >> >> Thanks, all. I look forward to a better understanding of what is intended >> here. >>_____________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > ------O37YDG2I9J4JV8N5I7G5H0L56AP8UY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00



Forest <tadaforest@gmail.com> schrieb:
Thanks for the clarification.  The subtle difference makes sense to
me, and indeed was what prompted me to address this list in the first
place.

It *is* subtle, though, and the oauth-v2-22 draft doesn't even hint at
it until six sections after a very clear "MUST" statement apparently
forbidding this use of client credentials.  I nearly walked away from
OAuth 2 as soon as I read that bit in Section 4.4, and I suspect
others would do exactly that.  I only discovered the distinction
because I happened to read an additional twelve discouraging pages
past the apparent roadblock. So, for the sake of clarity in the
working draft and in the hope of widespread adoption, I suggest that
this subtle difference be stated alongside aforementioned MUST
statement.

I'll read the oauth-security rationale.  Thanks for the link.

I'm
having trouble finding the current device flow proposal.  The last
mention of it I remember was an earlier oauth-v2 draft.  Can you send
me a current link?

Cheers,

Forest


On Fri, Oct 21, 2011 at 01:38, Torsten Lodderstedt
<torsten@lodderstedt.net> wrote:
> Hi,
>
> there is no contradiction. The subtle difference lays in the word
> "instance". Using secrets for a software package (and all of its
> installations) is useless and therefore not allowed. If you are able to
> issue a distinct id/secret pair to every installation of your app, this is
> fine.
>
> For a the complete rationale pls. take a look into
> http://tools.ietf.org/html/draft-lodderstedt-oauth-security/.
>
> The question is whether you really want to authenticate the client or the
&
 gt;
user. For users, resource owner password is an option. I agree with you that
> the user experience is bad. You may consider to use another device (pc,
> smartphone) to perform the authorization flow. You may take a look onto the
> device flow proposal. Alternatively, you could utilize the code flow on the
> secondary device and ask the user to enter the code on the TV Set.
>
> regards,
> Torsten.
>
>
>
>
> Forest <tadaforest@gmail.com> schrieb:
>>
>> Hi there.
>>
>> I've been considering OAuth 2 and its "client credentials" grant type
>> for use with applications that run on televisions and other consumer
>> devices.  It is appealing mainly because it requires no built-in web
>> browser and no cumbersome data entry for the user. (Similar to the
>> Netflix device registration procedure.)  H
 owever,
I think I've run
>> into a snag.
>>
>> Section 4.4 of draft-ietf-oauth-v2-22 says:
>> "The client credentials grant type MUST only be used by confidential
>> clients."
>>
>> Since Section 2.1 defines confidential clients as distinct from
>> "clients executing on the resource owner's device", I have the
>> impression that this forbids pretty much any device in the user's
>> possession from using client credentials.  (Except perhaps the rare
>> gadget that embeds encrypted storage and physical safeguards against
>> key
>> discovery.)  I suppose this would mean OAuth 2 is unsuitable for
>> the task at hand.
>>
>> However, Section 10.1 says:
>> "The authorization server MAY issue a client password or other
>> credentials for a specific installation of a native application client
&
 gt;>
on a specific device."
>>
>> This seems to contradict Section 4.4, although if I understand it
>> correctly, it would allow me to use client credentials as I had hoped
>> without violating the spec.  That's encouraging.  Maybe I can use
>> OAuth 2 after all, so long as each installed instance of my
>> application gets its own credentials.
>>
>> So, I could use some clarification on a few points:
>>
>> 1. Is that quote in Section 10.1 meant to be an exception to the one
>> in Section 4.4?  If so, I would suggest rephrasing 4.4 to allow for
>> the exception and to make it easier for OAuth 2 implementors to
>> discover.
>>
>> 2. If it is not intended as an exception, meaning that
>> apps running on
>> consumer devices are not to be issued client credentials, what is the
>> recommended
alternative?  Section 1.3.3 suggests resource owner
>> password credentials when "other authorization grant types are not
>> available", and using a "long-lived access token or refresh token".  I
>> suppose this approach would enable OAuth on devices that have no web
>> browser, though it would create a usability problem by requiring users
>> to enter their credentials using awkward, frustrating input devices
>> (like 5-button remote controls).  Perhaps more importantly, it begs
>> the question of how storing a long-lived token is any more secure than
>> storing client credentials.  After all, both could grant access, both
>> could be revoked, and both could be exposed just as easily.  Which
>> brings me to my third question:
>>
>> 3. From whom is a "confidential" client expected to keep its
>> credentials secret?  From the resource ow
 ner? 
(I
>> suppose this would
>> make sense for a server-side application trusted by many users, but it
>> makes little sense for a consumer device, since a user is unlikely to
>> give out his own device's credentials and could more easily give out
>> his own password.)  From other applications running on the same
>> device?  (This makes sense, but devices with sandboxed per-application
>> storage would seem to warrant an exception from the "clients executing
>> on the resource owner's device" generalization in Section 2.1.)  From
>> the world at large?  (If this is the only level of confidentiality
>> then I would think "clients executing on the resource owner's device"
>> would easily qualify as confidential.)
>>
>> Thanks, all.  I look forward to a better understanding of what is intended
>> here.
>>

>
 >
OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
------O37YDG2I9J4JV8N5I7G5H0L56AP8UY-- From sakimura@gmail.com Sat Oct 22 07:00:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25EC21F84CF for ; Sat, 22 Oct 2011 07:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEDrwvViQVMf for ; Sat, 22 Oct 2011 07:00:56 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9221F84CD for ; Sat, 22 Oct 2011 07:00:55 -0700 (PDT) Received: by eyg24 with SMTP id 24so4961737eyg.31 for ; Sat, 22 Oct 2011 07:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BfbURO/uyYb5yctawUZc2oNPKb647enp3H+dQ+ljZ0w=; b=I42UsYO3uZrZMeKUyjyXf7I1GpbUaIekN88Q/csBvyIg/+s4QnshD16zn8zL2Uulfu 8AlluNNBzG7wr2LMPNgltr5ONdnKhGyjH+c8HbH0m0KCJNPWsLx07mfs2BWqr84XCfNJ e8DB7JWNPc4EWW0TXk0+AxDkL0pDpIx2QXhyg= MIME-Version: 1.0 Received: by 10.223.14.134 with SMTP id g6mr31513066faa.11.1319292053222; Sat, 22 Oct 2011 07:00:53 -0700 (PDT) Received: by 10.152.37.201 with HTTP; Sat, 22 Oct 2011 07:00:53 -0700 (PDT) In-Reply-To: <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> Date: Sat, 22 Oct 2011 07:00:53 -0700 Message-ID: From: Nat Sakimura To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001517447b842ff53404afe39e63 Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 14:00:57 -0000 --001517447b842ff53404afe39e63 Content-Type: text/plain; charset=ISO-8859-1 Hi. Just a clarification: Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. Nat On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi all, > > my prioritization is driven by the goal to make OAuth the authorization > framework of choice for any internet standard protocol, such as WebDAV, > IMAP, SMTP or SIP. So let me first explain what is missing from my point of > view and explain some thoughts how to fill the gaps. > > A standard protocol is defined in terms of resource types and messages by a > body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and > used by different but deployment-independent clients. OAuth-based protocol > specifications must also define scope values (e.g. read, write, send) and > their relation to the resource types and messages. The different deployments > expose the standard protocol on different resource server endpoints. In my > opinion, it is fundamental to clearly distinguish scope values > (standardized, static) and resource server addresses (deployment specific) > and to manage their relationships. The current scope definition is much to > weak and insufficient. Probably, the UMA concepts of hosts, resources sets, > and corresponding scopes could be adopted for that purpose. > > OAuth today requires clients to register with the service provider before > they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, > to register with any a-Mail services upfront? So clients should be given a > way to register dynamically to the authorization servers. This should also > allow us to cover "client instance" aspects. It is interesting to note, that > such a mechanism would allow us to get rid of secret-less clients and the > one-time usage requirement for authorization codes. > > We also assume the client to know the URLs of the resource server and the > corresponding authorization server and to use HTTPS server authentication to > verify the resource server's authenticity. This is impossible in the > standard scenario. Clients must be able to discover the authorization server > a particular resource server relies on at runtime. The discovery mechanism > could be specified by the OAuth WG, but could also be part of an application > protocols specification. But we MUST find another way to prevent token > phishing by counterfeit resource servers. > > As one approach, the client could pass the (previously HTTPS validated) > resource server's URL with the authorization request. The authorization > server should then refuse such requests for any unknown (counterfeit) > resource servers. Such an additional parameter could also serve as namespace > for scope values and enable service providers to run multiple instances of > the same service within a single deployment. > > If the additional data enlarges the request payload to much, we could > consider to adopt the "request by reference" proposal. > > Let's now assume, OAuth is successful in the world of standard protocols > and we will see plenty of deployments with a bunch of different OAuth > protected resource servers. Shall this servers all be accessible with a > single token? In my opinion, this would cause security, privacy and/or > scalability/performance problems. To give just the most obvious example, the > target audience of such a token cannot be restricted enough, which may allow > a resource server (or an attacker in control of it) to abuse the token on > other servers. But the current design of the code grant type forces > deployments to use the same token for all services. What is needed from my > point of view is a way to request and issue multiple server-specific access > tokens with a single authorization process. > > I've been advocating this topic for a long time now and I'm still convinced > this is required to really complete the core design. We at Deutsche Telekom > needed and implemented this function on top of the existing core. In my > opinion, a core enhancement would be easier to handle and more powerful. If > others support this topic, I would be willed to submit an I-D describing a > possible solution. > > If we take standards really seriously, then service providers should be > given the opportunity to implement their service by utilizing standard > server implementations. This creates the challenge to find a standardized > protocol between authorization server and resource server to exchange > authorization data. Depending on the token design (self-contained vs. > handle) this could be solved by either standardizing a token format (JWT) or > an authorization API. > > Based on the rationale given above, my list is as follows (topics w/o I-D > are marked with *): > > - Revocation (low hanging fruit since I-D is ready and implemented in some > places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration > > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) > > regards, > Torsten. > Zitat von Hannes Tschofenig : > > > Hi all, >> >> in preparation of the upcoming IETF meeting Barry and I would like to >> start a re-chartering discussion. We both are currently attending the >> Internet Identity Workshop and so we had the chance to solicit input from >> the participants. This should serve as a discussion starter. >> >> Potential future OAuth charter items (in random order): >> >> ---------------- >> >> 1) Dynamic Client Registration Protocol >> >> Available document: >> http://datatracker.ietf.org/**doc/draft-hardjono-oauth-**dynreg/ >> >> 2) Token Revocation >> >> Available document: >> http://datatracker.ietf.org/**doc/draft-lodderstedt-oauth-**revocation/ >> >> 3) UMA >> >> Available document: >> http://datatracker.ietf.org/**doc/draft-hardjono-oauth-**umacore/ >> >> 4) Client Instance Extension >> >> Available document: >> http://tools.ietf.org/id/**draft-richer-oauth-instance-**00.txt >> >> 5) XML Encoding >> >> Available document: >> http://tools.ietf.org/id/**draft-richer-oauth-xml-00.txt >> >> 6) JSON Web Token >> >> Available document: >> http://tools.ietf.org/html/**draft-jones-json-web-token-05 >> >> 7) JSON Web Token (JWT) Bearer Profile >> >> Available document: >> http://tools.ietf.org/html/**draft-jones-oauth-jwt-bearer-**00 >> >> 8) User Experience Extension >> >> Available document: >> http://tools.ietf.org/html/**draft-recordon-oauth-v2-ux-00 >> >> 9) Request by Reference >> >> Available document: >> http://tools.ietf.org/html/**draft-sakimura-oauth-requrl-00 >> >> 10) Simple Web Discovery >> >> Available document: >> http://tools.ietf.org/html/**draft-jones-simple-web-**discovery-00 >> >> ---------------- >> >> We have the following questions: >> >> a) Are you interested in any of the above-listed items? (as a reviewer, >> co-author, implementer, or someone who would like to deploy). It is also >> useful to know if you think that we shouldn't work on a specific item. >> >> b) Are there other items you would like to see the group working on? >> >> Note: In case your document is expired please re-submit it. >> >> Ciao >> Hannes & Barry >> >> ______________________________**_________________ >> 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 > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001517447b842ff53404afe39e63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi.=A0

Just a clarification:=A0

Although my expired draft is 'request by reference', what was prop= osed through it at the iiw really is a generalized JSON based claim request= capability. It could be passed by value as JSON or could be passed by refe= rence. The later is an optimization for bandwidth constrained network as we= ll as strengthening security in some ways. This capability already exists i= n OpenID Connect but it is actually an underpinning transport, so it probab= ly should belong to OAuth instead. This was the primary reason for the prop= osal.=A0

Nat

On Thu, Oc= t 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wro= te:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization fra= mework of choice for any internet standard protocol, such as WebDAV, IMAP, = SMTP or SIP. So let me first explain what is missing from my point of view = and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a= body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and u= sed by different but deployment-independent clients. OAuth-based protocol s= pecifications must also define scope values (e.g. read, write, send) and th= eir relation to the resource types and messages. The different deployments = expose the standard protocol on different resource server endpoints. In my = opinion, it is fundamental to clearly distinguish scope values (standardize= d, static) and =A0resource server addresses (deployment specific) and to ma= nage their relationships. The current scope definition is much to weak and = insufficient. Probably, the UMA concepts of hosts, resources sets, and corr= esponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before t= hey are deployed. Would you really expect IMAP clients, e.g. Thunderbird, t= o register with any a-Mail services upfront? So clients should be given a w= ay to register dynamically to the authorization servers. This should also a= llow us to cover "client instance" aspects. It is interesting to = note, that such a mechanism would allow us to get rid of secret-less client= s and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the c= orresponding authorization server and to use HTTPS server authentication to= verify the resource server's authenticity. This is impossible in the s= tandard scenario. Clients must be able to discover the authorization server= a particular resource server relies on at runtime. The discovery mechanism= could be specified by the OAuth WG, but could also be part of an applicati= on protocols specification. But we MUST find another way to prevent token p= hishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) res= ource server's URL with the authorization request. The authorization se= rver should then refuse such requests for any unknown (counterfeit) resourc= e servers. Such an additional parameter could also serve as namespace for s= cope values and enable service providers to run multiple instances of the s= ame service within a single deployment.

If the additional data enlarges the request payload to much, we could consi= der to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocol= s and we will see plenty of deployments with a bunch of different OAuth pro= tected resource servers. Shall this servers all be accessible with a single= token? In my opinion, this would cause security, privacy and/or scalabilit= y/performance problems. To give just the most obvious example, the target a= udience of such a token cannot be restricted enough, which may allow a reso= urce server (or an attacker in control of it) to abuse the token on other s= ervers. But the current design of the code grant type forces deployments to= use the same token for all services. What is needed from my point of view = is a way to request and issue multiple server-specific access tokens with a= single authorization process.

I've been advocating this topic for a long time now and I'm still c= onvinced this is required to really complete the core design. We at Deutsch= e Telekom needed and implemented this function on top of the existing core.= In my opinion, a core enhancement would be easier to handle and more power= ful. If others support this topic, I would be willed to submit an I-D descr= ibing a possible solution.

If we take standards really seriously, then service providers should be giv= en the opportunity to implement their service by utilizing standard server = implementations. This creates the challenge to find a standardized protocol= between authorization server and resource server to exchange authorization= data. Depending on the token design (self-contained vs. handle) this could= be solved by either standardizing a token format (JWT) or an authorization= API.

Based on the rationale given above, my list is as follows (topics w/o I-D a= re marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some = places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

=A01) Dynamic Client Registration Protocol
=A04) Client Instance Extension
- Discovery
=A0(10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
=A0(depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start= a re-chartering discussion. =A0We both are currently attending the Interne= t Identity Workshop and so we had the chance to solicit input from the part= icipants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth= -dynreg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodders= tedt-oauth-revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oaut= h-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-= 00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05=

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-beare= r-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00=

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-= 00

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-= discovery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-= author, implementer, or someone who would like to deploy). It is also usefu= l to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en

--001517447b842ff53404afe39e63-- From eve@xmlgrrl.com Sat Oct 22 22:13:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9C021F8B23 for ; Sat, 22 Oct 2011 22:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5hJv5PHkePB for ; Sat, 22 Oct 2011 22:13:38 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id BB14621F8B22 for ; Sat, 22 Oct 2011 22:13:37 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id p9N5DVMP019815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Oct 2011 22:13:33 -0700 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> Date: Sat, 22 Oct 2011 22:13:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <867FBBCF-8578-4DC5-B59F-BF39B681F873@xmlgrrl.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 05:13:39 -0000 Hi Torsten et al., Prioritizing new work items based on an overarching goal seems like a = good idea. If Torsten's goal of making OAuth "the authorization = framework of choice for any internet protocol" is more widely shared, it = gives a useful basis for assessing the proposals consistently. I think = this is a great goal, myself. OAuth 2.0 has gone pretty far in this = direction, but not all the way. Although UMA can be seen as a relatively large and comprehensive = "application of OAuth" in the spec's current form, Torsten's suggestion = to look at it in pieces is certainly consistent with the intent of the = UMA group, and we're happy to break our future contributions down into = modules where it makes sense. Here are some obvious bits of UMA functionality that could be = considered: - (As Torsten notes:) Machine-readable descriptions of scopes (whether = proprietary or standardized) and interoperable ways to attach them to = labeled resource sets. This is where UMA's ability to differentially = protect arbitrary Web resources, such as each photo in an album, comes = from. - Standard interface between authorization server and resource server. - Clean distinction between authenticating a client and authorizing the = operator of the client for access. Achieving this could further the goal = of OAuth as an authorization framework of choice. Note that this is = where UMA's abilities to allow delegated authorization to third parties, = and to do true claims-based authorization, come from.=20 The work that we'd done in the UMA group and contributed to IETF on = dynamic client registration seems to have influenced other work in this = area, which is great. UMA, among others, definitely needs the ability to = register "client instances", but we currently point off to the OpenID = Connect spec for this. We'd love to be able to point to a registration = spec that has sedimented into the OAuth core (or satellite specs), since = it seems widely desired at this level. Eve On 20 Oct 2011, at 3:56 PM, Torsten Lodderstedt wrote: > Hi all, >=20 > my prioritization is driven by the goal to make OAuth the = authorization framework of choice for any internet standard protocol, = such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is = missing from my point of view and explain some thoughts how to fill the = gaps. >=20 > A standard protocol is defined in terms of resource types and messages = by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many = places, and used by different but deployment-independent clients. = OAuth-based protocol specifications must also define scope values (e.g. = read, write, send) and their relation to the resource types and = messages. The different deployments expose the standard protocol on = different resource server endpoints. In my opinion, it is fundamental to = clearly distinguish scope values (standardized, static) and resource = server addresses (deployment specific) and to manage their = relationships. The current scope definition is much to weak and = insufficient. Probably, the UMA concepts of hosts, resources sets, and = corresponding scopes could be adopted for that purpose. >=20 > OAuth today requires clients to register with the service provider = before they are deployed. Would you really expect IMAP clients, e.g. = Thunderbird, to register with any a-Mail services upfront? So clients = should be given a way to register dynamically to the authorization = servers. This should also allow us to cover "client instance" aspects. = It is interesting to note, that such a mechanism would allow us to get = rid of secret-less clients and the one-time usage requirement for = authorization codes. >=20 > We also assume the client to know the URLs of the resource server and = the corresponding authorization server and to use HTTPS server = authentication to verify the resource server's authenticity. This is = impossible in the standard scenario. Clients must be able to discover = the authorization server a particular resource server relies on at = runtime. The discovery mechanism could be specified by the OAuth WG, but = could also be part of an application protocols specification. But we = MUST find another way to prevent token phishing by counterfeit resource = servers. >=20 > As one approach, the client could pass the (previously HTTPS = validated) resource server's URL with the authorization request. The = authorization server should then refuse such requests for any unknown = (counterfeit) resource servers. Such an additional parameter could also = serve as namespace for scope values and enable service providers to run = multiple instances of the same service within a single deployment. >=20 > If the additional data enlarges the request payload to much, we could = consider to adopt the "request by reference" proposal. >=20 > Let's now assume, OAuth is successful in the world of standard = protocols and we will see plenty of deployments with a bunch of = different OAuth protected resource servers. Shall this servers all be = accessible with a single token? In my opinion, this would cause = security, privacy and/or scalability/performance problems. To give just = the most obvious example, the target audience of such a token cannot be = restricted enough, which may allow a resource server (or an attacker in = control of it) to abuse the token on other servers. But the current = design of the code grant type forces deployments to use the same token = for all services. What is needed from my point of view is a way to = request and issue multiple server-specific access tokens with a single = authorization process. >=20 > I've been advocating this topic for a long time now and I'm still = convinced this is required to really complete the core design. We at = Deutsche Telekom needed and implemented this function on top of the = existing core. In my opinion, a core enhancement would be easier to = handle and more powerful. If others support this topic, I would be = willed to submit an I-D describing a possible solution. >=20 > If we take standards really seriously, then service providers should = be given the opportunity to implement their service by utilizing = standard server implementations. This creates the challenge to find a = standardized protocol between authorization server and resource server = to exchange authorization data. Depending on the token design = (self-contained vs. handle) this could be solved by either standardizing = a token format (JWT) or an authorization API. >=20 > Based on the rationale given above, my list is as follows (topics w/o = I-D are marked with *): >=20 > - Revocation (low hanging fruit since I-D is ready and implemented in = some places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) >=20 > regards, > Torsten. > Zitat von Hannes Tschofenig : >=20 >> Hi all, >>=20 >> in preparation of the upcoming IETF meeting Barry and I would like to = start a re-chartering discussion. We both are currently attending the = Internet Identity Workshop and so we had the chance to solicit input = from the participants. This should serve as a discussion starter. >>=20 >> Potential future OAuth charter items (in random order): >>=20 >> ---------------- >>=20 >> 1) Dynamic Client Registration Protocol >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>=20 >> 2) Token Revocation >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>=20 >> 3) UMA >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>=20 >> 4) Client Instance Extension >>=20 >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>=20 >> 5) XML Encoding >>=20 >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>=20 >> 6) JSON Web Token >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>=20 >> 7) JSON Web Token (JWT) Bearer Profile >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>=20 >> 8) User Experience Extension >>=20 >> Available document: >> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>=20 >> 9) Request by Reference >>=20 >> Available document: >> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>=20 >> 10) Simple Web Discovery >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>=20 >> ---------------- >>=20 >> We have the following questions: >>=20 >> a) Are you interested in any of the above-listed items? (as a = reviewer, co-author, implementer, or someone who would like to deploy). = It is also useful to know if you think that we shouldn't work on a = specific item. >>=20 >> b) Are there other items you would like to see the group working on? >>=20 >> Note: In case your document is expired please re-submit it. >>=20 >> Ciao >> Hannes & Barry >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From hardjono@mit.edu Mon Oct 24 07:31:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D6521F8C4D for ; Mon, 24 Oct 2011 07:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdjCpgt-dabQ for ; Mon, 24 Oct 2011 07:31:07 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id B73B621F84A9 for ; Mon, 24 Oct 2011 07:31:06 -0700 (PDT) X-AuditID: 1209190f-b7f6e6d0000008df-c1-4ea576a984c0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id D6.6B.02271.9A675AE4; Mon, 24 Oct 2011 10:31:05 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p9OEV46h019131 for ; Mon, 24 Oct 2011 10:31:05 -0400 Received: from w92exedge3.EXCHANGE.MIT.EDU (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id p9OEV3fP002319 for ; Mon, 24 Oct 2011 10:31:04 -0400 Received: from oc11exhub1.exchange.mit.edu (18.9.3.11) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 24 Oct 2011 10:30:20 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub1.exchange.mit.edu ([18.9.3.11]) with mapi; Mon, 24 Oct 2011 10:31:03 -0400 From: Thomas Hardjono To: "oauth (oauth@ietf.org)" Date: Mon, 24 Oct 2011 10:31:01 -0400 Thread-Topic: New Version Notification for draft-hardjono-oauth-dynreg-01.txt Thread-Index: AcySWVPyKbX4q4C9TZ6+o/OdvWWK0gAAB7mA Message-ID: References: <20111024142922.27979.37890.idtracker@ietfa.amsl.com> In-Reply-To: <20111024142922.27979.37890.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHKsWRmVeSWpSXmKPExsUixG6noruybKmfwc65ZhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtpPn9kLmrgq9u27wdbA+ICzi5GTQ0LAROLLtw5mCFtM4sK9 9WxdjFwcQgL7GCW6L71lh3CuMkqcubafBcJ5ySjx+O4/JpAWIYGtjBKvWtwgEhMYJX4ueMgC kmAT0JA493svO4gtIqArsfpTL5jNIqAq8Wf7ArBmYQEfid8vXjFB1PhKdN/bxQphG0lMX3ye EcTmFQiQOPOphRFimaPEnf37wWxOASeJ123zwXYxAt39/dQasDnMAuISt57MZ4L4R1Bi0ew9 cL/92/WQDaJeVOJO+3qgORxA9ZoS63fpQ7QqSkzpfsgOsVZQ4uTMJyxAH81CMnUWQscsJB2z kHQsYGRZxSibklulm5uYmVOcmqxbnJyYl5dapGuil5tZopeaUrqJERRtnJL8Oxi/HVQ6xCjA wajEw3tp6RI/IdbEsuLK3EOMkhxMSqK8+iVL/YT4kvJTKjMSizPii0pzUosPMUpwMCuJ8M6z BsrxpiRWVqUW5cOkpDlYlMR5G3c4+AkJpCeWpGanphakFsFkZTg4lCR4xYBJRUiwKDU9tSIt M6cEIc3EwQkynAdouChIDW9xQWJucWY6RP4Uo6KUOO+fUqCEAEgiozQPrheWDF8xigO9Isx7 DaSKB5hI4bpfAQ1mAhqszA42uCQRISXVwKgdsO9v/7X1OiGLF02/yX0uydzG5InthQeN57yM s55fr+eRkr+wl19z1duamlkLMlMibS8z5rw6mZ0pcybEaOkNhXCXq6kypf3/P/e3CCxScrAu cb+3mfn61x2/2FSWbvskqHjDe8mN6/8CZ37xt43nM/K41lp4vjM569/xy2HtV9JFA4N/bVdi Kc5INNRiLipOBACVXA6ZYQMAAA== Subject: [OAUTH-WG] FW: New Version Notification for draft-hardjono-oauth-dynreg-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:31:07 -0000 RllJIEZvbGtzLA0KDQpKdXN0IGEgcmV2IHVwZGF0ZS4NCg0KL3Rob21hcy8NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNCwgMjAxMSAxMDoy OSBBTQ0KVG86IFRob21hcyBIYXJkam9ubw0KQ2M6IG0ucC5tYWNodWxha0BuY2wuYWMudWs7IFRo b21hcyBIYXJkam9ubzsgZXZlQHhtbGdycmwuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWhhcmRqb25vLW9hdXRoLWR5bnJlZy0wMS50eHQNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhcmRqb25vLW9hdXRoLWR5bnJlZy0wMS50eHQgaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaG9tYXMgSGFyZGpvbm8gYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWhhcmRqb25vLW9hdXRo LWR5bnJlZw0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgT0F1dGggRHluYW1pYyBDbGllbnQgUmVn aXN0cmF0aW9uIFByb3RvY29sDQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0xMC0yNA0KV0cgSUQ6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIwDQoNCkFic3RyYWN0Og0K ICAgVGhpcyBzcGVjaWZpY2F0aW9uIHByb3Bvc2VzIGFuIE9BdXRoIER5bmFtaWMgQ2xpZW50IFJl Z2lzdHJhdGlvbg0KICAgcHJvdG9jb2wuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From internet-drafts@ietf.org Tue Oct 25 14:49:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DC611E80AB; Tue, 25 Oct 2011 14:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZPDonlhPhcV; Tue, 25 Oct 2011 14:49:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D579B11E80A4; Tue, 25 Oct 2011 14:49:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025214948.32607.92459.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 14:49:48 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 21:49:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-11.txt Pages : 18 Date : 2011-10-25 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get ac= cess to granted resources (without demonstrating possession of a cryptographic key). To prevent misuse, the bearer token MUST be protected from disclosure in storage and in transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-11.txt From Michael.Jones@microsoft.com Tue Oct 25 15:02:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5682B1F0C4C for ; Tue, 25 Oct 2011 15:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.176 X-Spam-Level: X-Spam-Status: No, score=-10.176 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJbNu1TnkgVJ for ; Tue, 25 Oct 2011 15:02:22 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4294B1F0C40 for ; Tue, 25 Oct 2011 15:02:22 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Oct 2011 15:02:22 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.67]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0339.002; Tue, 25 Oct 2011 15:02:21 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -11 Thread-Index: AcyTYcSVnA6zcoyRQiqrjGTKadHIbg== Date: Tue, 25 Oct 2011 22:02:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F6BD1F6@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F6BD1F6TK5EX14MBXC283r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 22:02:23 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F6BD1F6TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 11 o= f the OAuth 2.0 Bearer Token Specification has been published. This version is intended= for submission to the IESG. It contains the following change: * Replaced uses of <"> with DQUOTE to pass ABNF syntax check. The draft is available at these locations: * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-11 * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-11= .pdf * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-11= .txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-11= .xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-11.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-11.pdf * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-11.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-11.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (wil= l point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will= point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will= point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will= point to new versions as they are posted) * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion= repository, with html, pdf, txt, and html versions available) -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435F6BD1F6TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 11 of the OA= uth 2.0 Bearer Token Specification has been published.  This versi= on is intended for submission to the IESG.  It contains the following = change:

·    &= nbsp;    Replace= d uses of <"> with DQUOTE to pass ABNF syntax check.<= /span>

 

The draft is available at these locations:

·         http://tools.ietf.org/html/draft-ietf-oauth-v2-bea= rer-11

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-11.pdf

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-11.txt

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-11.xml

·         http://self-issued.info/docs/draft-ietf-oau= th-v2-bearer-11.html

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-11.pdf

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-11.txt

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-11.xml

·         http://self-issued.info/docs/draft-ietf-oauth-= v2-bearer.html (will point to new versions as they are posted)

·         http://self-issued.info/docs/draft-ietf-oauth-v= 2-bearer.pdf (will point to new versions as they are posted)=

·         http://self-issued.info/docs/draft-ietf-oauth-v= 2-bearer.txt (will point to new versions as they are posted)=

·         http://self-issued.info/docs/draft-ietf-oauth-v= 2-bearer.xml (will point to new versions as they are posted)=

·         http://svn.openid.net/repos/specifications/oauth/2.0/= (Subversion repository, with html, pdf, txt, and html versions availab= le)

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435F6BD1F6TK5EX14MBXC283r_-- From dan.taflin@gettyimages.com Tue Oct 25 15:36:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C96B21F8A71 for ; Tue, 25 Oct 2011 15:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh9+nRPpbdEt for ; Tue, 25 Oct 2011 15:36:40 -0700 (PDT) Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC6421F891D for ; Tue, 25 Oct 2011 15:36:40 -0700 (PDT) X-Env-Sender: dan.taflin@gettyimages.com X-Msg-Ref: server-5.tower-144.messagelabs.com!1319582204!101014359!1 X-Originating-IP: [216.169.250.56] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 468 invoked from network); 25 Oct 2011 22:36:45 -0000 Received: from seattle.webmail.gettyimages.com (HELO SEAPXCH10CAHT01.amer.gettywan.com) (216.169.250.56) by server-5.tower-144.messagelabs.com with AES128-SHA encrypted SMTP; 25 Oct 2011 22:36:45 -0000 Received: from SEAPXCH10MBX01.amer.gettywan.com ([fe80::f054:280d:92db:5fff]) by SEAPXCH10CAHT01.amer.gettywan.com ([::1]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 15:36:38 -0700 From: Dan Taflin To: OAuth WG Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMj80/lXiDycBFuE2v7P/5IVRfpJWNqh8Q Date: Tue, 25 Oct 2011 22:36:35 +0000 Message-ID: <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> In-Reply-To: <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.102.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 22:36:41 -0000 I would like to second Torsten's pitch for the ability to return multiple a= ccess tokens with a single authorization process. The use case for my compa= ny is to segment operations into two main categories: protected and confide= ntial. (A possible third category, public, would not require any authorizat= ion at all). Protected operations would be user-specific operations that do= n't involve the passing of any sensitive information, such as image search = results tagged with information about whether each image is available for d= ownload by that user. Confidential operations would involve passing user da= ta, like user registration or e-commerce. We would like to protect each cat= egory of operations with distinct tokens: a general-use token for protected= operations, and a secure token for confidential operations. We could use the scope parameter to specify either "protected" or "confiden= tial". Currently the oauth spec allows a Refresh token to request a new tok= en with reduced scope from the one originally issued, but there is no way t= o obtain a new token with a completely different scope without doing the fu= ll oauth dance a second time. Dan -----Original Message----- From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 Sent: Thursday, October 20, 2011 3:57 PM To: Hannes Tschofenig Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering Hi all, my prioritization is driven by the goal to make OAuth the =20 authorization framework of choice for any internet standard protocol, =20 such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is =20 missing from my point of view and explain some thoughts how to fill =20 the gaps. A standard protocol is defined in terms of resource types and messages =20 by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many =20 places, and used by different but deployment-independent clients. =20 OAuth-based protocol specifications must also define scope values =20 (e.g. read, write, send) and their relation to the resource types and =20 messages. The different deployments expose the standard protocol on =20 different resource server endpoints. In my opinion, it is fundamental =20 to clearly distinguish scope values (standardized, static) and =20 resource server addresses (deployment specific) and to manage their =20 relationships. The current scope definition is much to weak and =20 insufficient. Probably, the UMA concepts of hosts, resources sets, and =20 corresponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider =20 before they are deployed. Would you really expect IMAP clients, e.g. =20 Thunderbird, to register with any a-Mail services upfront? So clients =20 should be given a way to register dynamically to the authorization =20 servers. This should also allow us to cover "client instance" aspects. =20 It is interesting to note, that such a mechanism would allow us to get =20 rid of secret-less clients and the one-time usage requirement for =20 authorization codes. We also assume the client to know the URLs of the resource server and =20 the corresponding authorization server and to use HTTPS server =20 authentication to verify the resource server's authenticity. This is =20 impossible in the standard scenario. Clients must be able to discover =20 the authorization server a particular resource server relies on at =20 runtime. The discovery mechanism could be specified by the OAuth WG, =20 but could also be part of an application protocols specification. But =20 we MUST find another way to prevent token phishing by counterfeit =20 resource servers. As one approach, the client could pass the (previously HTTPS =20 validated) resource server's URL with the authorization request. The =20 authorization server should then refuse such requests for any unknown =20 (counterfeit) resource servers. Such an additional parameter could =20 also serve as namespace for scope values and enable service providers =20 to run multiple instances of the same service within a single =20 deployment. If the additional data enlarges the request payload to much, we could =20 consider to adopt the "request by reference" proposal. Let's now assume, OAuth is successful in the world of standard =20 protocols and we will see plenty of deployments with a bunch of =20 different OAuth protected resource servers. Shall this servers all be =20 accessible with a single token? In my opinion, this would cause =20 security, privacy and/or scalability/performance problems. To give =20 just the most obvious example, the target audience of such a token =20 cannot be restricted enough, which may allow a resource server (or an =20 attacker in control of it) to abuse the token on other servers. But =20 the current design of the code grant type forces deployments to use =20 the same token for all services. What is needed from my point of view =20 is a way to request and issue multiple server-specific access tokens =20 with a single authorization process. I've been advocating this topic for a long time now and I'm still =20 convinced this is required to really complete the core design. We at =20 Deutsche Telekom needed and implemented this function on top of the =20 existing core. In my opinion, a core enhancement would be easier to =20 handle and more powerful. If others support this topic, I would be =20 willed to submit an I-D describing a possible solution. If we take standards really seriously, then service providers should =20 be given the opportunity to implement their service by utilizing =20 standard server implementations. This creates the challenge to find a =20 standardized protocol between authorization server and resource server =20 to exchange authorization data. Depending on the token design =20 (self-contained vs. handle) this could be solved by either =20 standardizing a token format (JWT) or an authorization API. Based on the rationale given above, my list is as follows (topics w/o =20 I-D are marked with *): - Revocation (low hanging fruit since I-D is ready and implemented in =20 some places) - Resource server notion* - Multiple access tokens* - Dynamic client registration 1) Dynamic Client Registration Protocol 4) Client Instance Extension - Discovery (10) Simple Web Discovery, probably other specs as well - (6) JSON Web Token - (7) JSON Web Token (JWT) Bearer Profile - 8) User Experience Extension - Device flow - 9) Request by Reference (depending resource server notion and multiple access tokens) regards, Torsten. Zitat von Hannes Tschofenig : > Hi all, > > in preparation of the upcoming IETF meeting Barry and I would like =20 > to start a re-chartering discussion. We both are currently =20 > attending the Internet Identity Workshop and so we had the chance to =20 > solicit input from the participants. This should serve as a =20 > discussion starter. > > Potential future OAuth charter items (in random order): > > ---------------- > > 1) Dynamic Client Registration Protocol > > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > 2) Token Revocation > > Available document: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > 3) UMA > > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > 4) Client Instance Extension > > Available document: > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > 5) XML Encoding > > Available document: > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > 6) JSON Web Token > > Available document: > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > 7) JSON Web Token (JWT) Bearer Profile > > Available document: > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > 8) User Experience Extension > > Available document: > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > 9) Request by Reference > > Available document: > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > 10) Simple Web Discovery > > Available document: > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > ---------------- > > We have the following questions: > > a) Are you interested in any of the above-listed items? (as a =20 > reviewer, co-author, implementer, or someone who would like to =20 > deploy). It is also useful to know if you think that we shouldn't =20 > work on a specific item. > > b) Are there other items you would like to see the group working on? > > Note: In case your document is expired please re-submit it. > > Ciao > Hannes & Barry > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From daver@quizlet.com Tue Oct 25 16:08:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E1521F848B for ; Tue, 25 Oct 2011 16:08:46 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3af0U6zwVGQs for ; Tue, 25 Oct 2011 16:08:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D409E1F0C43 for ; Tue, 25 Oct 2011 16:08:44 -0700 (PDT) Received: by gyh20 with SMTP id 20so1155049gyh.31 for ; Tue, 25 Oct 2011 16:08:44 -0700 (PDT) Received: by 10.236.124.4 with SMTP id w4mr44820674yhh.30.1319584124341; Tue, 25 Oct 2011 16:08:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id y71sm11743130yhh.6.2011.10.25.16.08.41 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 16:08:42 -0700 (PDT) Received: by ggnv1 with SMTP id v1so1146645ggn.31 for ; Tue, 25 Oct 2011 16:08:41 -0700 (PDT) Received: by 10.101.163.20 with SMTP id q20mr6692599ano.43.1319584121199; Tue, 25 Oct 2011 16:08:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.3.11 with HTTP; Tue, 25 Oct 2011 16:08:20 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> From: Dave Rochwerger Date: Tue, 25 Oct 2011 16:08:20 -0700 Message-ID: To: Dan Taflin Content-Type: multipart/alternative; boundary=0016e68deb79cb9bd804b0279e2f Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 23:08:46 -0000 --0016e68deb79cb9bd804b0279e2f Content-Type: text/plain; charset=ISO-8859-1 Is separating this out into 2 different tokens, really the best way to solve your use case? It sounds to me that you simply want to track/log the two types of accesses differently, which can be done entirely outside of the oauth2 process. Just bucket your operations into two piles internally and track appropriately (which you would have to do anyway with scopes). Scopes are the specific access that the end user grants to a 3rd party to access their protected resources. When an application, to use your example, asks for the scope "protected confidential", they are providing those two levels of access to the 3rd party application. If the user says "allow", then that application has all the access that those two scopes provides. Rather than getting applications to then further choose between two tokens to simply delineate two sets of operations seems like the wrong place to be doing this. i.e., why does the 3rd party application have to choose which token to use for each set of operations? - the user has already granted both. The resource server can do whatever tracking/logging it wants based on the actual operations requested - using the single token in this case. Regards, Dave On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin wrote: > I would like to second Torsten's pitch for the ability to return multiple > access tokens with a single authorization process. The use case for my > company is to segment operations into two main categories: protected and > confidential. (A possible third category, public, would not require any > authorization at all). Protected operations would be user-specific > operations that don't involve the passing of any sensitive information, such > as image search results tagged with information about whether each image is > available for download by that user. Confidential operations would involve > passing user data, like user registration or e-commerce. We would like to > protect each category of operations with distinct tokens: a general-use > token for protected operations, and a secure token for confidential > operations. > > We could use the scope parameter to specify either "protected" or > "confidential". Currently the oauth spec allows a Refresh token to request a > new token with reduced scope from the one originally issued, but there is no > way to obtain a new token with a completely different scope without doing > the full oauth dance a second time. > > Dan > > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Thursday, October 20, 2011 3:57 PM > To: Hannes Tschofenig > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering > > Hi all, > > my prioritization is driven by the goal to make OAuth the > authorization framework of choice for any internet standard protocol, > such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is > missing from my point of view and explain some thoughts how to fill > the gaps. > > A standard protocol is defined in terms of resource types and messages > by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many > places, and used by different but deployment-independent clients. > OAuth-based protocol specifications must also define scope values > (e.g. read, write, send) and their relation to the resource types and > messages. The different deployments expose the standard protocol on > different resource server endpoints. In my opinion, it is fundamental > to clearly distinguish scope values (standardized, static) and > resource server addresses (deployment specific) and to manage their > relationships. The current scope definition is much to weak and > insufficient. Probably, the UMA concepts of hosts, resources sets, and > corresponding scopes could be adopted for that purpose. > > OAuth today requires clients to register with the service provider > before they are deployed. Would you really expect IMAP clients, e.g. > Thunderbird, to register with any a-Mail services upfront? So clients > should be given a way to register dynamically to the authorization > servers. This should also allow us to cover "client instance" aspects. > It is interesting to note, that such a mechanism would allow us to get > rid of secret-less clients and the one-time usage requirement for > authorization codes. > > We also assume the client to know the URLs of the resource server and > the corresponding authorization server and to use HTTPS server > authentication to verify the resource server's authenticity. This is > impossible in the standard scenario. Clients must be able to discover > the authorization server a particular resource server relies on at > runtime. The discovery mechanism could be specified by the OAuth WG, > but could also be part of an application protocols specification. But > we MUST find another way to prevent token phishing by counterfeit > resource servers. > > As one approach, the client could pass the (previously HTTPS > validated) resource server's URL with the authorization request. The > authorization server should then refuse such requests for any unknown > (counterfeit) resource servers. Such an additional parameter could > also serve as namespace for scope values and enable service providers > to run multiple instances of the same service within a single > deployment. > > If the additional data enlarges the request payload to much, we could > consider to adopt the "request by reference" proposal. > > Let's now assume, OAuth is successful in the world of standard > protocols and we will see plenty of deployments with a bunch of > different OAuth protected resource servers. Shall this servers all be > accessible with a single token? In my opinion, this would cause > security, privacy and/or scalability/performance problems. To give > just the most obvious example, the target audience of such a token > cannot be restricted enough, which may allow a resource server (or an > attacker in control of it) to abuse the token on other servers. But > the current design of the code grant type forces deployments to use > the same token for all services. What is needed from my point of view > is a way to request and issue multiple server-specific access tokens > with a single authorization process. > > I've been advocating this topic for a long time now and I'm still > convinced this is required to really complete the core design. We at > Deutsche Telekom needed and implemented this function on top of the > existing core. In my opinion, a core enhancement would be easier to > handle and more powerful. If others support this topic, I would be > willed to submit an I-D describing a possible solution. > > If we take standards really seriously, then service providers should > be given the opportunity to implement their service by utilizing > standard server implementations. This creates the challenge to find a > standardized protocol between authorization server and resource server > to exchange authorization data. Depending on the token design > (self-contained vs. handle) this could be solved by either > standardizing a token format (JWT) or an authorization API. > > Based on the rationale given above, my list is as follows (topics w/o > I-D are marked with *): > > - Revocation (low hanging fruit since I-D is ready and implemented in > some places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) > > regards, > Torsten. > Zitat von Hannes Tschofenig : > > > Hi all, > > > > in preparation of the upcoming IETF meeting Barry and I would like > > to start a re-chartering discussion. We both are currently > > attending the Internet Identity Workshop and so we had the chance to > > solicit input from the participants. This should serve as a > > discussion starter. > > > > Potential future OAuth charter items (in random order): > > > > ---------------- > > > > 1) Dynamic Client Registration Protocol > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > > > 2) Token Revocation > > > > Available document: > > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > > > 3) UMA > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > > > 4) Client Instance Extension > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > > > 5) XML Encoding > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > > > 6) JSON Web Token > > > > Available document: > > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > > > 7) JSON Web Token (JWT) Bearer Profile > > > > Available document: > > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > > > 8) User Experience Extension > > > > Available document: > > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > > > 9) Request by Reference > > > > Available document: > > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > > > 10) Simple Web Discovery > > > > Available document: > > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > > > ---------------- > > > > We have the following questions: > > > > a) Are you interested in any of the above-listed items? (as a > > reviewer, co-author, implementer, or someone who would like to > > deploy). It is also useful to know if you think that we shouldn't > > work on a specific item. > > > > b) Are there other items you would like to see the group working on? > > > > Note: In case your document is expired please re-submit it. > > > > Ciao > > Hannes & Barry > > > > _______________________________________________ > > 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 > --0016e68deb79cb9bd804b0279e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is separating this out into 2 different tokens, really the best way to= solve your use case?

It sounds to me that you sim= ply want to track/log the two types of accesses differently, which can be d= one entirely outside of the oauth2 process.
Just bucket your operations into two piles internally and track approp= riately (which you would have to do anyway with scopes).

Scopes are the specific access that the end user grants to a 3rd par= ty to access their protected resources.

When an application, to use your example, asks for the = scope "protected confidential", they are providing those two leve= ls of access to the 3rd party application. If the user says "allow&quo= t;, then that application has all the access that those two scopes provides= .

Rather than getting applications to then further choose= between two tokens to simply=A0delineate two sets of operations seems like= the wrong place to be doing this.
i.e., why does the 3rd party a= pplication have to choose which token to use for each set of operations? - = the user has already granted both. The resource server can do whatever trac= king/logging it wants based on the actual operations requested - using the = single token in this case.

Regards,
Dave

On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <= ;dan.taflin@gettyimages.com> wrote:
I would like to second Torsten's pitch = for the ability to return multiple access tokens with a single authorizatio= n process. The use case for my company is to segment operations into two ma= in categories: protected and confidential. (A possible third category, publ= ic, would not require any authorization at all). Protected operations would= be user-specific operations that don't involve the passing of any sens= itive information, such as image search results tagged with information abo= ut whether each image is available for download by that user. Confidential = operations would involve passing user data, like user registration or e-com= merce. We would like to protect each category of operations with distinct t= okens: a general-use token for protected operations, and a secure token for= confidential operations.

We could use the scope parameter to specify either "protected" or= "confidential". Currently the oauth spec allows a Refresh token = to request a new token with reduced scope from the one originally issued, b= ut there is no way to obtain a new token with a completely different scope = without doing the full oauth dance a second time.

Dan

-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, October 20, 2011 3:57 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

Hi all,

my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard protocol,
such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is
missing from my point of view and explain some thoughts how to fill
the gaps.

A standard protocol is defined in terms of resource types and messages
by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many
places, and used by different but deployment-independent clients.
OAuth-based protocol specifications must also define scope values
(e.g. read, write, send) and their relation to the resource types and
messages. The different deployments expose the standard protocol on
different resource server endpoints. In my opinion, it is fundamental
to clearly distinguish scope values (standardized, static) and
resource server addresses (deployment specific) and to manage their
relationships. The current scope definition is much to weak and
insufficient. Probably, the UMA concepts of hosts, resources sets, and
corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider
before they are deployed. Would you really expect IMAP clients, e.g.
Thunderbird, to register with any a-Mail services upfront? So clients
should be given a way to register dynamically to the authorization
servers. This should also allow us to cover "client instance" asp= ects.
It is interesting to note, that such a mechanism would allow us to get
rid of secret-less clients and the one-time usage requirement for
authorization codes.

We also assume the client to know the URLs of the resource server and
the corresponding authorization server and to use HTTPS server
authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover
the authorization server a particular resource server relies on at
runtime. The discovery mechanism could be specified by the OAuth WG,
but could also be part of an application protocols specification. But
we MUST find another way to prevent token phishing by counterfeit
resource servers.

As one approach, the client could pass the (previously HTTPS
validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown
(counterfeit) resource servers. Such an additional parameter could
also serve as namespace for scope values and enable service providers
to run multiple instances of the same service within a single
deployment.

If the additional data enlarges the request payload to much, we could
consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard
protocols and we will see plenty of deployments with a bunch of
different OAuth protected resource servers. Shall this servers all be
accessible with a single token? In my opinion, this would cause
security, privacy and/or scalability/performance problems. To give
just the most obvious example, the target audience of such a token
cannot be restricted enough, which may allow a resource server (or an
attacker in control of it) to abuse the token on other servers. But
the current design of the code grant type forces deployments to use
the same token for all services. What is needed from my point of view
is a way to request and issue multiple server-specific access tokens
with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at
Deutsche Telekom needed and implemented this function on top of the
existing core. In my opinion, a core enhancement would be easier to
handle and more powerful. If others support this topic, I would be
willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should
be given the opportunity to implement their service by utilizing
standard server implementations. This creates the challenge to find a
standardized protocol between authorization server and resource server
to exchange authorization data. Depending on the token design
(self-contained vs. handle) this could be solved by either
standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o
I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in
some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration
=A01) Dynamic Client Registration Protocol
=A04) Client Instance Extension
- Discovery
=A0(10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
=A0(depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:

> Hi all,
>
> in preparation of the upcoming IETF meeting Barry and I would like
> to start a re-chartering discussion. =A0We both are currently
> attending the Internet Identity Workshop and so we had the chance to > solicit input from the participants. This should serve as a
> discussion starter.
>
> Potential future OAuth charter items (in random order):
>
> ----------------
>
> 1) Dynamic Client Registration Protocol
>
> Available document:
> http://datatracker.ietf.org/doc/draft-hardjono-oauth-d= ynreg/
>
> 2) Token Revocation
>
> Available document:
> http://datatracker.ietf.org/doc/draft-lodderste= dt-oauth-revocation/
>
> 3) UMA
>
> Available document:
> http://datatracker.ietf.org/doc/draft-hardjono-oauth-= umacore/
>
> 4) Client Instance Extension
>
> Available document:
> http://tools.ietf.org/id/draft-richer-oauth-instance-00= .txt
>
> 5) XML Encoding
>
> Available document:
> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >
> 6) JSON Web Token
>
> Available document:
> http://tools.ietf.org/html/draft-jones-json-web-token-05
>
> 7) JSON Web Token (JWT) Bearer Profile
>
> Available document:
> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-= 00
>
> 8) User Experience Extension
>
> Available document:
> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
>
> 9) Request by Reference
>
> Available document:
> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00=
>
> 10) Simple Web Discovery
>
> Available document:
> http://tools.ietf.org/html/draft-jones-simple-web-di= scovery-00
>
> ----------------
>
> We have the following questions:
>
> a) Are you interested in any of the above-listed items? (as a
> reviewer, co-author, implementer, or someone who would like to
> deploy). It is also useful to know if you think that we shouldn't<= br> > work on a specific item.
>
> b) Are there other items you would like to see the group working on? >
> Note: In case your document is expired please re-submit it.
>
> Ciao
> Hannes & Barry
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e68deb79cb9bd804b0279e2f-- From dan.taflin@gettyimages.com Tue Oct 25 16:21:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADBD11E8082 for ; Tue, 25 Oct 2011 16:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw6QYgRWkpwW for ; Tue, 25 Oct 2011 16:21:04 -0700 (PDT) Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by ietfa.amsl.com (Postfix) with ESMTP id F0AE01F0C4B for ; Tue, 25 Oct 2011 16:21:03 -0700 (PDT) X-Env-Sender: dan.taflin@gettyimages.com X-Msg-Ref: server-11.tower-143.messagelabs.com!1319584866!92894834!1 X-Originating-IP: [216.169.250.56] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32325 invoked from network); 25 Oct 2011 23:21:06 -0000 Received: from london.webmail.gettyimages.com (HELO SEAPXCH10CAHT02.amer.gettywan.com) (216.169.250.56) by server-11.tower-143.messagelabs.com with AES128-SHA encrypted SMTP; 25 Oct 2011 23:21:06 -0000 Received: from SEAPXCH10MBX01.amer.gettywan.com ([fe80::f054:280d:92db:5fff]) by SEAPXCH10CAHT02.amer.gettywan.com ([::1]) with mapi id 14.01.0289.001; Tue, 25 Oct 2011 16:21:02 -0700 From: Dan Taflin To: Dave Rochwerger Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMj80/lXiDycBFuE2v7P/5IVRfpJWNqh8QgACBmAD//4tusA== Date: Tue, 25 Oct 2011 23:21:01 +0000 Message-ID: <429493818451304B84EC9A0797B5D8582385DD@SEAPXCH10MBX01.amer.gettywan.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.102.80] Content-Type: multipart/alternative; boundary="_000_429493818451304B84EC9A0797B5D8582385DDSEAPXCH10MBX01ame_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 23:21:10 -0000 --_000_429493818451304B84EC9A0797B5D8582385DDSEAPXCH10MBX01ame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You're right, if tracking was all we needed then a single token would suffi= ce. The reason for two tokens has more to do with the fact that we'd like t= o allow "protected" operations to be called over plain http. This opens up = the possibility of an attacker intercepting the token for his own nefarious= use. If the only thing that token gave him access to was relatively benign= operations like image search, it would be an acceptable risk (especially i= f we have a relatively short lifespan for the token). In contrast, "confidential" operations would only be callable over https. B= y requiring a different token for them (and not allowing that token to be u= sed for unprotected operations) we prevent it from being intercepted. This = design intentionally mimics the way secure and non-secure http cookies work= . Oauth today basically requires https for all bearer token implementations. = I would like to see this relaxed somewhat. Dan From: Dave Rochwerger [mailto:daver@quizlet.com] Sent: Tuesday, October 25, 2011 4:08 PM To: Dan Taflin Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering Is separating this out into 2 different tokens, really the best way to solv= e your use case? It sounds to me that you simply want to track/log the two types of accesses= differently, which can be done entirely outside of the oauth2 process. Just bucket your operations into two piles internally and track appropriate= ly (which you would have to do anyway with scopes). Scopes are the specific access that the end user grants to a 3rd party to a= ccess their protected resources. When an application, to use your example, asks for the scope "protected con= fidential", they are providing those two levels of access to the 3rd party = application. If the user says "allow", then that application has all the ac= cess that those two scopes provides. Rather than getting applications to then further choose between two tokens = to simply delineate two sets of operations seems like the wrong place to be= doing this. i.e., why does the 3rd party application have to choose which token to use = for each set of operations? - the user has already granted both. The resour= ce server can do whatever tracking/logging it wants based on the actual ope= rations requested - using the single token in this case. Regards, Dave On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin > wrote: I would like to second Torsten's pitch for the ability to return multiple a= ccess tokens with a single authorization process. The use case for my compa= ny is to segment operations into two main categories: protected and confide= ntial. (A possible third category, public, would not require any authorizat= ion at all). Protected operations would be user-specific operations that do= n't involve the passing of any sensitive information, such as image search = results tagged with information about whether each image is available for d= ownload by that user. Confidential operations would involve passing user da= ta, like user registration or e-commerce. We would like to protect each cat= egory of operations with distinct tokens: a general-use token for protected= operations, and a secure token for confidential operations. We could use the scope parameter to specify either "protected" or "confiden= tial". Currently the oauth spec allows a Refresh token to request a new tok= en with reduced scope from the one originally issued, but there is no way t= o obtain a new token with a completely different scope without doing the fu= ll oauth dance a second time. Dan -----Original Message----- From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Thursday, October 20, 2011 3:57 PM To: Hannes Tschofenig Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering Hi all, my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes. We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers. As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment. If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal. Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process. I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution. If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API. Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *): - Revocation (low hanging fruit since I-D is ready and implemented in some places) - Resource server notion* - Multiple access tokens* - Dynamic client registration 1) Dynamic Client Registration Protocol 4) Client Instance Extension - Discovery (10) Simple Web Discovery, probably other specs as well - (6) JSON Web Token - (7) JSON Web Token (JWT) Bearer Profile - 8) User Experience Extension - Device flow - 9) Request by Reference (depending resource server notion and multiple access tokens) regards, Torsten. Zitat von Hannes Tschofenig >: > Hi all, > > in preparation of the upcoming IETF meeting Barry and I would like > to start a re-chartering discussion. We both are currently > attending the Internet Identity Workshop and so we had the chance to > solicit input from the participants. This should serve as a > discussion starter. > > Potential future OAuth charter items (in random order): > > ---------------- > > 1) Dynamic Client Registration Protocol > > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > 2) Token Revocation > > Available document: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > 3) UMA > > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > 4) Client Instance Extension > > Available document: > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > 5) XML Encoding > > Available document: > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > 6) JSON Web Token > > Available document: > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > 7) JSON Web Token (JWT) Bearer Profile > > Available document: > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > 8) User Experience Extension > > Available document: > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > 9) Request by Reference > > Available document: > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > 10) Simple Web Discovery > > Available document: > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > ---------------- > > We have the following questions: > > a) Are you interested in any of the above-listed items? (as a > reviewer, co-author, implementer, or someone who would like to > deploy). It is also useful to know if you think that we shouldn't > work on a specific item. > > b) Are there other items you would like to see the group working on? > > Note: In case your document is expired please re-submit it. > > Ciao > Hannes & Barry > > _______________________________________________ > 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_429493818451304B84EC9A0797B5D8582385DDSEAPXCH10MBX01ame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You’re right, if tracking was all we needed then a sin= gle token would suffice. The reason for two tokens has more to do with the = fact that we’d like to allow “protected” operations to be called over plain http. This open= s up the possibility of an attacker intercepting the token for his own nefa= rious use. If the only thing that token gave him access to was relatively b= enign operations like image search, it would be an acceptable risk (especially if we have a relatively short lifespan f= or the token).

 

In contrast, “confidential” operations would onl= y be callable over https. By requiring a different token for them (and not = allowing that token to be used for unprotected operations) we prevent it from being intercepted. This des= ign intentionally mimics the way secure and non-secure http cookies work.

 

Oauth today basically requires https for all bearer token im= plementations. I would like to see this relaxed somewhat.=

 

Dan

 

From: Dave Roc= hwerger [mailto:daver@quizlet.com]
Sent: Tuesday, October 25, 2011 4:08 PM
To: Dan Taflin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

 

Is separating this out into 2 different tokens, real= ly the best way to solve your use case?

 

It sounds to me that you simply want to track/log th= e two types of accesses differently, which can be done entirely outside of = the oauth2 process.

Just bucket your operations into two piles internall= y and track appropriately (which you would have to do anyway with scopes).<= o:p>

 

Scopes are the specific access that the end user gra= nts to a 3rd party to access their protected resources.

 

When an application, to use your example, asks for t= he scope "protected confidential", they are providing those two l= evels of access to the 3rd party application. If the user says "allow&= quot;, then that application has all the access that those two scopes provides.

 

Rather than getting applications to then further cho= ose between two tokens to simply delineate two sets of operations seem= s like the wrong place to be doing this.

i.e., why does the 3rd party application have to cho= ose which token to use for each set of operations? - the user has already g= ranted both. The resource server can do whatever tracking/logging it wants = based on the actual operations requested - using the single token in this case.

 

Regards,

Dave

 

On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <dan.taflin@gettyimages.com>= ; wrote:

I would like to second Torsten's pitch for the abili= ty to return multiple access tokens with a single authorization process. Th= e use case for my company is to segment operations into two main categories= : protected and confidential. (A possible third category, public, would not require any authorization at all). Prote= cted operations would be user-specific operations that don't involve the pa= ssing of any sensitive information, such as image search results tagged wit= h information about whether each image is available for download by that user. Confidential operations woul= d involve passing user data, like user registration or e-commerce. We would= like to protect each category of operations with distinct tokens: a genera= l-use token for protected operations, and a secure token for confidential operations.

We could use the scope parameter to specify either "protected" or= "confidential". Currently the oauth spec allows a Refresh token = to request a new token with reduced scope from the one originally issued, b= ut there is no way to obtain a new token with a completely different scope without doing the full oauth dance a second time.

Dan


-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, October 20, 2011 3:57 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

Hi all,

my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard protocol,
such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is
missing from my point of view and explain some thoughts how to fill
the gaps.

A standard protocol is defined in terms of resource types and messages
by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many
places, and used by different but deployment-independent clients.
OAuth-based protocol specifications must also define scope values
(e.g. read, write, send) and their relation to the resource types and
messages. The different deployments expose the standard protocol on
different resource server endpoints. In my opinion, it is fundamental
to clearly distinguish scope values (standardized, static) and
resource server addresses (deployment specific) and to manage their
relationships. The current scope definition is much to weak and
insufficient. Probably, the UMA concepts of hosts, resources sets, and
corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider
before they are deployed. Would you really expect IMAP clients, e.g.
Thunderbird, to register with any a-Mail services upfront? So clients
should be given a way to register dynamically to the authorization
servers. This should also allow us to cover "client instance" asp= ects.
It is interesting to note, that such a mechanism would allow us to get
rid of secret-less clients and the one-time usage requirement for
authorization codes.

We also assume the client to know the URLs of the resource server and
the corresponding authorization server and to use HTTPS server
authentication to verify the resource server's authenticity. This is
impossible in the standard scenario. Clients must be able to discover
the authorization server a particular resource server relies on at
runtime. The discovery mechanism could be specified by the OAuth WG,
but could also be part of an application protocols specification. But
we MUST find another way to prevent token phishing by counterfeit
resource servers.

As one approach, the client could pass the (previously HTTPS
validated) resource server's URL with the authorization request. The
authorization server should then refuse such requests for any unknown
(counterfeit) resource servers. Such an additional parameter could
also serve as namespace for scope values and enable service providers
to run multiple instances of the same service within a single
deployment.

If the additional data enlarges the request payload to much, we could
consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard
protocols and we will see plenty of deployments with a bunch of
different OAuth protected resource servers. Shall this servers all be
accessible with a single token? In my opinion, this would cause
security, privacy and/or scalability/performance problems. To give
just the most obvious example, the target audience of such a token
cannot be restricted enough, which may allow a resource server (or an
attacker in control of it) to abuse the token on other servers. But
the current design of the code grant type forces deployments to use
the same token for all services. What is needed from my point of view
is a way to request and issue multiple server-specific access tokens
with a single authorization process.

I've been advocating this topic for a long time now and I'm still
convinced this is required to really complete the core design. We at
Deutsche Telekom needed and implemented this function on top of the
existing core. In my opinion, a core enhancement would be easier to
handle and more powerful. If others support this topic, I would be
willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should
be given the opportunity to implement their service by utilizing
standard server implementations. This creates the challenge to find a
standardized protocol between authorization server and resource server
to exchange authorization data. Depending on the token design
(self-contained vs. handle) this could be solved by either
standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o
I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in
some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration
 1) Dynamic Client Registration Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:

> Hi all,
>
> in preparation of the upcoming IETF meeting Barry and I would like
> to start a re-chartering discussion.  We both are currently
> attending the Internet Identity Workshop and so we had the chance to > solicit input from the participants. This should serve as a
> discussion starter.
>
> Potential future OAuth charter items (in random order):
>
> ----------------
>
> 1) Dynamic Client Registration Protocol
>
> Available document:
> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/
>
> 2) Token Revocation
>
> Available document:
> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
>
> 3) UMA
>
> Available document:
> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
>
> 4) Client Instance Extension
>
> Available document:
> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt
>
> 5) XML Encoding
>
> Available document:
> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt
>
> 6) JSON Web Token
>
> Available document:
> http://tools.ietf.org/html/draft-jones-json-web-token-05
>
> 7) JSON Web Token (JWT) Bearer Profile
>
> Available document:
> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00
>
> 8) User Experience Extension
>
> Available document:
> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
>
> 9) Request by Reference
>
> Available document:
> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00
>
> 10) Simple Web Discovery
>
> Available document:
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00
>
> ----------------
>
> We have the following questions:
>
> a) Are you interested in any of the above-listed items? (as a
> reviewer, co-author, implementer, or someone who would like to
> deploy). It is also useful to know if you think that we shouldn't
> work on a specific item.
>
> b) Are there other items you would like to see the group working on? >
> Note: In case your document is expired please re-submit it.
>
> Ciao
> Hannes & Barry
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

--_000_429493818451304B84EC9A0797B5D8582385DDSEAPXCH10MBX01ame_-- From daver@quizlet.com Tue Oct 25 16:33:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5115911E80D6 for ; Tue, 25 Oct 2011 16:33:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k33+ew+6IZDs for ; Tue, 25 Oct 2011 16:33:28 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3767F11E80F5 for ; Tue, 25 Oct 2011 16:33:28 -0700 (PDT) Received: by ggnv1 with SMTP id v1so1164157ggn.31 for ; Tue, 25 Oct 2011 16:33:27 -0700 (PDT) Received: by 10.236.156.71 with SMTP id l47mr18890445yhk.130.1319585606528; Tue, 25 Oct 2011 16:33:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id d63sm40710862yhl.10.2011.10.25.16.33.23 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 16:33:25 -0700 (PDT) Received: by gyh20 with SMTP id 20so1172704gyh.31 for ; Tue, 25 Oct 2011 16:33:23 -0700 (PDT) Received: by 10.101.21.15 with SMTP id y15mr6748511ani.21.1319585603412; Tue, 25 Oct 2011 16:33:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.3.11 with HTTP; Tue, 25 Oct 2011 16:33:03 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: <429493818451304B84EC9A0797B5D8582385DD@SEAPXCH10MBX01.amer.gettywan.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <429493818451304B84EC9A0797B5D8582385DD@SEAPXCH10MBX01.amer.gettywan.com> From: Dave Rochwerger Date: Tue, 25 Oct 2011 16:33:03 -0700 Message-ID: To: Dan Taflin Content-Type: multipart/alternative; boundary=00504501755e24642c04b027f7ed Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 23:33:30 -0000 --00504501755e24642c04b027f7ed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan, I think we are going down the wrong path here. Basically, you've started with the premise of wanting plain HTTP scheme (in some circumstances), which has caused you to suggest both of, firstly, relaxing the only method of encryption in oauth2 and secondly, to further complicate the protocol by allowing multiple tokens to be returned. OAuth2 (unlike version 1) has no signatures or other encryption - it relies solely on SSL. Therefore any relaxation of this requirement breaks security wide open (even in your specific short-term token case). I think you're asking the wrong question. We should not ask "to relax the SSL requirement", but rather - Why do you not want to use SSL? With today's computer speeds, there is no reason not to use SSL. The plain HTTP scheme does not really provide a noticeable enough performance boost. On a side note, if the likes of Google's SPDY is anything to go by, the future might always be SSL only anyway. Cheers, Dave On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin wro= te: > You=92re right, if tracking was all we needed then a single token would > suffice. The reason for two tokens has more to do with the fact that we= =92d > like to allow =93protected=94 operations to be called over plain http. Th= is > opens up the possibility of an attacker intercepting the token for his ow= n > nefarious use. If the only thing that token gave him access to was > relatively benign operations like image search, it would be an acceptable > risk (especially if we have a relatively short lifespan for the token).**= * > * > > ** ** > > In contrast, =93confidential=94 operations would only be callable over ht= tps. > By requiring a different token for them (and not allowing that token to b= e > used for unprotected operations) we prevent it from being intercepted. Th= is > design intentionally mimics the way secure and non-secure http cookies wo= rk. > **** > > ** ** > > Oauth today basically requires https for all bearer token implementations= . > I would like to see this relaxed somewhat.**** > > ** ** > > Dan**** > > ** ** > > *From:* Dave Rochwerger [mailto:daver@quizlet.com] > *Sent:* Tuesday, October 25, 2011 4:08 PM > *To:* Dan Taflin > > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Rechartering**** > > ** ** > > Is separating this out into 2 different tokens, really the best way to > solve your use case?**** > > ** ** > > It sounds to me that you simply want to track/log the two types of access= es > differently, which can be done entirely outside of the oauth2 process.***= * > > Just bucket your operations into two piles internally and track > appropriately (which you would have to do anyway with scopes).**** > > ** ** > > Scopes are the specific access that the end user grants to a 3rd party to > access their protected resources.**** > > ** ** > > When an application, to use your example, asks for the scope "protected > confidential", they are providing those two levels of access to the 3rd > party application. If the user says "allow", then that application has al= l > the access that those two scopes provides.**** > > ** ** > > Rather than getting applications to then further choose between two token= s > to simply delineate two sets of operations seems like the wrong place to = be > doing this.**** > > i.e., why does the 3rd party application have to choose which token to us= e > for each set of operations? - the user has already granted both. The > resource server can do whatever tracking/logging it wants based on the > actual operations requested - using the single token in this case.**** > > ** ** > > Regards,**** > > Dave**** > > ** ** > > On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin > wrote:**** > > I would like to second Torsten's pitch for the ability to return multiple > access tokens with a single authorization process. The use case for my > company is to segment operations into two main categories: protected and > confidential. (A possible third category, public, would not require any > authorization at all). Protected operations would be user-specific > operations that don't involve the passing of any sensitive information, s= uch > as image search results tagged with information about whether each image = is > available for download by that user. Confidential operations would involv= e > passing user data, like user registration or e-commerce. We would like to > protect each category of operations with distinct tokens: a general-use > token for protected operations, and a secure token for confidential > operations. > > We could use the scope parameter to specify either "protected" or > "confidential". Currently the oauth spec allows a Refresh token to reques= t a > new token with reduced scope from the one originally issued, but there is= no > way to obtain a new token with a completely different scope without doing > the full oauth dance a second time. > > Dan**** > > > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Thursday, October 20, 2011 3:57 PM > To: Hannes Tschofenig > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering**** > > Hi all, > > my prioritization is driven by the goal to make OAuth the > authorization framework of choice for any internet standard protocol, > such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is > missing from my point of view and explain some thoughts how to fill > the gaps. > > A standard protocol is defined in terms of resource types and messages > by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many > places, and used by different but deployment-independent clients. > OAuth-based protocol specifications must also define scope values > (e.g. read, write, send) and their relation to the resource types and > messages. The different deployments expose the standard protocol on > different resource server endpoints. In my opinion, it is fundamental > to clearly distinguish scope values (standardized, static) and > resource server addresses (deployment specific) and to manage their > relationships. The current scope definition is much to weak and > insufficient. Probably, the UMA concepts of hosts, resources sets, and > corresponding scopes could be adopted for that purpose. > > OAuth today requires clients to register with the service provider > before they are deployed. Would you really expect IMAP clients, e.g. > Thunderbird, to register with any a-Mail services upfront? So clients > should be given a way to register dynamically to the authorization > servers. This should also allow us to cover "client instance" aspects. > It is interesting to note, that such a mechanism would allow us to get > rid of secret-less clients and the one-time usage requirement for > authorization codes. > > We also assume the client to know the URLs of the resource server and > the corresponding authorization server and to use HTTPS server > authentication to verify the resource server's authenticity. This is > impossible in the standard scenario. Clients must be able to discover > the authorization server a particular resource server relies on at > runtime. The discovery mechanism could be specified by the OAuth WG, > but could also be part of an application protocols specification. But > we MUST find another way to prevent token phishing by counterfeit > resource servers. > > As one approach, the client could pass the (previously HTTPS > validated) resource server's URL with the authorization request. The > authorization server should then refuse such requests for any unknown > (counterfeit) resource servers. Such an additional parameter could > also serve as namespace for scope values and enable service providers > to run multiple instances of the same service within a single > deployment. > > If the additional data enlarges the request payload to much, we could > consider to adopt the "request by reference" proposal. > > Let's now assume, OAuth is successful in the world of standard > protocols and we will see plenty of deployments with a bunch of > different OAuth protected resource servers. Shall this servers all be > accessible with a single token? In my opinion, this would cause > security, privacy and/or scalability/performance problems. To give > just the most obvious example, the target audience of such a token > cannot be restricted enough, which may allow a resource server (or an > attacker in control of it) to abuse the token on other servers. But > the current design of the code grant type forces deployments to use > the same token for all services. What is needed from my point of view > is a way to request and issue multiple server-specific access tokens > with a single authorization process. > > I've been advocating this topic for a long time now and I'm still > convinced this is required to really complete the core design. We at > Deutsche Telekom needed and implemented this function on top of the > existing core. In my opinion, a core enhancement would be easier to > handle and more powerful. If others support this topic, I would be > willed to submit an I-D describing a possible solution. > > If we take standards really seriously, then service providers should > be given the opportunity to implement their service by utilizing > standard server implementations. This creates the challenge to find a > standardized protocol between authorization server and resource server > to exchange authorization data. Depending on the token design > (self-contained vs. handle) this could be solved by either > standardizing a token format (JWT) or an authorization API. > > Based on the rationale given above, my list is as follows (topics w/o > I-D are marked with *): > > - Revocation (low hanging fruit since I-D is ready and implemented in > some places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) > > regards, > Torsten. > Zitat von Hannes Tschofenig : > > > Hi all, > > > > in preparation of the upcoming IETF meeting Barry and I would like > > to start a re-chartering discussion. We both are currently > > attending the Internet Identity Workshop and so we had the chance to > > solicit input from the participants. This should serve as a > > discussion starter. > > > > Potential future OAuth charter items (in random order): > > > > ---------------- > > > > 1) Dynamic Client Registration Protocol > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > > > 2) Token Revocation > > > > Available document: > > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > > > 3) UMA > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > > > 4) Client Instance Extension > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > > > 5) XML Encoding > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > > > 6) JSON Web Token > > > > Available document: > > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > > > 7) JSON Web Token (JWT) Bearer Profile > > > > Available document: > > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > > > 8) User Experience Extension > > > > Available document: > > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > > > 9) Request by Reference > > > > Available document: > > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > > > 10) Simple Web Discovery > > > > Available document: > > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > > > ---------------- > > > > We have the following questions: > > > > a) Are you interested in any of the above-listed items? (as a > > reviewer, co-author, implementer, or someone who would like to > > deploy). It is also useful to know if you think that we shouldn't > > work on a specific item. > > > > b) Are there other items you would like to see the group working on? > > > > Note: In case your document is expired please re-submit it. > > > > Ciao > > Hannes & Barry > > > > _______________________________________________ > > 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**** > > ** ** > --00504501755e24642c04b027f7ed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan,

I think we are going down the wrong path here.
Basically, you've started with the premise of wanting plain HT= TP scheme (in some circumstances), which has caused you to suggest both of,= firstly, relaxing the only method of encryption in oauth2 and secondly, to= further complicate the protocol by allowing=A0multiple=A0tokens to be retu= rned.

OAuth2 (unlike version 1) has no signatures or other en= cryption - it relies solely on SSL. Therefore any relaxation of this requir= ement breaks security wide open (even in your specific short-term token cas= e).

I think you're asking the wrong question.

We should not ask "to relax the SSL requirement",= but rather - Why do you not want to use SSL?

With today's computer speeds, there is no reason not to use SSL. The pl= ain HTTP scheme does not really provide a=A0noticeable=A0enough performance= boost.=A0On a side note, if the likes of Google's SPDY is anything to = go by, the future might always be SSL only anyway.

Cheers,
Dave

On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin <dan.taflin@gettyimages.com> wrote:

You= =92re right, if tracking was all we needed then a single token would suffic= e. The reason for two tokens has more to do with the fact that we=92d like = to allow =93protected=94 operations to be called over plain http. This opens up the= possibility of an attacker intercepting the token for his own nefarious us= e. If the only thing that token gave him access to was relatively benign op= erations like image search, it would be an acceptable risk (especially if we have a relatively short lifespan f= or the token).

=A0

In co= ntrast, =93confidential=94 operations would only be callable over https. By= requiring a different token for them (and not allowing that token to be us= ed for unprotected operations) we prevent it from being intercepted. This des= ign intentionally mimics the way secure and non-secure http cookies work.

=A0

Oauth= today basically requires https for all bearer token implementations. I wou= ld like to see this relaxed somewhat.

=A0

Dan

=A0

From:= Dave Rochwerger [mailto:daver@quizlet.com]
Sent: Tuesday, October 25, 2011 4:08 PM
To: Dan Taflin


Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

=A0

Is separating this out into 2 different tokens, real= ly the best way to solve your use case?

=A0

It sounds to me that you simply want to track/log th= e two types of accesses differently, which can be done entirely outside of = the oauth2 process.

Just bucket your operations into two piles internall= y and track appropriately (which you would have to do anyway with scopes).<= u>

=A0

Scopes are the specific access that the end user gra= nts to a 3rd party to access their protected resources.

=A0

When an application, to use your example, asks for t= he scope "protected confidential", they are providing those two l= evels of access to the 3rd party application. If the user says "allow&= quot;, then that application has all the access that those two scopes provides.

=A0

Rather than getting applications to then further cho= ose between two tokens to simply=A0delineate two sets of operations seems l= ike the wrong place to be doing this.

i.e., why does the 3rd party application have to cho= ose which token to use for each set of operations? - the user has already g= ranted both. The resource server can do whatever tracking/logging it wants = based on the actual operations requested - using the single token in this case.

=A0

Regards,

Dave

=A0

On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <dan.taflin@gett= yimages.com> wrote:

I would like to second Torsten's pitch for the a= bility to return multiple access tokens with a single authorization process= . The use case for my company is to segment operations into two main catego= ries: protected and confidential. (A possible third category, public, would not require any authorization at all). Prote= cted operations would be user-specific operations that don't involve th= e passing of any sensitive information, such as image search results tagged= with information about whether each image is available for download by that user. Confidential operations woul= d involve passing user data, like user registration or e-commerce. We would= like to protect each category of operations with distinct tokens: a genera= l-use token for protected operations, and a secure token for confidential operations.

We could use the scope parameter to specify either "protected" or= "confidential". Currently the oauth spec allows a Refresh token = to request a new token with reduced scope from the one originally issued, b= ut there is no way to obtain a new token with a completely different scope without doing the full oauth dance a second time.

Dan


-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, October 20, 2011 3:57 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

Hi all,

my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard protocol,
such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is
missing from my point of view and explain some thoughts how to fill
the gaps.

A standard protocol is defined in terms of resource types and messages
by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many
places, and used by different but deployment-independent clients.
OAuth-based protocol specifications must also define scope values
(e.g. read, write, send) and their relation to the resource types and
messages. The different deployments expose the standard protocol on
different resource server endpoints. In my opinion, it is fundamental
to clearly distinguish scope values (standardized, static) and
resource server addresses (deployment specific) and to manage their
relationships. The current scope definition is much to weak and
insufficient. Probably, the UMA concepts of hosts, resources sets, and
corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider
before they are deployed. Would you really expect IMAP clients, e.g.
Thunderbird, to register with any a-Mail services upfront? So clients
should be given a way to register dynamically to the authorization
servers. This should also allow us to cover "client instance" asp= ects.
It is interesting to note, that such a mechanism would allow us to get
rid of secret-less clients and the one-time usage requirement for
authorization codes.

We also assume the client to know the URLs of the resource server and
the corresponding authorization server and to use HTTPS server
authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover
the authorization server a particular resource server relies on at
runtime. The discovery mechanism could be specified by the OAuth WG,
but could also be part of an application protocols specification. But
we MUST find another way to prevent token phishing by counterfeit
resource servers.

As one approach, the client could pass the (previously HTTPS
validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown
(counterfeit) resource servers. Such an additional parameter could
also serve as namespace for scope values and enable service providers
to run multiple instances of the same service within a single
deployment.

If the additional data enlarges the request payload to much, we could
consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard
protocols and we will see plenty of deployments with a bunch of
different OAuth protected resource servers. Shall this servers all be
accessible with a single token? In my opinion, this would cause
security, privacy and/or scalability/performance problems. To give
just the most obvious example, the target audience of such a token
cannot be restricted enough, which may allow a resource server (or an
attacker in control of it) to abuse the token on other servers. But
the current design of the code grant type forces deployments to use
the same token for all services. What is needed from my point of view
is a way to request and issue multiple server-specific access tokens
with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at
Deutsche Telekom needed and implemented this function on top of the
existing core. In my opinion, a core enhancement would be easier to
handle and more powerful. If others support this topic, I would be
willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should
be given the opportunity to implement their service by utilizing
standard server implementations. This creates the challenge to find a
standardized protocol between authorization server and resource server
to exchange authorization data. Depending on the token design
(self-contained vs. handle) this could be solved by either
standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o
I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in
some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration
=A01) Dynamic Client Registration Protocol
=A04) Client Instance Extension
- Discovery
=A0(10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
=A0(depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:

> Hi all,
>
> in preparation of the upcoming IETF meeting Barry and I would like
> to start a re-chartering discussion. =A0We both are currently
> attending the Internet Identity Workshop and so we had the chance to > solicit input from the participants. This should serve as a
> discussion starter.
>
> Potential future OAuth charter items (in random order):
>
> ----------------
>
> 1) Dynamic Client Registration Protocol
>
> Available document:
> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/
>
> 2) Token Revocation
>
> Available document:
> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
>
> 3) UMA
>
> Available document:
> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
>
> 4) Client Instance Extension
>
> Available document:
> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt
>
> 5) XML Encoding
>
> Available document:
> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt
>
> 6) JSON Web Token
>
> Available document:
> http://tools.ietf.org/html/draft-jones-json-web-token-05
>
> 7) JSON Web Token (JWT) Bearer Profile
>
> Available document:
> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00
>
> 8) User Experience Extension
>
> Available document:
> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
>
> 9) Request by Reference
>
> Available document:
> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00
>
> 10) Simple Web Discovery
>
> Available document:
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00
>
> ----------------
>
> We have the following questions:
>
> a) Are you interested in any of the above-listed items? (as a
> reviewer, co-author, implementer, or someone who would like to
> deploy). It is also useful to know if you think that we shouldn't<= br> > work on a specific item.
>
> b) Are there other items you would like to see the group working on? >
> Note: In case your document is expired please re-submit it.
>
> Ciao
> Hannes & Barry
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0


--00504501755e24642c04b027f7ed-- From bob@veznat.com Tue Oct 25 20:41:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D1721F8B83 for ; Tue, 25 Oct 2011 20:41:31 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqIEWnjf7u0C for ; Tue, 25 Oct 2011 20:41:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B478D21F8B81 for ; Tue, 25 Oct 2011 20:41:26 -0700 (PDT) Received: by wyh22 with SMTP id 22so1423830wyh.31 for ; Tue, 25 Oct 2011 20:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=veznat.com; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type; bh=yp6EhfrIEXPyEHq42n7/c+r7u+Ex9iznXhmEo6psRHU=; b=WMdF/pCH1TYh/hvuh06T8ANd8ByqQxBnvxJM2CEf8XJcEN2929YL4grjERCM5w8OQ7 H+AdN5tO+D7OM13TB4BNHHUnkqjxZpPnSWDsu5Ai4cclxIo794nvUM99Mta8HKBkdq5j 7oJoQoHcXjnxz7lG20G6rJpFxjJ1DZ3Rbh/Dk= MIME-Version: 1.0 Received: by 10.216.24.9 with SMTP id w9mr375857wew.2.1319600485785; Tue, 25 Oct 2011 20:41:25 -0700 (PDT) Received: by 10.216.22.77 with HTTP; Tue, 25 Oct 2011 20:41:25 -0700 (PDT) X-Originating-IP: [24.5.12.71] Date: Tue, 25 Oct 2011 20:41:25 -0700 Message-ID: From: Bob Van Zant To: Dave Rochwerger Content-Type: multipart/alternative; boundary=001485f03806335f6504b02b6ecd Cc: OAuth WG , Dan Taflin Subject: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 03:41:31 -0000 --001485f03806335f6504b02b6ecd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm going to reiterate what has already been said. OAuth already supports what you're trying to do. Just request a token twice= , the first time request it with a scope or scopes that allows these special operations. The second time request it with a scope or scopes that do not. In general I really like how simple OAuth 2 is. By working within the constraints of this simplicity we can keep the protocol simple and easy to use. -Bob On Tuesday, October 25, 2011, Dave Rochwerger wrote: > Hi Dan, > I think we are going down the wrong path here. > Basically, you've started with the premise of wanting plain HTTP scheme (in some circumstances), which has caused you to suggest both of, firstly, relaxing the only method of encryption in oauth2 and secondly, to further complicate the protocol by allowing multiple tokens to be returned. > OAuth2 (unlike version 1) has no signatures or other encryption - it relies solely on SSL. Therefore any relaxation of this requirement breaks security wide open (even in your specific short-term token case). > I think you're asking the wrong question. > We should not ask "to relax the SSL requirement", but rather - Why do you not want to use SSL? > With today's computer speeds, there is no reason not to use SSL. The plai= n HTTP scheme does not really provide a noticeable enough performance boost. On a side note, if the likes of Google's SPDY is anything to go by, the future might always be SSL only anyway. > Cheers, > Dave > > On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin wrote: > > You=92re right, if tracking was all we needed then a single token would suffice. The reason for two tokens has more to do with the fact that we=92d like to allow =93protected=94 operations to be called over plain http. This opens up the possibility of an attacker intercepting the token for his own nefarious use. If the only thing that token gave him access to was relatively benign operations like image search, it would be an acceptable risk (especially if we have a relatively short lifespan for the token). > > > > In contrast, =93confidential=94 operations would only be callable over ht= tps. By requiring a different token for them (and not allowing that token to be used for unprotected operations) we prevent it from being intercepted. This design intentionally mimics the way secure and non-secure http cookies work= . > > > > Oauth today basically requires https for all bearer token implementations= . I would like to see this relaxed somewhat. > > > > Dan > > > > From: Dave Rochwerger [mailto:daver@quizlet.com] > Sent: Tuesday, October 25, 2011 4:08 PM > To: Dan Taflin > > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering > > > > Is separating this out into 2 different tokens, really the best way to solve your use case? > > > > It sounds to me that you simply want to track/log the two types of accesses differently, which can be done entirely outside of the oauth2 process. > > Just bucket your operations into two piles internally and track appropriately (which you would have to do anyway with scopes). > > > > Scopes are the specific access that the end user grants to a 3rd party to access their protected resources. > > > > When an application, to use your example, asks for the scope "protected confidential", they are providing those two levels of access to the 3rd party application. If the user says "allow", then that application has all the access that those two scopes provides. > > > > Rather than getting applications to then further choose between two token= s to simply delineate two sets of operations seems like the wrong place to be doing this. > > i.e., why does the 3rd party application have to choose which token to us= e for each set of operations? - the user has already granted both. The resource server can do whatever tracking/logging it wants based on the actual operations requested - using the single token in this case. > > > > Regards, > > Dave > > > > On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin wrote: > > I would like to second Torsten's pitch for the ability to return multiple access tokens with a single authorization process. The use case for my company is to segment operatio --001485f03806335f6504b02b6ecd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm going to reiterate what has already been said.

OAuth alread= y supports what you're trying to do. Just request a token twice, the fi= rst time request it with a scope or scopes that allows these special operat= ions. The second time request it with a scope or scopes that do not.

In general I really like how simple OAuth 2 is. By working within the c= onstraints of this simplicity we can keep the protocol simple and easy to u= se.

-Bob

On Tuesday, October 25, 2011, Dave Rochwerger <<= a href=3D"mailto:daver@quizlet.com">daver@quizlet.com> wrote:
> Hi Dan,
> I think we are going down the wrong path here.
>= Basically, you've started with the premise of wanting plain HTTP schem= e (in some circumstances), which has caused you to suggest both of, firstly= , relaxing the only method of encryption in oauth2 and secondly, to further= complicate the protocol by allowing=A0multiple=A0tokens to be returned. > OAuth2 (unlike version 1) has no signatures or other encryption - it r= elies solely on SSL. Therefore any relaxation of this requirement breaks se= curity wide open (even in your specific short-term token case).
> I t= hink you're asking the wrong question.
> We should not ask "to relax the SSL requirement", but rather= - Why do you not want to use SSL?
> With today's computer speeds= , there is no reason not to use SSL. The plain HTTP scheme does not really = provide a=A0noticeable=A0enough performance boost.=A0On a side note, if the= likes of Google's SPDY is anything to go by, the future might always b= e SSL only anyway.
> Cheers,
> Dave
>
> On Tue, Oct 25, 2011 at 4:21 PM, = Dan Taflin <dan.taflin@get= tyimages.com> wrote:
>
> You=92re right, if tracking was= all we needed then a single token would suffice. The reason for two tokens= has more to do with the fact that we=92d like to allow =93protected=94 ope= rations to be called over plain http. This opens up the possibility of an a= ttacker intercepting the token for his own nefarious use. If the only thing= that token gave him access to was relatively benign operations like image = search, it would be an acceptable risk (especially if we have a relatively = short lifespan for the token).
>
> =A0
>
> In contrast, =93confidential=94 operations= would only be callable over https. By requiring a different token for them= (and not allowing that token to be used for unprotected operations) we pre= vent it from being intercepted. This design intentionally mimics the way se= cure and non-secure http cookies work.
>
> =A0
>
> Oauth today basically requires https for a= ll bearer token implementations. I would like to see this relaxed somewhat.=
>
> =A0
>
> Dan
>
> =A0
>
>= ; From: Dave Rochwerger [mailto:daver@= quizlet.com]
> Sent: Tuesday, October 25, 2011 4:08 PM
> To: Dan Taflin
>=
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
><= br>> =A0
>
> Is separating this out into 2 different tokens,= really the best way to solve your use case?
>
> =A0
>
> It sounds to me that you simply want to tr= ack/log the two types of accesses differently, which can be done entirely o= utside of the oauth2 process.
>
> Just bucket your operations i= nto two piles internally and track appropriately (which you would have to d= o anyway with scopes).
>
> =A0
>
> Scopes are the specific access that the en= d user grants to a 3rd party to access their protected resources.
>> =A0
>
> When an application, to use your example, asks f= or the scope "protected confidential", they are providing those t= wo levels of access to the 3rd party application. If the user says "al= low", then that application has all the access that those two scopes p= rovides.
>
> =A0
>
> Rather than getting applications to then f= urther choose between two tokens to simply=A0delineate two sets of operatio= ns seems like the wrong place to be doing this.
>
> i.e., why d= oes the 3rd party application have to choose which token to use for each se= t of operations? - the user has already granted both. The resource server c= an do whatever tracking/logging it wants based on the actual operations req= uested - using the single token in this case.
>
> =A0
>
> Regards,
>
> Dave
>
&= gt; =A0
>
> On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <dan.taflin@gettyimages.com&g= t; wrote:
>
> I would like to second Torsten's pitch for the ability to = return multiple access tokens with a single authorization process. The use = case for my company is to segment operatio --001485f03806335f6504b02b6ecd-- From eran@hueniverse.com Wed Oct 26 09:16:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5579B21F84C3 for ; Wed, 26 Oct 2011 09:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEl-y2CsmVJE for ; Wed, 26 Oct 2011 09:16:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 0C3BC21F84B6 for ; Wed, 26 Oct 2011 09:16:17 -0700 (PDT) Received: (qmail 30914 invoked from network); 26 Oct 2011 16:16:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Oct 2011 16:16:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 26 Oct 2011 09:15:57 -0700 From: Eran Hammer-Lahav To: Dan Taflin , OAuth WG Date: Wed, 26 Oct 2011 09:15:50 -0700 Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMj80/lXiDycBFuE2v7P/5IVRfpJWNqh8QgAErLjA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> In-Reply-To: <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> 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] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 16:16:19 -0000 Why not just ask for one access token with all the scopes you need, then re= fresh it by asking for the different subsets you want. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dan Taflin > Sent: Tuesday, October 25, 2011 3:37 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering >=20 > I would like to second Torsten's pitch for the ability to return multiple= access > tokens with a single authorization process. The use case for my company i= s to > segment operations into two main categories: protected and confidential. = (A > possible third category, public, would not require any authorization at a= ll). > Protected operations would be user-specific operations that don't involve > the passing of any sensitive information, such as image search results ta= gged > with information about whether each image is available for download by th= at > user. Confidential operations would involve passing user data, like user > registration or e-commerce. We would like to protect each category of > operations with distinct tokens: a general-use token for protected > operations, and a secure token for confidential operations. >=20 > We could use the scope parameter to specify either "protected" or > "confidential". Currently the oauth spec allows a Refresh token to reques= t a > new token with reduced scope from the one originally issued, but there is= no > way to obtain a new token with a completely different scope without doing > the full oauth dance a second time. >=20 > Dan >=20 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Thursday, October 20, 2011 3:57 PM > To: Hannes Tschofenig > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering >=20 > Hi all, >=20 > my prioritization is driven by the goal to make OAuth the authorization > framework of choice for any internet standard protocol, such as WebDAV, > IMAP, SMTP or SIP. So let me first explain what is missing from my point = of > view and explain some thoughts how to fill the gaps. >=20 > A standard protocol is defined in terms of resource types and messages by= a > body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and > used by different but deployment-independent clients. > OAuth-based protocol specifications must also define scope values (e.g. > read, write, send) and their relation to the resource types and messages.= The > different deployments expose the standard protocol on different resource > server endpoints. In my opinion, it is fundamental > to clearly distinguish scope values (standardized, static) and > resource server addresses (deployment specific) and to manage their > relationships. The current scope definition is much to weak and insuffici= ent. > Probably, the UMA concepts of hosts, resources sets, and corresponding > scopes could be adopted for that purpose. >=20 > OAuth today requires clients to register with the service provider before > they are deployed. Would you really expect IMAP clients, e.g. > Thunderbird, to register with any a-Mail services upfront? So clients sho= uld > be given a way to register dynamically to the authorization servers. This > should also allow us to cover "client instance" aspects. > It is interesting to note, that such a mechanism would allow us to get ri= d of > secret-less clients and the one-time usage requirement for authorization > codes. >=20 > We also assume the client to know the URLs of the resource server and the > corresponding authorization server and to use HTTPS server authentication > to verify the resource server's authenticity. This is impossible in the s= tandard > scenario. Clients must be able to discover the authorization server a > particular resource server relies on at runtime. The discovery mechanism > could be specified by the OAuth WG, but could also be part of an applicat= ion > protocols specification. But we MUST find another way to prevent token > phishing by counterfeit resource servers. >=20 > As one approach, the client could pass the (previously HTTPS > validated) resource server's URL with the authorization request. The > authorization server should then refuse such requests for any unknown > (counterfeit) resource servers. Such an additional parameter could also s= erve > as namespace for scope values and enable service providers to run multipl= e > instances of the same service within a single deployment. >=20 > If the additional data enlarges the request payload to much, we could > consider to adopt the "request by reference" proposal. >=20 > Let's now assume, OAuth is successful in the world of standard protocols = and > we will see plenty of deployments with a bunch of different OAuth > protected resource servers. Shall this servers all be accessible with a s= ingle > token? In my opinion, this would cause security, privacy and/or > scalability/performance problems. To give just the most obvious example, > the target audience of such a token cannot be restricted enough, which ma= y > allow a resource server (or an attacker in control of it) to abuse the to= ken on > other servers. But the current design of the code grant type forces > deployments to use the same token for all services. What is needed from m= y > point of view is a way to request and issue multiple server-specific acce= ss > tokens with a single authorization process. >=20 > I've been advocating this topic for a long time now and I'm still convinc= ed this > is required to really complete the core design. We at Deutsche Telekom > needed and implemented this function on top of the existing core. In my > opinion, a core enhancement would be easier to handle and more powerful. > If others support this topic, I would be willed to submit an I-D describi= ng a > possible solution. >=20 > If we take standards really seriously, then service providers should be g= iven > the opportunity to implement their service by utilizing standard server > implementations. This creates the challenge to find a standardized protoc= ol > between authorization server and resource server to exchange authorizatio= n > data. Depending on the token design (self-contained vs. handle) this coul= d > be solved by either standardizing a token format (JWT) or an authorizatio= n > API. >=20 > Based on the rationale given above, my list is as follows (topics w/o I-D= are > marked with *): >=20 > - Revocation (low hanging fruit since I-D is ready and implemented in som= e > places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) >=20 > regards, > Torsten. > Zitat von Hannes Tschofenig : >=20 > > Hi all, > > > > in preparation of the upcoming IETF meeting Barry and I would like to > > start a re-chartering discussion. We both are currently attending the > > Internet Identity Workshop and so we had the chance to solicit input > > from the participants. This should serve as a discussion starter. > > > > Potential future OAuth charter items (in random order): > > > > ---------------- > > > > 1) Dynamic Client Registration Protocol > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > > > 2) Token Revocation > > > > Available document: > > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > > > 3) UMA > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > > > 4) Client Instance Extension > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > > > 5) XML Encoding > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > > > 6) JSON Web Token > > > > Available document: > > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > > > 7) JSON Web Token (JWT) Bearer Profile > > > > Available document: > > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > > > 8) User Experience Extension > > > > Available document: > > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > > > 9) Request by Reference > > > > Available document: > > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > > > 10) Simple Web Discovery > > > > Available document: > > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > > > ---------------- > > > > We have the following questions: > > > > a) Are you interested in any of the above-listed items? (as a > > reviewer, co-author, implementer, or someone who would like to > > deploy). It is also useful to know if you think that we shouldn't work > > on a specific item. > > > > b) Are there other items you would like to see the group working on? > > > > Note: In case your document is expired please re-submit it. > > > > Ciao > > Hannes & Barry > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dan.taflin@gettyimages.com Wed Oct 26 09:33:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9297221F8B48 for ; Wed, 26 Oct 2011 09:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDcdQpft4UIv for ; Wed, 26 Oct 2011 09:33:56 -0700 (PDT) Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 92CA821F8593 for ; Wed, 26 Oct 2011 09:33:56 -0700 (PDT) X-Env-Sender: dan.taflin@gettyimages.com X-Msg-Ref: server-12.tower-144.messagelabs.com!1319646798!44354412!1 X-Originating-IP: [216.169.250.56] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20911 invoked from network); 26 Oct 2011 16:33:18 -0000 Received: from mail.gettyimages.com (HELO SEAPXCH10CAHT01.amer.gettywan.com) (216.169.250.56) by server-12.tower-144.messagelabs.com with AES128-SHA encrypted SMTP; 26 Oct 2011 16:33:18 -0000 Received: from SEAPXCH10MBX01.amer.gettywan.com ([fe80::f054:280d:92db:5fff]) by SEAPXCH10CAHT01.amer.gettywan.com ([::1]) with mapi id 14.01.0289.001; Wed, 26 Oct 2011 09:33:54 -0700 From: Dan Taflin To: Bob Van Zant , Dave Rochwerger Thread-Topic: Returning two tokens. Was: Re: [OAUTH-WG] Rechartering Thread-Index: AQHMk5EmX3qTviDSFUCxYOBEbJWXjJWOzYsQ Date: Wed, 26 Oct 2011 16:33:53 +0000 Message-ID: <429493818451304B84EC9A0797B5D85823CDA8@SEAPXCH10MBX01.amer.gettywan.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.102.80] Content-Type: multipart/alternative; boundary="_000_429493818451304B84EC9A0797B5D85823CDA8SEAPXCH10MBX01ame_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 16:33:59 -0000 --_000_429493818451304B84EC9A0797B5D85823CDA8SEAPXCH10MBX01ame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Bob, you're right and I withdraw my request to allow the return of = two tokens. However, I'm not sure OAuth supports our desired use case of passing "prote= cted" access tokens over plain http, based on my reading of section 10.3: "= Access token (as well as any access token type-specific attributes) MUST be= kept confidential in transit and storage..." seems to imply TLS. Dave, we may in fact end up going all SSL for our API, but that would mean = giving up on certain advantages plain http offers, not just performance but= also cacheability. Dan From: Bob Van Zant [mailto:bob@veznat.com] Sent: Tuesday, October 25, 2011 8:41 PM To: Dave Rochwerger Cc: Dan Taflin; OAuth WG Subject: Returning two tokens. Was: Re: [OAUTH-WG] Rechartering I'm going to reiterate what has already been said. OAuth already supports what you're trying to do. Just request a token twice= , the first time request it with a scope or scopes that allows these specia= l operations. The second time request it with a scope or scopes that do not= . In general I really like how simple OAuth 2 is. By working within the const= raints of this simplicity we can keep the protocol simple and easy to use. -Bob On Tuesday, October 25, 2011, Dave Rochwerger > wrote: > Hi Dan, > I think we are going down the wrong path here. > Basically, you've started with the premise of wanting plain HTTP scheme (= in some circumstances), which has caused you to suggest both of, firstly, r= elaxing the only method of encryption in oauth2 and secondly, to further co= mplicate the protocol by allowing multiple tokens to be returned. > OAuth2 (unlike version 1) has no signatures or other encryption - it reli= es solely on SSL. Therefore any relaxation of this requirement breaks secur= ity wide open (even in your specific short-term token case). > I think you're asking the wrong question. > We should not ask "to relax the SSL requirement", but rather - Why do you= not want to use SSL? > With today's computer speeds, there is no reason not to use SSL. The plai= n HTTP scheme does not really provide a noticeable enough performance boost= . On a side note, if the likes of Google's SPDY is anything to go by, the f= uture might always be SSL only anyway. > Cheers, > Dave > > On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin > wrote: > > You're right, if tracking was all we needed then a single token would suf= fice. The reason for two tokens has more to do with the fact that we'd like= to allow "protected" operations to be called over plain http. This opens u= p the possibility of an attacker intercepting the token for his own nefario= us use. If the only thing that token gave him access to was relatively beni= gn operations like image search, it would be an acceptable risk (especially= if we have a relatively short lifespan for the token). > > > > In contrast, "confidential" operations would only be callable over https.= By requiring a different token for them (and not allowing that token to be= used for unprotected operations) we prevent it from being intercepted. Thi= s design intentionally mimics the way secure and non-secure http cookies wo= rk. > > > > Oauth today basically requires https for all bearer token implementations= . I would like to see this relaxed somewhat. > > > > Dan > > > > From: Dave Rochwerger [mailto:daver@quizlet.com= ] > Sent: Tuesday, October 25, 2011 4:08 PM > To: Dan Taflin > > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering > > > > Is separating this out into 2 different tokens, really the best way to so= lve your use case? > > > > It sounds to me that you simply want to track/log the two types of access= es differently, which can be done entirely outside of the oauth2 process. > > Just bucket your operations into two piles internally and track appropria= tely (which you would have to do anyway with scopes). > > > > Scopes are the specific access that the end user grants to a 3rd party to= access their protected resources. > > > > When an application, to use your example, asks for the scope "protected c= onfidential", they are providing those two levels of access to the 3rd part= y application. If the user says "allow", then that application has all the = access that those two scopes provides. > > > > Rather than getting applications to then further choose between two token= s to simply delineate two sets of operations seems like the wrong place to = be doing this. > > i.e., why does the 3rd party application have to choose which token to us= e for each set of operations? - the user has already granted both. The reso= urce server can do whatever tracking/logging it wants based on the actual o= perations requested - using the single token in this case. > > > > Regards, > > Dave > > > > On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin > wrote: > > I would like to second Torsten's pitch for the ability to return multiple= access tokens with a single authorization process. The use case for my com= pany is to segment operatio --_000_429493818451304B84EC9A0797B5D85823CDA8SEAPXCH10MBX01ame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Bob, you’re right and I withdraw my request to= allow the return of two tokens.

 

However, I’m not sure OAuth supports our desired use c= ase of passing “protected” access tokens over plain http, based= on my reading of section 10.3: “Access token (as well as any access token type-specific attributes) MUST be kept = confidential in transit and storage...” seems to imply TLS.

 

Dave, we may in fact end up going all SSL for our API, but t= hat would mean giving up on certain advantages plain http offers, not just = performance but also cacheability.

 

Dan

 

From: Bob Van = Zant [mailto:bob@veznat.com]
Sent: Tuesday, October 25, 2011 8:41 PM
To: Dave Rochwerger
Cc: Dan Taflin; OAuth WG
Subject: Returning two tokens. Was: Re: [OAUTH-WG] Rechartering=

 

I'm going to reiterate what has already been said. <= br>
OAuth already supports what you're trying to do. Just request a token twice= , the first time request it with a scope or scopes that allows these specia= l operations. The second time request it with a scope or scopes that do not= .

In general I really like how simple OAuth 2 is. By working within the const= raints of this simplicity we can keep the protocol simple and easy to use.

-Bob

On Tuesday, October 25, 2011, Dave Rochwerger <daver@quizlet.com> wrote:
> Hi Dan,
> I think we are going down the wrong path here.
> Basically, you've started with the premise of wanting plain HTTP schem= e (in some circumstances), which has caused you to suggest both of, firstly= , relaxing the only method of encryption in oauth2 and secondly, to further= complicate the protocol by allowing multiple tokens to be returned.
> OAuth2 (unlike version 1) has no signatures or other encryption - it r= elies solely on SSL. Therefore any relaxation of this requirement breaks se= curity wide open (even in your specific short-term token case).
> I think you're asking the wrong question.
> We should not ask "to relax the SSL requirement", but rather= - Why do you not want to use SSL?
> With today's computer speeds, there is no reason not to use SSL. The p= lain HTTP scheme does not really provide a noticeable enough perf= ormance boost. On a side note, if the likes of Google's SPDY is anythi= ng to go by, the future might always be SSL only anyway.
> Cheers,
> Dave
>
> On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin <dan.taflin@gettyimages.com> wrote:
>
> You’re right, if tracking was all we needed then a single token = would suffice. The reason for two tokens has more to do with the fact that = we’d like to allow “protected” operations to be called ov= er plain http. This opens up the possibility of an attacker intercepting the token for his own nefarious use. If the only thing that t= oken gave him access to was relatively benign operations like image search,= it would be an acceptable risk (especially if we have a relatively short l= ifespan for the token).
>
>  
>
> In contrast, “confidential” operations would only be calla= ble over https. By requiring a different token for them (and not allowing t= hat token to be used for unprotected operations) we prevent it from being i= ntercepted. This design intentionally mimics the way secure and non-secure http cookies work.
>
>  
>
> Oauth today basically requires https for all bearer token implementati= ons. I would like to see this relaxed somewhat.
>
>  
>
> Dan
>
>  
>
> From: Dave Rochwerger [mailto:dav= er@quizlet.com]
> Sent: Tuesday, October 25, 2011 4:08 PM
> To: Dan Taflin
>
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
>
>  
>
> Is separating this out into 2 different tokens, really the best way to= solve your use case?
>
>  
>
> It sounds to me that you simply want to track/log the two types of acc= esses differently, which can be done entirely outside of the oauth2 process= .
>
> Just bucket your operations into two piles internally and track approp= riately (which you would have to do anyway with scopes).
>
>  
>
> Scopes are the specific access that the end user grants to a 3rd party= to access their protected resources.
>
>  
>
> When an application, to use your example, asks for the scope "pro= tected confidential", they are providing those two levels of access to= the 3rd party application. If the user says "allow", then that a= pplication has all the access that those two scopes provides.
>
>  
>
> Rather than getting applications to then further choose between two to= kens to simply delineate two sets of operations seems like the wrong p= lace to be doing this.
>
> i.e., why does the 3rd party application have to choose which token to= use for each set of operations? - the user has already granted both. The r= esource server can do whatever tracking/logging it wants based on the actua= l operations requested - using the single token in this case.
>
>  
>
> Regards,
>
> Dave
>
>  
>
> On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <dan.taflin@gettyimages.com> wrote:
>
> I would like to second Torsten's pitch for the ability to return multi= ple access tokens with a single authorization process. The use case for my = company is to segment operatio

--_000_429493818451304B84EC9A0797B5D85823CDA8SEAPXCH10MBX01ame_-- From torsten@lodderstedt.net Wed Oct 26 11:17:02 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BC921F84C3 for ; Wed, 26 Oct 2011 11:17:02 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOIXXI23slXj for ; Wed, 26 Oct 2011 11:17:00 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by ietfa.amsl.com (Postfix) with ESMTP id C776D21F84B9 for ; Wed, 26 Oct 2011 11:16:57 -0700 (PDT) Received: from [79.253.62.217] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RJ823-0000sH-AM; Wed, 26 Oct 2011 20:16:55 +0200 Message-ID: <4EA84E97.3020708@lodderstedt.net> Date: Wed, 26 Oct 2011 20:16:55 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nat Sakimura References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000503090201000501060900" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:17:02 -0000 This is a multi-part message in MIME format. --------------000503090201000501060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Nat, I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)). Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this. regards, Torsten. Am 22.10.2011 16:00, schrieb Nat Sakimura: > Hi. > > Just a clarification: > > Although my expired draft is 'request by reference', what was proposed > through it at the iiw really is a generalized JSON based claim request > capability. It could be passed by value as JSON or could be passed by > reference. The later is an optimization for bandwidth constrained > network as well as strengthening security in some ways. This > capability already exists in OpenID Connect but it is actually an > underpinning transport, so it probably should belong to OAuth instead. > This was the primary reason for the proposal. > > Nat > > On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt > > wrote: > > Hi all, > > my prioritization is driven by the goal to make OAuth the > authorization framework of choice for any internet standard > protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first > explain what is missing from my point of view and explain some > thoughts how to fill the gaps. > > A standard protocol is defined in terms of resource types and > messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented > in many places, and used by different but deployment-independent > clients. OAuth-based protocol specifications must also define > scope values (e.g. read, write, send) and their relation to the > resource types and messages. The different deployments expose the > standard protocol on different resource server endpoints. In my > opinion, it is fundamental to clearly distinguish scope values > (standardized, static) and resource server addresses (deployment > specific) and to manage their relationships. The current scope > definition is much to weak and insufficient. Probably, the UMA > concepts of hosts, resources sets, and corresponding scopes could > be adopted for that purpose. > > OAuth today requires clients to register with the service provider > before they are deployed. Would you really expect IMAP clients, > e.g. Thunderbird, to register with any a-Mail services upfront? So > clients should be given a way to register dynamically to the > authorization servers. This should also allow us to cover "client > instance" aspects. It is interesting to note, that such a > mechanism would allow us to get rid of secret-less clients and the > one-time usage requirement for authorization codes. > > We also assume the client to know the URLs of the resource server > and the corresponding authorization server and to use HTTPS server > authentication to verify the resource server's authenticity. This > is impossible in the standard scenario. Clients must be able to > discover the authorization server a particular resource server > relies on at runtime. The discovery mechanism could be specified > by the OAuth WG, but could also be part of an application > protocols specification. But we MUST find another way to prevent > token phishing by counterfeit resource servers. > > As one approach, the client could pass the (previously HTTPS > validated) resource server's URL with the authorization request. > The authorization server should then refuse such requests for any > unknown (counterfeit) resource servers. Such an additional > parameter could also serve as namespace for scope values and > enable service providers to run multiple instances of the same > service within a single deployment. > > If the additional data enlarges the request payload to much, we > could consider to adopt the "request by reference" proposal. > > Let's now assume, OAuth is successful in the world of standard > protocols and we will see plenty of deployments with a bunch of > different OAuth protected resource servers. Shall this servers all > be accessible with a single token? In my opinion, this would cause > security, privacy and/or scalability/performance problems. To give > just the most obvious example, the target audience of such a token > cannot be restricted enough, which may allow a resource server (or > an attacker in control of it) to abuse the token on other servers. > But the current design of the code grant type forces deployments > to use the same token for all services. What is needed from my > point of view is a way to request and issue multiple > server-specific access tokens with a single authorization process. > > I've been advocating this topic for a long time now and I'm still > convinced this is required to really complete the core design. We > at Deutsche Telekom needed and implemented this function on top of > the existing core. In my opinion, a core enhancement would be > easier to handle and more powerful. If others support this topic, > I would be willed to submit an I-D describing a possible solution. > > If we take standards really seriously, then service providers > should be given the opportunity to implement their service by > utilizing standard server implementations. This creates the > challenge to find a standardized protocol between authorization > server and resource server to exchange authorization data. > Depending on the token design (self-contained vs. handle) this > could be solved by either standardizing a token format (JWT) or an > authorization API. > > Based on the rationale given above, my list is as follows (topics > w/o I-D are marked with *): > > - Revocation (low hanging fruit since I-D is ready and implemented > in some places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration > > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) > > regards, > Torsten. > Zitat von Hannes Tschofenig >: > > > Hi all, > > in preparation of the upcoming IETF meeting Barry and I would > like to start a re-chartering discussion. We both are > currently attending the Internet Identity Workshop and so we > had the chance to solicit input from the participants. This > should serve as a discussion starter. > > Potential future OAuth charter items (in random order): > > ---------------- > > 1) Dynamic Client Registration Protocol > > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > 2) Token Revocation > > Available document: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > 3) UMA > > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > 4) Client Instance Extension > > Available document: > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > 5) XML Encoding > > Available document: > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > 6) JSON Web Token > > Available document: > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > 7) JSON Web Token (JWT) Bearer Profile > > Available document: > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > 8) User Experience Extension > > Available document: > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > 9) Request by Reference > > Available document: > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > 10) Simple Web Discovery > > Available document: > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > ---------------- > > We have the following questions: > > a) Are you interested in any of the above-listed items? (as a > reviewer, co-author, implementer, or someone who would like to > deploy). It is also useful to know if you think that we > shouldn't work on a specific item. > > b) Are there other items you would like to see the group > working on? > > Note: In case your document is expired please re-submit it. > > Ciao > Hannes & Barry > > _______________________________________________ > 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 > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --------------000503090201000501060900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 

Just a clarification: 

Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and  resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

 1) Dynamic Client Registration Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion.  We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--------------000503090201000501060900-- From torsten@lodderstedt.net Wed Oct 26 11:52:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4151921F8511 for ; Wed, 26 Oct 2011 11:52:21 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR0oZIzCLPuC for ; Wed, 26 Oct 2011 11:52:18 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by ietfa.amsl.com (Postfix) with ESMTP id E65C321F84B2 for ; Wed, 26 Oct 2011 11:52:17 -0700 (PDT) Received: from [79.253.62.217] (helo=[192.168.71.42]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RJ8aF-0007hX-Ch; Wed, 26 Oct 2011 20:52:15 +0200 Message-ID: <4EA856DC.9050303@lodderstedt.net> Date: Wed, 26 Oct 2011 20:52:12 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Bob Van Zant References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070801070508080000070108" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG , Dan Taflin Subject: Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:52:21 -0000 This is a multi-part message in MIME format. --------------070801070508080000070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Am 26.10.2011 05:41, schrieb Bob Van Zant: > I'm going to reiterate what has already been said. > > OAuth already supports what you're trying to do. Just request a token > twice, the first time request it with a scope or scopes that allows > these special operations. The second time request it with a scope or > scopes that do not. > > In general I really like how simple OAuth 2 is. By working within the > constraints of this simplicity we can keep the protocol simple and > easy to use. I also very much like the simplicity of the protocol but is this an end in itself? There are use cases not supported by the protocol at present. I intended to point this out and raise a discussion. We did not discuss a solution so far, so we also don't know the impact this may cause to the protocol. Justin made a proposal some month ago, which seems reasonable to me: http://www.ietf.org/mail-archive/web/oauth/current/msg06771.html I think the multiple tokens use case is relevant for every multi-service provider. If a client uses different services of such a provider (e.g. mail, web storage, telephony, and payment), there are good reasons to use different tokens for the respective resource servers, e.g. abuse prevention, service seggragation, privacy protection. This holds especially true if the services are operated by different business partners in an ASP model. The problem becomes even more obvious in cloud scenarios. With the current capabilities of the authorization code, such a client must send the user through the OAuth dance twice or more often. Alternatively, a single token is good to access all service. This means to trade user experience for security or vice versa. I don't like this. regards, Torsten. > > -Bob > > On Tuesday, October 25, 2011, Dave Rochwerger > wrote: > > Hi Dan, > > I think we are going down the wrong path here. > > Basically, you've started with the premise of wanting plain HTTP > scheme (in some circumstances), which has caused you to suggest both > of, firstly, relaxing the only method of encryption in oauth2 and > secondly, to further complicate the protocol by > allowing multiple tokens to be returned. > > OAuth2 (unlike version 1) has no signatures or other encryption - it > relies solely on SSL. Therefore any relaxation of this requirement > breaks security wide open (even in your specific short-term token case). > > I think you're asking the wrong question. > > We should not ask "to relax the SSL requirement", but rather - Why > do you not want to use SSL? > > With today's computer speeds, there is no reason not to use SSL. The > plain HTTP scheme does not really provide a noticeable enough > performance boost. On a side note, if the likes of Google's SPDY is > anything to go by, the future might always be SSL only anyway. > > Cheers, > > Dave > > > > On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin > > wrote: > > > > You're right, if tracking was all we needed then a single token > would suffice. The reason for two tokens has more to do with the fact > that we'd like to allow "protected" operations to be called over plain > http. This opens up the possibility of an attacker intercepting the > token for his own nefarious use. If the only thing that token gave him > access to was relatively benign operations like image search, it would > be an acceptable risk (especially if we have a relatively short > lifespan for the token). > > > > > > > > In contrast, "confidential" operations would only be callable over > https. By requiring a different token for them (and not allowing that > token to be used for unprotected operations) we prevent it from being > intercepted. This design intentionally mimics the way secure and > non-secure http cookies work. > > > > > > > > Oauth today basically requires https for all bearer token > implementations. I would like to see this relaxed somewhat. > > > > > > > > Dan > > > > > > > > From: Dave Rochwerger [mailto:daver@quizlet.com > ] > > Sent: Tuesday, October 25, 2011 4:08 PM > > To: Dan Taflin > > > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Rechartering > > > > > > > > Is separating this out into 2 different tokens, really the best way > to solve your use case? > > > > > > > > It sounds to me that you simply want to track/log the two types of > accesses differently, which can be done entirely outside of the oauth2 > process. > > > > Just bucket your operations into two piles internally and track > appropriately (which you would have to do anyway with scopes). > > > > > > > > Scopes are the specific access that the end user grants to a 3rd > party to access their protected resources. > > > > > > > > When an application, to use your example, asks for the scope > "protected confidential", they are providing those two levels of > access to the 3rd party application. If the user says "allow", then > that application has all the access that those two scopes provides. > > > > > > > > Rather than getting applications to then further choose between two > tokens to simply delineate two sets of operations seems like the wrong > place to be doing this. > > > > i.e., why does the 3rd party application have to choose which token > to use for each set of operations? - the user has already granted > both. The resource server can do whatever tracking/logging it wants > based on the actual operations requested - using the single token in > this case. > > > > > > > > Regards, > > > > Dave > > > > > > > > On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin > > wrote: > > > > I would like to second Torsten's pitch for the ability to return > multiple access tokens with a single authorization process. The use > case for my company is to segment operatio > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070801070508080000070108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Am 26.10.2011 05:41, schrieb Bob Van Zant:
I'm going to reiterate what has already been said.

OAuth already supports what you're trying to do. Just request a token twice, the first time request it with a scope or scopes that allows these special operations. The second time request it with a scope or scopes that do not.

In general I really like how simple OAuth 2 is. By working within the constraints of this simplicity we can keep the protocol simple and easy to use.

I also very much like the simplicity of the protocol but is this an end in itself? There are use cases not supported by the protocol at present. I intended to point this out and raise a discussion. We did not discuss a solution so far, so we also don't know the impact this may cause to the protocol.

Justin made a proposal some month ago, which seems reasonable to me: http://www.ietf.org/mail-archive/web/oauth/current/msg06771.html

I think the multiple tokens use case is relevant for every multi-service provider.

If a client uses different services of such a provider (e.g. mail, web storage, telephony, and payment), there are good reasons to use different tokens for the respective resource servers, e.g. abuse prevention, service seggragation, privacy protection. This holds especially true if the services are operated by different business partners in an ASP model. The problem becomes even more obvious in cloud scenarios.

With the current capabilities of the authorization code, such a client must send the user through the OAuth dance twice or more often. Alternatively, a single token is good to access all service. This means to trade user experience for security or vice versa. I don't like this.

regards,
Torsten.


-Bob

On Tuesday, October 25, 2011, Dave Rochwerger <daver@quizlet.com> wrote:
> Hi Dan,
> I think we are going down the wrong path here.
> Basically, you've started with the premise of wanting plain HTTP scheme (in some circumstances), which has caused you to suggest both of, firstly, relaxing the only method of encryption in oauth2 and secondly, to further complicate the protocol by allowing multiple tokens to be returned.
> OAuth2 (unlike version 1) has no signatures or other encryption - it relies solely on SSL. Therefore any relaxation of this requirement breaks security wide open (even in your specific short-term token case).
> I think you're asking the wrong question.
> We should not ask "to relax the SSL requirement", but rather - Why do you not want to use SSL?
> With today's computer speeds, there is no reason not to use SSL. The plain HTTP scheme does not really provide a noticeable enough performance boost. On a side note, if the likes of Google's SPDY is anything to go by, the future might always be SSL only anyway.
> Cheers,
> Dave
>
> On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin <dan.taflin@gettyimages.com> wrote:
>
> You’re right, if tracking was all we needed then a single token would suffice. The reason for two tokens has more to do with the fact that we’d like to allow “protected” operations to be called over plain http. This opens up the possibility of an attacker intercepting the token for his own nefarious use. If the only thing that token gave him access to was relatively benign operations like image search, it would be an acceptable risk (especially if we have a relatively short lifespan for the token).
>
>  
>
> In contrast, “confidential” operations would only be callable over https. By requiring a different token for them (and not allowing that token to be used for unprotected operations) we prevent it from being intercepted. This design intentionally mimics the way secure and non-secure http cookies work.
>
>  
>
> Oauth today basically requires https for all bearer token implementations. I would like to see this relaxed somewhat.
>
>  
>
> Dan
>
>  
>
> From: Dave Rochwerger [mailto:daver@quizlet.com]
> Sent: Tuesday, October 25, 2011 4:08 PM
> To: Dan Taflin
>
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
>
>  
>
> Is separating this out into 2 different tokens, really the best way to solve your use case?
>
>  
>
> It sounds to me that you simply want to track/log the two types of accesses differently, which can be done entirely outside of the oauth2 process.
>
> Just bucket your operations into two piles internally and track appropriately (which you would have to do anyway with scopes).
>
>  
>
> Scopes are the specific access that the end user grants to a 3rd party to access their protected resources.
>
>  
>
> When an application, to use your example, asks for the scope "protected confidential", they are providing those two levels of access to the 3rd party application. If the user says "allow", then that application has all the access that those two scopes provides.
>
>  
>
> Rather than getting applications to then further choose between two tokens to simply delineate two sets of operations seems like the wrong place to be doing this.
>
> i.e., why does the 3rd party application have to choose which token to use for each set of operations? - the user has already granted both. The resource server can do whatever tracking/logging it wants based on the actual operations requested - using the single token in this case.
>
>  
>
> Regards,
>
> Dave
>
>  
>
> On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <dan.taflin@gettyimages.com> wrote:
>
> I would like to second Torsten's pitch for the ability to return multiple access tokens with a single authorization process. The use case for my company is to segment operatio 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------070801070508080000070108-- From internet-drafts@ietf.org Wed Oct 26 12:11:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96C621F85DB; Wed, 26 Oct 2011 12:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjO72ptYz1la; Wed, 26 Oct 2011 12:11:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6A421F858C; Wed, 26 Oct 2011 12:11:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111026191133.30416.52941.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2011 12:11:33 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:11:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : OAuth 2.0 Threat Model and Security Considerations Author(s) : Torsten Lodderstedt Mark McGloin Phil Hunt Filename : draft-ietf-oauth-v2-threatmodel-01.txt Pages : 64 Date : 2011-10-26 This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt From torsten@lodderstedt.net Wed Oct 26 12:15:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F275C21F8B46 for ; Wed, 26 Oct 2011 12:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXWgWz1wLNum for ; Wed, 26 Oct 2011 12:15:29 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1886B21F8A7A for ; Wed, 26 Oct 2011 12:15:29 -0700 (PDT) Received: from [79.253.62.217] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RJ8wg-00077D-EN for oauth@ietf.org; Wed, 26 Oct 2011 21:15:26 +0200 Message-ID: <4EA85C4F.604@lodderstedt.net> Date: Wed, 26 Oct 2011 21:15:27 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 CC: oauth@ietf.org References: <20111026191133.30416.52941.idtracker@ietfa.amsl.com> In-Reply-To: <20111026191133.30416.52941.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000306050600060502040409" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:15:30 -0000 This is a multi-part message in MIME format. --------------000306050600060502040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, the new version of the security document is mostly dedicated to the alignment with the core draft -22. * Alignment of terminology with core draft 22 (private/public client, redirect URI validation policy, replaced definition of the client categories by reference to respective core section) * Synchronisation with the core's security consideration section (UPDATE 10.12 CSRF, NEW 10.14/15) * Added Resource Owner Impersonation * Improved section 5 * Renamed Refresh Token Replacement to Refresh Token Rotation Thanks to all people involved! regards, Torsten. Am 26.10.2011 21:11, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : OAuth 2.0 Threat Model and Security Considerations > Author(s) : Torsten Lodderstedt > Mark McGloin > Phil Hunt > Filename : draft-ietf-oauth-v2-threatmodel-01.txt > Pages : 64 > Date : 2011-10-26 > > This document gives security considerations based on a comprehensive > threat model for the OAuth 2.0 Protocol. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000306050600060502040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

the new version of the security document is mostly dedicated to the alignment with the core draft -22.
  • Alignment of terminology with core draft 22 (private/public client, redirect URI validation policy, replaced definition of the client categories by reference to respective core section)
  • Synchronisation with the core's security consideration section (UPDATE 10.12 CSRF, NEW 10.14/15)
  • Added Resource Owner Impersonation
  • Improved section 5
  • Renamed Refresh Token Replacement to Refresh Token Rotation
Thanks to all people involved!

regards,
Torsten.

Am 26.10.2011 21:11, schrieb internet-drafts@ietf.org: 
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : OAuth 2.0 Threat Model and Security Considerations
	Author(s)       : Torsten Lodderstedt
                          Mark McGloin
                          Phil Hunt
	Filename        : draft-ietf-oauth-v2-threatmodel-01.txt
	Pages           : 64
	Date            : 2011-10-26

   This document gives security considerations based on a comprehensive
   threat model for the OAuth 2.0 Protocol.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------000306050600060502040409-- From mike@mtcc.com Wed Oct 26 13:18:02 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B252521F85FF for ; Wed, 26 Oct 2011 13:18:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMwo0kVEzn3J for ; Wed, 26 Oct 2011 13:18:01 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id C928321F85F7 for ; Wed, 26 Oct 2011 13:18:01 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p9QKHwHb015008 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 13:17:59 -0700 Message-ID: <4EA86AF6.3030606@mtcc.com> Date: Wed, 26 Oct 2011 13:17:58 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20111026191133.30416.52941.idtracker@ietfa.amsl.com> <4EA85C4F.604@lodderstedt.net> In-Reply-To: <4EA85C4F.604@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3456; t=1319660281; x=1320524281; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20client=20embedded=20browsers=20(was=3A=20[OAUTH -WG]=20I-D=20Action=3A=20draft-ietf-oauth-v2-threatmodel-01. txt) |Sender:=20 |To:=20Torsten=20Lodderstedt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=BOKCzeXhxRVTNT0L2U61D6ReNpzHFvG4R255FJJ+mBc=; b=kXRJ9SgaDM5DeaLxZ9sNujtTwJVKGdDhPB4ys7QUsEFM+MNri/cVgzaXk8 cEIkgiBJutXPP8sxA5oNdPtfaWhVWqe4hGTeCqkmzuxyi37fFRF6PO8PlJ2u 8gQTZtq58NpVv9esCw65Gqqy6qMzRRE/SMLyFIuMaLcBG8CVVP0dA=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: oauth@ietf.org Subject: [OAUTH-WG] client embedded browsers (was: I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:18:02 -0000 First, I think that this threat should be elevated to something more than a threat because it is a fundamental assumption of the protocol that the browser is trustworthy. I have heard far too many people on this list say that that's silly because it is "obvious" but it is not obvious to the uninitiated, who are the remaining 7*10^9-100 people in this world. Second, I think it's worth explicitly pointing out that this PERTAINS TO APPS too. The world has changed significantly since OAUTH was conceived, and native phone, etc apps continue to grow explosively after a long, long decline leading up to OAUTH's birth. I would venture to say that a sizable if not majority of uses of OAUTH will be in app settings. A few inline comments: 4.1.4. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/ password). [mat] I think it's also worth mentioning either here, or in another threat that there is a further social engineering misuse/attack where an app offers/demands to keep your credentials so that you don't have to go through the authorization rigmarole. Users are already conditioned to give their credentials up to do things -- just this morning I noticed facebook asking for my email password which they promise with sugar on top to not store. It might be worth mentioning that things like CAPTCHA could be deployed to defend against that sort of attack/misuse. Impact: If the client application or the communication is compromised, the user would not be aware and all information in the authorization exchange could be captured such as username and password. Countermeasures: o Client developers and end-user can be educated to trust an external System-Browser only. [mat] I assume that this is in here just for the amusement factor because it is not a credible countermeasure. o Client applications could be validated prior publication in a application market. [mat] How would this be done in practice? o Client developers should not collect authentication information directly from users and should instead use redirects to and back from a trusted external system-browser. [mat] How would the resource/authentication server enforce such a thing? The main problem here is that the countermeasures -- if they are practical at all -- are deep and complex problems unto themselves. To just handwave them away does no justice to the seriousness of the threat. I realize that this strays more into BCP land but there isn't any B-C-P, and I'm not terribly convinced there ever will be. In that respect, I think this threat and its potential countermeasures need to be discussed in much more detail. If there is anything about OAUTH that will cause it to be junked, it's this threat. Mike From andredemarre@gmail.com Wed Oct 26 13:44:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45FC21F8B82 for ; Wed, 26 Oct 2011 13:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN+0Pl4VAMG9 for ; Wed, 26 Oct 2011 13:44:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7A1121F8B80 for ; Wed, 26 Oct 2011 13:44:55 -0700 (PDT) Received: by iabn5 with SMTP id n5so2721684iab.31 for ; Wed, 26 Oct 2011 13:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4zezIFM3Ujek1T/vMNDL1gnShuW1F65V9abtpZQhaIk=; b=DMVfcDNYhMBAuWcK2qUiUrcnY+yZx6za0EUCa4Kya/h9lG8T37B5JWHvaK6N1c5NYl jh6yrUpmnJyJ2aq5PxC2dGnaUxWXmmbsAZmMJRgYxIRZqudIV+HIxR9emIE3OjWU/uv9 7IRVssMP+TDxPDncZeHbtyVHk74ElzNo0tef4= MIME-Version: 1.0 Received: by 10.42.172.194 with SMTP id o2mr53244669icz.15.1319661895430; Wed, 26 Oct 2011 13:44:55 -0700 (PDT) Received: by 10.42.151.131 with HTTP; Wed, 26 Oct 2011 13:44:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 13:44:55 -0700 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Phishing with Client Application Name Spoofing X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:44:56 -0000 Should a brief explanation of this be added to the Threat Model and Security Considerations document? Or does anyone even agree that this can be a problem? Regards, Andre DeMarre On Tue, Oct 4, 2011 at 11:32 AM, Andr=E9 DeMarre w= rote: > I've not seen this particular variant of phishing and client > impersonation discussed. A cursory search revealed that most of the > related discussion centers around either (a) client impersonation with > stolen client credentials or (b) phishing by malicious clients > directing resource owners to spoofed authorization servers. This is > different. > > This attack exploits the trust a resource owner has for an OAuth > authorization server so as to lend repute to a malicious client > pretending to be from a trustworthy source. This is not necessarily a > direct vulnerability of OAuth; rather, it shows that authorization > servers have a responsibility regarding client application names and > how they present resource owners with the option to allow or deny > authorization. > > A key to this exploit is the process of client registration with the > authorization server. A malicious client developer registers his > client application with a name that appears to represent a legitimate > organization which resource owners are likely to trust. Resource > owners at the authorization endpoint may be misled into granting > authorization when they see the authorization server asserting " trustworthy name> is requesting permission to..." > > Imagine someone registers a client application with an OAuth service, > let's call it Foobar, and he names his client app "Google, Inc.". The > Foobar authorization server will engage the user with "Google, Inc. is > requesting permission to do the following." The resource owner might > reason, "I see that I'm legitimately on the https://www.foobar.com > site, and Foobar is telling me that Google wants permission. I trust > Foobar and Google, so I'll click Allow." > > To make the masquerade act even more convincing, many of the most > popular OAuth services allow app developers to upload images which > could be official logos of the organizations they are posing as. Often > app developers can supply arbitrary, unconfirmed URIs which are shown > to the resource owner as the app's website, even if the domain does > not match the redirect URI. Some OAuth services blindly entrust client > apps to customize the authorization page in other ways. > > This is hard to defend against. Authorization server administrators > could police client names, but that approach gives them a burden > similar to certificate authorities to verify organizations before > issuing certificates. Very expensive. > > A much simpler solution is for authorization servers to be careful > with their wording and educate resource owners about the need for > discretion when granting authority. Foobar's message above could be > changed: "An application calling itself Google, Inc. is requesting > permission to do the following" later adding, "Only allow this request > if you are sure of the application's source." Such wording is less > likely to give the impression that the resource server is vouching for > the application's identity. > > Authorization servers would also do well to show the resource owner > additional information about the client application to help them make > informed decisions. For example, it could display all or part of the > app's redirect URI, saying, "The application is operating on > example.com" or "If you decide to allow this application, your browser > will be directed to http://www.example.com/." Further, if the client > app's redirect URI uses TLS (something authorization servers might > choose to mandate), then auth servers can verify the certificate and > show the certified organization name to resource owners. > > This attack is possible with OAuth 1, but OAuth 2 makes successful > exploitation easier. OAuth 1 required the client to obtain temporary > credentials (aka access tokens) before sending resource owners to the > authorization endpoint. Now with OAuth 2, this attack does not require > resource owners to interact with the client application before > visiting the authorization server. The malicious client developer only > needs to distribute links around the web to the authorization server's > authorization endpoint. If the HTTP service is a social platform, the > client app might distribute links using resource owners' accounts with > the access tokens it has acquired, becoming a sort of worm. Continuing > the Google/Foobar example above, it might use anchor text such as "I > used Google Plus to synchronize with my Foobar account." Moreover, if > the app's redirect URI bounces the resource owner back to the HTTP > service after acquiring an authorization code, the victim will never > see a page rendered at the insidious app's domain. > > This is especially dangerous because the public is not trained to > defend against it. Savvy users are (arguably) getting better at > protecting themselves from traditional phishing by verifying the > domain in the address bar, and perhaps checking TLS certificates, but > such defenses are irrelevent here. Resource owners now need to verify > not only that they are on the legitimate authorization server, but to > consider the trustworthyness of the link that referred them there. > > I'm not sure what can or should be done, but I think it's important > for authorization server implementers to be aware of this attack. If > administrators are not able to authenticate client organizations, then > they are shifting this burden to resource owners. They should do all > they can to educate resource owners and help them make informed > decisions before granting authorization. > > Regards, > Andre DeMarre > From igor.faynberg@alcatel-lucent.com Wed Oct 26 14:34:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A2421F8B34 for ; Wed, 26 Oct 2011 14:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa66yzWJxsOO for ; Wed, 26 Oct 2011 14:34:06 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2921F8AB0 for ; Wed, 26 Oct 2011 14:34:06 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9QLY4oO006637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Oct 2011 16:34:05 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9QLY4MA001283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Oct 2011 16:34:04 -0500 Received: from [135.222.134.155] (USMUYN0L055118.mh.lucent.com [135.222.134.155]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9QLY3sf005533; Wed, 26 Oct 2011 16:34:04 -0500 (CDT) Message-ID: <4EA87CCB.40000@alcatel-lucent.com> Date: Wed, 26 Oct 2011 17:34:03 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050502050009000106070209" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 21:34:08 -0000 This is a multi-part message in MIME format. --------------050502050009000106070209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Actually, I think we need to document the use case. Igor On 10/25/2011 7:08 PM, Dave Rochwerger wrote: > Is separating this out into 2 different tokens, really the best way to > solve your use case? > > It sounds to me that you simply want to track/log the two types of > accesses differently, which can be done entirely outside of the oauth2 > process. > Just bucket your operations into two piles internally and track > appropriately (which you would have to do anyway with scopes). > > Scopes are the specific access that the end user grants to a 3rd party > to access their protected resources. > > When an application, to use your example, asks for the scope > "protected confidential", they are providing those two levels of > access to the 3rd party application. If the user says "allow", then > that application has all the access that those two scopes provides. > > Rather than getting applications to then further choose between two > tokens to simply delineate two sets of operations seems like the wrong > place to be doing this. > i.e., why does the 3rd party application have to choose which token to > use for each set of operations? - the user has already granted both. > The resource server can do whatever tracking/logging it wants based on > the actual operations requested - using the single token in this case. > > Regards, > Dave > > On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin > > wrote: > > I would like to second Torsten's pitch for the ability to return > multiple access tokens with a single authorization process. The > use case for my company is to segment operations into two main > categories: protected and confidential. (A possible third > category, public, would not require any authorization at all). > Protected operations would be user-specific operations that don't > involve the passing of any sensitive information, such as image > search results tagged with information about whether each image is > available for download by that user. Confidential operations would > involve passing user data, like user registration or e-commerce. > We would like to protect each category of operations with distinct > tokens: a general-use token for protected operations, and a secure > token for confidential operations. > > We could use the scope parameter to specify either "protected" or > "confidential". Currently the oauth spec allows a Refresh token to > request a new token with reduced scope from the one originally > issued, but there is no way to obtain a new token with a > completely different scope without doing the full oauth dance a > second time. > > Dan > > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net > ] > Sent: Thursday, October 20, 2011 3:57 PM > To: Hannes Tschofenig > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering > > Hi all, > > my prioritization is driven by the goal to make OAuth the > authorization framework of choice for any internet standard protocol, > such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is > missing from my point of view and explain some thoughts how to fill > the gaps. > > A standard protocol is defined in terms of resource types and messages > by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many > places, and used by different but deployment-independent clients. > OAuth-based protocol specifications must also define scope values > (e.g. read, write, send) and their relation to the resource types and > messages. The different deployments expose the standard protocol on > different resource server endpoints. In my opinion, it is fundamental > to clearly distinguish scope values (standardized, static) and > resource server addresses (deployment specific) and to manage their > relationships. The current scope definition is much to weak and > insufficient. Probably, the UMA concepts of hosts, resources sets, and > corresponding scopes could be adopted for that purpose. > > OAuth today requires clients to register with the service provider > before they are deployed. Would you really expect IMAP clients, e.g. > Thunderbird, to register with any a-Mail services upfront? So clients > should be given a way to register dynamically to the authorization > servers. This should also allow us to cover "client instance" aspects. > It is interesting to note, that such a mechanism would allow us to get > rid of secret-less clients and the one-time usage requirement for > authorization codes. > > We also assume the client to know the URLs of the resource server and > the corresponding authorization server and to use HTTPS server > authentication to verify the resource server's authenticity. This is > impossible in the standard scenario. Clients must be able to discover > the authorization server a particular resource server relies on at > runtime. The discovery mechanism could be specified by the OAuth WG, > but could also be part of an application protocols specification. But > we MUST find another way to prevent token phishing by counterfeit > resource servers. > > As one approach, the client could pass the (previously HTTPS > validated) resource server's URL with the authorization request. The > authorization server should then refuse such requests for any unknown > (counterfeit) resource servers. Such an additional parameter could > also serve as namespace for scope values and enable service providers > to run multiple instances of the same service within a single > deployment. > > If the additional data enlarges the request payload to much, we could > consider to adopt the "request by reference" proposal. > > Let's now assume, OAuth is successful in the world of standard > protocols and we will see plenty of deployments with a bunch of > different OAuth protected resource servers. Shall this servers all be > accessible with a single token? In my opinion, this would cause > security, privacy and/or scalability/performance problems. To give > just the most obvious example, the target audience of such a token > cannot be restricted enough, which may allow a resource server (or an > attacker in control of it) to abuse the token on other servers. But > the current design of the code grant type forces deployments to use > the same token for all services. What is needed from my point of view > is a way to request and issue multiple server-specific access tokens > with a single authorization process. > > I've been advocating this topic for a long time now and I'm still > convinced this is required to really complete the core design. We at > Deutsche Telekom needed and implemented this function on top of the > existing core. In my opinion, a core enhancement would be easier to > handle and more powerful. If others support this topic, I would be > willed to submit an I-D describing a possible solution. > > If we take standards really seriously, then service providers should > be given the opportunity to implement their service by utilizing > standard server implementations. This creates the challenge to find a > standardized protocol between authorization server and resource server > to exchange authorization data. Depending on the token design > (self-contained vs. handle) this could be solved by either > standardizing a token format (JWT) or an authorization API. > > Based on the rationale given above, my list is as follows (topics w/o > I-D are marked with *): > > - Revocation (low hanging fruit since I-D is ready and implemented in > some places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) > > regards, > Torsten. > Zitat von Hannes Tschofenig >: > > > Hi all, > > > > in preparation of the upcoming IETF meeting Barry and I would like > > to start a re-chartering discussion. We both are currently > > attending the Internet Identity Workshop and so we had the chance to > > solicit input from the participants. This should serve as a > > discussion starter. > > > > Potential future OAuth charter items (in random order): > > > > ---------------- > > > > 1) Dynamic Client Registration Protocol > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > > > > 2) Token Revocation > > > > Available document: > > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > > > 3) UMA > > > > Available document: > > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > > > > 4) Client Instance Extension > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > > > > 5) XML Encoding > > > > Available document: > > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > > > > 6) JSON Web Token > > > > Available document: > > http://tools.ietf.org/html/draft-jones-json-web-token-05 > > > > 7) JSON Web Token (JWT) Bearer Profile > > > > Available document: > > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > > > > 8) User Experience Extension > > > > Available document: > > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > > > > 9) Request by Reference > > > > Available document: > > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > > > > 10) Simple Web Discovery > > > > Available document: > > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > > > > ---------------- > > > > We have the following questions: > > > > a) Are you interested in any of the above-listed items? (as a > > reviewer, co-author, implementer, or someone who would like to > > deploy). It is also useful to know if you think that we shouldn't > > work on a specific item. > > > > b) Are there other items you would like to see the group working on? > > > > Note: In case your document is expired please re-submit it. > > > > Ciao > > Hannes & Barry > > > > _______________________________________________ > > 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 --------------050502050009000106070209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Actually, I think we need to document the use case.

Igor

On 10/25/2011 7:08 PM, Dave Rochwerger wrote:
Is separating this out into 2 different tokens, really the best way to solve your use case?

It sounds to me that you simply want to track/log the two types of accesses differently, which can be done entirely outside of the oauth2 process.
Just bucket your operations into two piles internally and track appropriately (which you would have to do anyway with scopes).

Scopes are the specific access that the end user grants to a 3rd party to access their protected resources.

When an application, to use your example, asks for the scope "protected confidential", they are providing those two levels of access to the 3rd party application. If the user says "allow", then that application has all the access that those two scopes provides.

Rather than getting applications to then further choose between two tokens to simply delineate two sets of operations seems like the wrong place to be doing this.
i.e., why does the 3rd party application have to choose which token to use for each set of operations? - the user has already granted both. The resource server can do whatever tracking/logging it wants based on the actual operations requested - using the single token in this case.

Regards,
Dave

On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <dan.taflin@gettyimages.com> wrote:
I would like to second Torsten's pitch for the ability to return multiple access tokens with a single authorization process. The use case for my company is to segment operations into two main categories: protected and confidential. (A possible third category, public, would not require any authorization at all). Protected operations would be user-specific operations that don't involve the passing of any sensitive information, such as image search results tagged with information about whether each image is available for download by that user. Confidential operations would involve passing user data, like user registration or e-commerce. We would like to protect each category of operations with distinct tokens: a general-use token for protected operations, and a secure token for confidential operations.

We could use the scope parameter to specify either "protected" or "confidential". Currently the oauth spec allows a Refresh token to request a new token with reduced scope from the one originally issued, but there is no way to obtain a new token with a completely different scope without doing the full oauth dance a second time.

Dan

-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Thursday, October 20, 2011 3:57 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

Hi all,

my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard protocol,
such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is
missing from my point of view and explain some thoughts how to fill
the gaps.

A standard protocol is defined in terms of resource types and messages
by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many
places, and used by different but deployment-independent clients.
OAuth-based protocol specifications must also define scope values
(e.g. read, write, send) and their relation to the resource types and
messages. The different deployments expose the standard protocol on
different resource server endpoints. In my opinion, it is fundamental
to clearly distinguish scope values (standardized, static) and
resource server addresses (deployment specific) and to manage their
relationships. The current scope definition is much to weak and
insufficient. Probably, the UMA concepts of hosts, resources sets, and
corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider
before they are deployed. Would you really expect IMAP clients, e.g.
Thunderbird, to register with any a-Mail services upfront? So clients
should be given a way to register dynamically to the authorization
servers. This should also allow us to cover "client instance" aspects.
It is interesting to note, that such a mechanism would allow us to get
rid of secret-less clients and the one-time usage requirement for
authorization codes.

We also assume the client to know the URLs of the resource server and
the corresponding authorization server and to use HTTPS server
authentication to verify the resource server's authenticity. This is
impossible in the standard scenario. Clients must be able to discover
the authorization server a particular resource server relies on at
runtime. The discovery mechanism could be specified by the OAuth WG,
but could also be part of an application protocols specification. But
we MUST find another way to prevent token phishing by counterfeit
resource servers.

As one approach, the client could pass the (previously HTTPS
validated) resource server's URL with the authorization request. The
authorization server should then refuse such requests for any unknown
(counterfeit) resource servers. Such an additional parameter could
also serve as namespace for scope values and enable service providers
to run multiple instances of the same service within a single
deployment.

If the additional data enlarges the request payload to much, we could
consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard
protocols and we will see plenty of deployments with a bunch of
different OAuth protected resource servers. Shall this servers all be
accessible with a single token? In my opinion, this would cause
security, privacy and/or scalability/performance problems. To give
just the most obvious example, the target audience of such a token
cannot be restricted enough, which may allow a resource server (or an
attacker in control of it) to abuse the token on other servers. But
the current design of the code grant type forces deployments to use
the same token for all services. What is needed from my point of view
is a way to request and issue multiple server-specific access tokens
with a single authorization process.

I've been advocating this topic for a long time now and I'm still
convinced this is required to really complete the core design. We at
Deutsche Telekom needed and implemented this function on top of the
existing core. In my opinion, a core enhancement would be easier to
handle and more powerful. If others support this topic, I would be
willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should
be given the opportunity to implement their service by utilizing
standard server implementations. This creates the challenge to find a
standardized protocol between authorization server and resource server
to exchange authorization data. Depending on the token design
(self-contained vs. handle) this could be solved by either
standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o
I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in
some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration
 1) Dynamic Client Registration Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:

> Hi all,
>
> in preparation of the upcoming IETF meeting Barry and I would like
> to start a re-chartering discussion.  We both are currently
> attending the Internet Identity Workshop and so we had the chance to
> solicit input from the participants. This should serve as a
> discussion starter.
>
> Potential future OAuth charter items (in random order):
>
> ----------------
>
> 1) Dynamic Client Registration Protocol
>
> Available document:
> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/
>
> 2) Token Revocation
>
> Available document:
> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
>
> 3) UMA
>
> Available document:
> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
>
> 4) Client Instance Extension
>
> Available document:
> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt
>
> 5) XML Encoding
>
> Available document:
> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt
>
> 6) JSON Web Token
>
> Available document:
> http://tools.ietf.org/html/draft-jones-json-web-token-05
>
> 7) JSON Web Token (JWT) Bearer Profile
>
> Available document:
> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00
>
> 8) User Experience Extension
>
> Available document:
> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
>
> 9) Request by Reference
>
> Available document:
> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00
>
> 10) Simple Web Discovery
>
> Available document:
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00
>
> ----------------
>
> We have the following questions:
>
> a) Are you interested in any of the above-listed items? (as a
> reviewer, co-author, implementer, or someone who would like to
> deploy). It is also useful to know if you think that we shouldn't
> work on a specific item.
>
> b) Are there other items you would like to see the group working on?
>
> Note: In case your document is expired please re-submit it.
>
> Ciao
> Hannes & Barry
>
> _______________________________________________
> 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
--------------050502050009000106070209-- From sakimura@gmail.com Wed Oct 26 15:30:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C60F21F8B7C for ; Wed, 26 Oct 2011 15:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4H7DGPQrtmW for ; Wed, 26 Oct 2011 15:30:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF30021F8B75 for ; Wed, 26 Oct 2011 15:30:09 -0700 (PDT) Received: by faas12 with SMTP id s12so2332152faa.31 for ; Wed, 26 Oct 2011 15:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MzhKAfelrewuk0GQwccwj8tTSkW9yHgK9T6CdFsdDFk=; b=uQm0EKZV8+xLNutXNoy4kdu65A2+PuspSOnvPNktwxwEBUJVdkp0WeKxAzacofnFdc hdkB5aL+B9YEyx3cVAw4dj52Gm+TNk3SwgeY83OPzDdJ+LnCTDEDkOGW1vO126YF8Vvn 2hOxQHntUwU+m51ERWo27gcZYIN8srQRusM+0= MIME-Version: 1.0 Received: by 10.223.62.15 with SMTP id v15mr62113224fah.22.1319668208719; Wed, 26 Oct 2011 15:30:08 -0700 (PDT) Received: by 10.152.37.201 with HTTP; Wed, 26 Oct 2011 15:30:08 -0700 (PDT) In-Reply-To: <4EA84E97.3020708@lodderstedt.net> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> Date: Thu, 27 Oct 2011 07:30:08 +0900 Message-ID: From: Nat Sakimura To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001517402a2acd59fe04b03b323d Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 22:30:12 -0000 --001517402a2acd59fe04b03b323d Content-Type: text/plain; charset=ISO-8859-1 HI Torsten, I and John just refreshed the I-D to be more in-line with what we do with OpenID Connect. http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01 As you point out, this would solve the duplication / non-standard behavior that OpenID Connect requires. Cheers, Nat On Thu, Oct 27, 2011 at 3:16 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Nat, > > I think your proposal would be a useful OAuth enhancement. A JSON-based > request format would allow for more complex requests (e.g. carrying resource > server URLs and corresponding scope values ;-)). > > Please note: I also think the way this mechanism is introduced and used in > the current OpenID connect spec requires OpenID connect clients and servers > to handle OAuth request parameters differently than for standard OAuth > requests. Introducing the JSON based claim request capability to OAuth would > be a way to cope with this. > > regards, > Torsten. > > Am 22.10.2011 16:00, schrieb Nat Sakimura: > > Hi. > > Just a clarification: > > Although my expired draft is 'request by reference', what was proposed > through it at the iiw really is a generalized JSON based claim request > capability. It could be passed by value as JSON or could be passed by > reference. The later is an optimization for bandwidth constrained network as > well as strengthening security in some ways. This capability already exists > in OpenID Connect but it is actually an underpinning transport, so it > probably should belong to OAuth instead. This was the primary reason for the > proposal. > > Nat > > On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi all, >> >> my prioritization is driven by the goal to make OAuth the authorization >> framework of choice for any internet standard protocol, such as WebDAV, >> IMAP, SMTP or SIP. So let me first explain what is missing from my point of >> view and explain some thoughts how to fill the gaps. >> >> A standard protocol is defined in terms of resource types and messages by >> a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and >> used by different but deployment-independent clients. OAuth-based protocol >> specifications must also define scope values (e.g. read, write, send) and >> their relation to the resource types and messages. The different deployments >> expose the standard protocol on different resource server endpoints. In my >> opinion, it is fundamental to clearly distinguish scope values >> (standardized, static) and resource server addresses (deployment specific) >> and to manage their relationships. The current scope definition is much to >> weak and insufficient. Probably, the UMA concepts of hosts, resources sets, >> and corresponding scopes could be adopted for that purpose. >> >> OAuth today requires clients to register with the service provider before >> they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, >> to register with any a-Mail services upfront? So clients should be given a >> way to register dynamically to the authorization servers. This should also >> allow us to cover "client instance" aspects. It is interesting to note, that >> such a mechanism would allow us to get rid of secret-less clients and the >> one-time usage requirement for authorization codes. >> >> We also assume the client to know the URLs of the resource server and the >> corresponding authorization server and to use HTTPS server authentication to >> verify the resource server's authenticity. This is impossible in the >> standard scenario. Clients must be able to discover the authorization server >> a particular resource server relies on at runtime. The discovery mechanism >> could be specified by the OAuth WG, but could also be part of an application >> protocols specification. But we MUST find another way to prevent token >> phishing by counterfeit resource servers. >> >> As one approach, the client could pass the (previously HTTPS validated) >> resource server's URL with the authorization request. The authorization >> server should then refuse such requests for any unknown (counterfeit) >> resource servers. Such an additional parameter could also serve as namespace >> for scope values and enable service providers to run multiple instances of >> the same service within a single deployment. >> >> If the additional data enlarges the request payload to much, we could >> consider to adopt the "request by reference" proposal. >> >> Let's now assume, OAuth is successful in the world of standard protocols >> and we will see plenty of deployments with a bunch of different OAuth >> protected resource servers. Shall this servers all be accessible with a >> single token? In my opinion, this would cause security, privacy and/or >> scalability/performance problems. To give just the most obvious example, the >> target audience of such a token cannot be restricted enough, which may allow >> a resource server (or an attacker in control of it) to abuse the token on >> other servers. But the current design of the code grant type forces >> deployments to use the same token for all services. What is needed from my >> point of view is a way to request and issue multiple server-specific access >> tokens with a single authorization process. >> >> I've been advocating this topic for a long time now and I'm still >> convinced this is required to really complete the core design. We at >> Deutsche Telekom needed and implemented this function on top of the existing >> core. In my opinion, a core enhancement would be easier to handle and more >> powerful. If others support this topic, I would be willed to submit an I-D >> describing a possible solution. >> >> If we take standards really seriously, then service providers should be >> given the opportunity to implement their service by utilizing standard >> server implementations. This creates the challenge to find a standardized >> protocol between authorization server and resource server to exchange >> authorization data. Depending on the token design (self-contained vs. >> handle) this could be solved by either standardizing a token format (JWT) or >> an authorization API. >> >> Based on the rationale given above, my list is as follows (topics w/o I-D >> are marked with *): >> >> - Revocation (low hanging fruit since I-D is ready and implemented in some >> places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >> >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >> >> regards, >> Torsten. >> Zitat von Hannes Tschofenig : >> >> >> Hi all, >>> >>> in preparation of the upcoming IETF meeting Barry and I would like to >>> start a re-chartering discussion. We both are currently attending the >>> Internet Identity Workshop and so we had the chance to solicit input from >>> the participants. This should serve as a discussion starter. >>> >>> Potential future OAuth charter items (in random order): >>> >>> ---------------- >>> >>> 1) Dynamic Client Registration Protocol >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>> >>> 2) Token Revocation >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>> >>> 3) UMA >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>> >>> 4) Client Instance Extension >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>> >>> 5) XML Encoding >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>> >>> 6) JSON Web Token >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>> >>> 7) JSON Web Token (JWT) Bearer Profile >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>> >>> 8) User Experience Extension >>> >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>> >>> 9) Request by Reference >>> >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>> >>> 10) Simple Web Discovery >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>> >>> ---------------- >>> >>> We have the following questions: >>> >>> a) Are you interested in any of the above-listed items? (as a reviewer, >>> co-author, implementer, or someone who would like to deploy). It is also >>> useful to know if you think that we shouldn't work on a specific item. >>> >>> b) Are there other items you would like to see the group working on? >>> >>> Note: In case your document is expired please re-submit it. >>> >>> Ciao >>> Hannes & Barry >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001517402a2acd59fe04b03b323d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI Torsten,=A0

I and John just refreshed the I-D to be m= ore in-line with what we do with OpenID Connect.=A0

htt= p://tools.ietf.org/html/draft-sakimura-oauth-requrl-01

As you point out, this would solve the duplication / no= n-standard behavior that OpenID Connect requires.=A0

Cheers,=A0

Nat

On Thu, Oct 27, 2011 at 3:16 AM, Torsten Lodderstedt <= torsten@lodderstedt.net><= /span> wrote:
=20 =20 =20
Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi.=A0

Just a clarification:=A0

Although my expired draft is 'request by reference', wha= t was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal.=A0

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and =A0resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspec= ts. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I&#= 39;m still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

=A01) Dynamic Client Registration Protocol
=A04) Client Instance Extension
- Discovery
=A0(10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
=A0(depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion. =A0We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-har= djono-oauth-dynreg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/dr= aft-lodderstedt-oauth-revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-ha= rdjono-oauth-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oaut= h-instance-00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml= -00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-w= eb-token-05

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oaut= h-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oau= th-v2-ux-00

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oa= uth-requrl-00

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-= simple-web-discovery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

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



_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat= .sakimura.org/
@_nat_en




--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--001517402a2acd59fe04b03b323d-- From ve7jtb@ve7jtb.com Wed Oct 26 15:33:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC7811E8080 for ; Wed, 26 Oct 2011 15:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNVOd9lAUc2d for ; Wed, 26 Oct 2011 15:33:55 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F45311E808A for ; Wed, 26 Oct 2011 15:33:55 -0700 (PDT) Received: by ggnv1 with SMTP id v1so2372669ggn.31 for ; Wed, 26 Oct 2011 15:33:55 -0700 (PDT) Received: by 10.150.205.19 with SMTP id c19mr30074825ybg.58.1319668434831; Wed, 26 Oct 2011 15:33:54 -0700 (PDT) Received: from [192.168.1.213] ([190.22.12.103]) by mx.google.com with ESMTPS id z6sm8897185anf.22.2011.10.26.15.33.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Oct 2011 15:33:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_3C781098-1FD0-44AA-A95F-50AE869FBBEB"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4EA84E97.3020708@lodderstedt.net> Date: Wed, 26 Oct 2011 19:31:43 -0300 Message-Id: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 22:33:57 -0000 --Apple-Mail=_3C781098-1FD0-44AA-A95F-50AE869FBBEB Content-Type: multipart/alternative; boundary="Apple-Mail=_F02E2C6E-39A0-4FC9-83A1-4C9F6B339EE9" --Apple-Mail=_F02E2C6E-39A0-4FC9-83A1-4C9F6B339EE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. It is essentially a standardization of the method we are using in = openID Connect to make signed requests to the Authorization server. We do have the issue that parameters in the signed/encrypted request = necessarily duplicate the query parameters to keep it a valid OAuth = request plus an extension. Even if it doesn't wind up as a OAuth WG item it is probably worth = people looking at it before the final openID spec is voted on. Regards John B. On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: > Hi Nat, >=20 > I think your proposal would be a useful OAuth enhancement. A = JSON-based request format would allow for more complex requests (e.g. = carrying resource server URLs and corresponding scope values ;-)).=20 >=20 > Please note: I also think the way this mechanism is introduced and = used in the current OpenID connect spec requires OpenID connect clients = and servers to handle OAuth request parameters differently than for = standard OAuth requests. Introducing the JSON based claim request = capability to OAuth would be a way to cope with this. >=20 > regards, > Torsten. >=20 > Am 22.10.2011 16:00, schrieb Nat Sakimura: >>=20 >> Hi.=20 >>=20 >> Just a clarification:=20 >>=20 >> Although my expired draft is 'request by reference', what was = proposed through it at the iiw really is a generalized JSON based claim = request capability. It could be passed by value as JSON or could be = passed by reference. The later is an optimization for bandwidth = constrained network as well as strengthening security in some ways. This = capability already exists in OpenID Connect but it is actually an = underpinning transport, so it probably should belong to OAuth instead. = This was the primary reason for the proposal.=20 >>=20 >> Nat >>=20 >> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt = wrote: >> Hi all, >>=20 >> my prioritization is driven by the goal to make OAuth the = authorization framework of choice for any internet standard protocol, = such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is = missing from my point of view and explain some thoughts how to fill the = gaps. >>=20 >> A standard protocol is defined in terms of resource types and = messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in = many places, and used by different but deployment-independent clients. = OAuth-based protocol specifications must also define scope values (e.g. = read, write, send) and their relation to the resource types and = messages. The different deployments expose the standard protocol on = different resource server endpoints. In my opinion, it is fundamental to = clearly distinguish scope values (standardized, static) and resource = server addresses (deployment specific) and to manage their = relationships. The current scope definition is much to weak and = insufficient. Probably, the UMA concepts of hosts, resources sets, and = corresponding scopes could be adopted for that purpose. >>=20 >> OAuth today requires clients to register with the service provider = before they are deployed. Would you really expect IMAP clients, e.g. = Thunderbird, to register with any a-Mail services upfront? So clients = should be given a way to register dynamically to the authorization = servers. This should also allow us to cover "client instance" aspects. = It is interesting to note, that such a mechanism would allow us to get = rid of secret-less clients and the one-time usage requirement for = authorization codes. >>=20 >> We also assume the client to know the URLs of the resource server and = the corresponding authorization server and to use HTTPS server = authentication to verify the resource server's authenticity. This is = impossible in the standard scenario. Clients must be able to discover = the authorization server a particular resource server relies on at = runtime. The discovery mechanism could be specified by the OAuth WG, but = could also be part of an application protocols specification. But we = MUST find another way to prevent token phishing by counterfeit resource = servers. >>=20 >> As one approach, the client could pass the (previously HTTPS = validated) resource server's URL with the authorization request. The = authorization server should then refuse such requests for any unknown = (counterfeit) resource servers. Such an additional parameter could also = serve as namespace for scope values and enable service providers to run = multiple instances of the same service within a single deployment. >>=20 >> If the additional data enlarges the request payload to much, we could = consider to adopt the "request by reference" proposal. >>=20 >> Let's now assume, OAuth is successful in the world of standard = protocols and we will see plenty of deployments with a bunch of = different OAuth protected resource servers. Shall this servers all be = accessible with a single token? In my opinion, this would cause = security, privacy and/or scalability/performance problems. To give just = the most obvious example, the target audience of such a token cannot be = restricted enough, which may allow a resource server (or an attacker in = control of it) to abuse the token on other servers. But the current = design of the code grant type forces deployments to use the same token = for all services. What is needed from my point of view is a way to = request and issue multiple server-specific access tokens with a single = authorization process. >>=20 >> I've been advocating this topic for a long time now and I'm still = convinced this is required to really complete the core design. We at = Deutsche Telekom needed and implemented this function on top of the = existing core. In my opinion, a core enhancement would be easier to = handle and more powerful. If others support this topic, I would be = willed to submit an I-D describing a possible solution. >>=20 >> If we take standards really seriously, then service providers should = be given the opportunity to implement their service by utilizing = standard server implementations. This creates the challenge to find a = standardized protocol between authorization server and resource server = to exchange authorization data. Depending on the token design = (self-contained vs. handle) this could be solved by either standardizing = a token format (JWT) or an authorization API. >>=20 >> Based on the rationale given above, my list is as follows (topics w/o = I-D are marked with *): >>=20 >> - Revocation (low hanging fruit since I-D is ready and implemented in = some places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >>=20 >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >>=20 >> regards, >> Torsten. >> Zitat von Hannes Tschofenig : >>=20 >>=20 >> Hi all, >>=20 >> in preparation of the upcoming IETF meeting Barry and I would like to = start a re-chartering discussion. We both are currently attending the = Internet Identity Workshop and so we had the chance to solicit input = from the participants. This should serve as a discussion starter. >>=20 >> Potential future OAuth charter items (in random order): >>=20 >> ---------------- >>=20 >> 1) Dynamic Client Registration Protocol >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>=20 >> 2) Token Revocation >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>=20 >> 3) UMA >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>=20 >> 4) Client Instance Extension >>=20 >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>=20 >> 5) XML Encoding >>=20 >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>=20 >> 6) JSON Web Token >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>=20 >> 7) JSON Web Token (JWT) Bearer Profile >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>=20 >> 8) User Experience Extension >>=20 >> Available document: >> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>=20 >> 9) Request by Reference >>=20 >> Available document: >> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>=20 >> 10) Simple Web Discovery >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>=20 >> ---------------- >>=20 >> We have the following questions: >>=20 >> a) Are you interested in any of the above-listed items? (as a = reviewer, co-author, implementer, or someone who would like to deploy). = It is also useful to know if you think that we shouldn't work on a = specific item. >>=20 >> b) Are there other items you would like to see the group working on? >>=20 >> Note: In case your document is expired please re-submit it. >>=20 >> Ciao >> Hannes & Barry >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F02E2C6E-39A0-4FC9-83A1-4C9F6B339EE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Nat and I just refreshed the I-D = for draft-sakimura-oauth-requrl.

It is essentially =  a standardization of the method we are using in openID Connect to = make signed requests to the Authorization = server.

We do have the issue that parameters in = the signed/encrypted request necessarily duplicate the query parameters = to keep it a valid OAuth request plus an = extension.

Even if it doesn't wind up as a = OAuth WG item it is probably worth people looking at it before the final = openID spec is voted on.

Regards
John = B.

On 2011-10-26, at 3:16 PM, Torsten = Lodderstedt wrote:

=20 =20
Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 

Just a clarification: 

Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi = all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and  resource server = addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization = API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

 1) Dynamic Client Registration Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as = well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion. =  We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dyn= reg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-= revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-uma= core/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.= txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05=

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-= 00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00=

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-0= 0

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-discov= ery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

= --Apple-Mail=_F02E2C6E-39A0-4FC9-83A1-4C9F6B339EE9-- --Apple-Mail=_3C781098-1FD0-44AA-A95F-50AE869FBBEB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEw MjYyMjMxNDRaMCMGCSqGSIb3DQEJBDEWBBQygJxKR4bTC9T9Est96HqWj3Bw2DCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQCVDUQzG8+WsbwNdBmFsmwlHCwitdykGdKV2D8HEZl1dUA7ivZ1Gx0i6HZVPXbc6HMdJQ8NnldQ EBk1y3suJo9Lcrv6I98IVnE/J1/yL3w/6jW0VoySW3lZS2DxTpvKr865dfYS7YkPwkQQlmB3XRnT 6JPOSEOvRtLupNXL+uJ3qv2TBWRVrK48xTAmxpnYSbhibE9EnoSJPkx+DE4pO4k9q9HIhEubONyA p2KeBJ6eiLNfg+e9zToxlSMGQdY48qcNawZGFy+uH1pq5z07lM44Ht0qihEEuxy37geWUMJCnanm qNBzeo8KV3HwJEjJdfG7qPQFff7vKQNsvyy1BZkmAAAAAAAA --Apple-Mail=_3C781098-1FD0-44AA-A95F-50AE869FBBEB-- From ve7jtb@ve7jtb.com Wed Oct 26 15:42:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC9211E80A6 for ; Wed, 26 Oct 2011 15:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPEnElMniYxC for ; Wed, 26 Oct 2011 15:42:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8339A11E808A for ; Wed, 26 Oct 2011 15:42:54 -0700 (PDT) Received: by ywt2 with SMTP id 2so2387322ywt.31 for ; Wed, 26 Oct 2011 15:42:54 -0700 (PDT) Received: by 10.151.87.19 with SMTP id p19mr9203377ybl.71.1319668974092; Wed, 26 Oct 2011 15:42:54 -0700 (PDT) Received: from [192.168.1.213] ([190.22.12.103]) by mx.google.com with ESMTPS id 36sm9061702anz.2.2011.10.26.15.42.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Oct 2011 15:42:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_D9BBAF70-7E28-453C-92E6-8571E0784B8C"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 26 Oct 2011 19:42:32 -0300 Message-Id: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG , Dan Taflin Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 22:42:56 -0000 --Apple-Mail=_D9BBAF70-7E28-453C-92E6-8571E0784B8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Connect use case was a bit different for needing a id_token however = your proposal would work if being less efficient for the code flow. However in the implicit flow you can't get a refresh token so the only = option is to make the user go through multiple authorizations, or return = multiple tokens. We went with the multiple token option, by registering new = response_type. Not necessarily the perfect solution but one that works as an extension. John B. On 2011-10-26, at 1:15 PM, Eran Hammer-Lahav wrote: > Why not just ask for one access token with all the scopes you need, = then refresh it by asking for the different subsets you want. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Dan Taflin >> Sent: Tuesday, October 25, 2011 3:37 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >>=20 >> I would like to second Torsten's pitch for the ability to return = multiple access >> tokens with a single authorization process. The use case for my = company is to >> segment operations into two main categories: protected and = confidential. (A >> possible third category, public, would not require any authorization = at all). >> Protected operations would be user-specific operations that don't = involve >> the passing of any sensitive information, such as image search = results tagged >> with information about whether each image is available for download = by that >> user. Confidential operations would involve passing user data, like = user >> registration or e-commerce. We would like to protect each category of >> operations with distinct tokens: a general-use token for protected >> operations, and a secure token for confidential operations. >>=20 >> We could use the scope parameter to specify either "protected" or >> "confidential". Currently the oauth spec allows a Refresh token to = request a >> new token with reduced scope from the one originally issued, but = there is no >> way to obtain a new token with a completely different scope without = doing >> the full oauth dance a second time. >>=20 >> Dan >>=20 >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Thursday, October 20, 2011 3:57 PM >> To: Hannes Tschofenig >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >>=20 >> Hi all, >>=20 >> my prioritization is driven by the goal to make OAuth the = authorization >> framework of choice for any internet standard protocol, such as = WebDAV, >> IMAP, SMTP or SIP. So let me first explain what is missing from my = point of >> view and explain some thoughts how to fill the gaps. >>=20 >> A standard protocol is defined in terms of resource types and = messages by a >> body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, = and >> used by different but deployment-independent clients. >> OAuth-based protocol specifications must also define scope values = (e.g. >> read, write, send) and their relation to the resource types and = messages. The >> different deployments expose the standard protocol on different = resource >> server endpoints. In my opinion, it is fundamental >> to clearly distinguish scope values (standardized, static) and >> resource server addresses (deployment specific) and to manage their >> relationships. The current scope definition is much to weak and = insufficient. >> Probably, the UMA concepts of hosts, resources sets, and = corresponding >> scopes could be adopted for that purpose. >>=20 >> OAuth today requires clients to register with the service provider = before >> they are deployed. Would you really expect IMAP clients, e.g. >> Thunderbird, to register with any a-Mail services upfront? So clients = should >> be given a way to register dynamically to the authorization servers. = This >> should also allow us to cover "client instance" aspects. >> It is interesting to note, that such a mechanism would allow us to = get rid of >> secret-less clients and the one-time usage requirement for = authorization >> codes. >>=20 >> We also assume the client to know the URLs of the resource server and = the >> corresponding authorization server and to use HTTPS server = authentication >> to verify the resource server's authenticity. This is impossible in = the standard >> scenario. Clients must be able to discover the authorization server a >> particular resource server relies on at runtime. The discovery = mechanism >> could be specified by the OAuth WG, but could also be part of an = application >> protocols specification. But we MUST find another way to prevent = token >> phishing by counterfeit resource servers. >>=20 >> As one approach, the client could pass the (previously HTTPS >> validated) resource server's URL with the authorization request. The >> authorization server should then refuse such requests for any unknown >> (counterfeit) resource servers. Such an additional parameter could = also serve >> as namespace for scope values and enable service providers to run = multiple >> instances of the same service within a single deployment. >>=20 >> If the additional data enlarges the request payload to much, we could >> consider to adopt the "request by reference" proposal. >>=20 >> Let's now assume, OAuth is successful in the world of standard = protocols and >> we will see plenty of deployments with a bunch of different OAuth >> protected resource servers. Shall this servers all be accessible with = a single >> token? In my opinion, this would cause security, privacy and/or >> scalability/performance problems. To give just the most obvious = example, >> the target audience of such a token cannot be restricted enough, = which may >> allow a resource server (or an attacker in control of it) to abuse = the token on >> other servers. But the current design of the code grant type forces >> deployments to use the same token for all services. What is needed = from my >> point of view is a way to request and issue multiple server-specific = access >> tokens with a single authorization process. >>=20 >> I've been advocating this topic for a long time now and I'm still = convinced this >> is required to really complete the core design. We at Deutsche = Telekom >> needed and implemented this function on top of the existing core. In = my >> opinion, a core enhancement would be easier to handle and more = powerful. >> If others support this topic, I would be willed to submit an I-D = describing a >> possible solution. >>=20 >> If we take standards really seriously, then service providers should = be given >> the opportunity to implement their service by utilizing standard = server >> implementations. This creates the challenge to find a standardized = protocol >> between authorization server and resource server to exchange = authorization >> data. Depending on the token design (self-contained vs. handle) this = could >> be solved by either standardizing a token format (JWT) or an = authorization >> API. >>=20 >> Based on the rationale given above, my list is as follows (topics w/o = I-D are >> marked with *): >>=20 >> - Revocation (low hanging fruit since I-D is ready and implemented in = some >> places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >>=20 >> regards, >> Torsten. >> Zitat von Hannes Tschofenig : >>=20 >>> Hi all, >>>=20 >>> in preparation of the upcoming IETF meeting Barry and I would like = to >>> start a re-chartering discussion. We both are currently attending = the >>> Internet Identity Workshop and so we had the chance to solicit input >>> from the participants. This should serve as a discussion starter. >>>=20 >>> Potential future OAuth charter items (in random order): >>>=20 >>> ---------------- >>>=20 >>> 1) Dynamic Client Registration Protocol >>>=20 >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>>=20 >>> 2) Token Revocation >>>=20 >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>>=20 >>> 3) UMA >>>=20 >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>>=20 >>> 4) Client Instance Extension >>>=20 >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>>=20 >>> 5) XML Encoding >>>=20 >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>>=20 >>> 6) JSON Web Token >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>>=20 >>> 7) JSON Web Token (JWT) Bearer Profile >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>>=20 >>> 8) User Experience Extension >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>>=20 >>> 9) Request by Reference >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>>=20 >>> 10) Simple Web Discovery >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>>=20 >>> ---------------- >>>=20 >>> We have the following questions: >>>=20 >>> a) Are you interested in any of the above-listed items? (as a >>> reviewer, co-author, implementer, or someone who would like to >>> deploy). It is also useful to know if you think that we shouldn't = work >>> on a specific item. >>>=20 >>> b) Are there other items you would like to see the group working on? >>>=20 >>> Note: In case your document is expired please re-submit it. >>>=20 >>> Ciao >>> Hannes & Barry >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_D9BBAF70-7E28-453C-92E6-8571E0784B8C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEw MjYyMjQyMzJaMCMGCSqGSIb3DQEJBDEWBBQSE4VAVVwL6hj46mR3GxVkiizEZjCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAEUc4C90RBYQa3appsgpiruOCzrdy6hX4HxZGSP5zHs9vaqclIaD/GQGnjmHA4rt/338AiWbh8 DAq5XHsjVOCcij8Btuay+/y4K1/USVuupdVby/JvHJVeNP6KCXFyp52ozen+SGJ2ZhNbGc1Lrxcj ZKLQXlc82/T006fxh4Dr6AkRNe5zG+x3Z3dUmPwZ4x5JkOIptiNAMKocxxVf8PxrcJZ517bv+bK0 q0yLGC9YrMYw0aKAjHAi4lOqtdN7YplKVwA4g6FnNaA63fEkLyIBycnLjcuFFxdxPiyG51Jfwebk 0IYZEz7EX5PMZo1XTPHcR9cNRSfM4H84eta/IZr8AAAAAAAA --Apple-Mail=_D9BBAF70-7E28-453C-92E6-8571E0784B8C-- From torsten@lodderstedt.net Wed Oct 26 22:22:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4A21F8A64 for ; Wed, 26 Oct 2011 22:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTKwuBLDTYmW for ; Wed, 26 Oct 2011 22:22:43 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 83BAC21F8A55 for ; Wed, 26 Oct 2011 22:22:41 -0700 (PDT) Received: from [79.253.61.184] (helo=[192.168.71.26]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RJIQD-0002mF-I2; Thu, 27 Oct 2011 07:22:33 +0200 Message-ID: <4EA8EA99.4010203@lodderstedt.net> Date: Thu, 27 Oct 2011 07:22:33 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Bradley References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040704030006000201080906" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 05:22:45 -0000 This is a multi-part message in MIME format. --------------040704030006000201080906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit why is it neccessary to duplicate the OAuth request parameters? Am 27.10.2011 00:31, schrieb John Bradley: > Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. > > It is essentially a standardization of the method we are using in > openID Connect to make signed requests to the Authorization server. > > We do have the issue that parameters in the signed/encrypted request > necessarily duplicate the query parameters to keep it a valid OAuth > request plus an extension. > > Even if it doesn't wind up as a OAuth WG item it is probably worth > people looking at it before the final openID spec is voted on. > > Regards > John B. > > On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: > >> Hi Nat, >> >> I think your proposal would be a useful OAuth enhancement. A >> JSON-based request format would allow for more complex requests (e.g. >> carrying resource server URLs and corresponding scope values ;-)). >> >> Please note: I also think the way this mechanism is introduced and >> used in the current OpenID connect spec requires OpenID connect >> clients and servers to handle OAuth request parameters differently >> than for standard OAuth requests. Introducing the JSON based claim >> request capability to OAuth would be a way to cope with this. >> >> regards, >> Torsten. >> >> Am 22.10.2011 16:00, schrieb Nat Sakimura: >>> Hi. >>> >>> Just a clarification: >>> >>> Although my expired draft is 'request by reference', what was >>> proposed through it at the iiw really is a generalized JSON based >>> claim request capability. It could be passed by value as JSON or >>> could be passed by reference. The later is an optimization for >>> bandwidth constrained network as well as strengthening security in >>> some ways. This capability already exists in OpenID Connect but it >>> is actually an underpinning transport, so it probably should belong >>> to OAuth instead. This was the primary reason for the proposal. >>> >>> Nat >>> >>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt >>> > wrote: >>> >>> Hi all, >>> >>> my prioritization is driven by the goal to make OAuth the >>> authorization framework of choice for any internet standard >>> protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first >>> explain what is missing from my point of view and explain some >>> thoughts how to fill the gaps. >>> >>> A standard protocol is defined in terms of resource types and >>> messages by a body (e.g. IETF, OIDF, OMA), (hopefully) >>> implemented in many places, and used by different but >>> deployment-independent clients. OAuth-based protocol >>> specifications must also define scope values (e.g. read, write, >>> send) and their relation to the resource types and messages. The >>> different deployments expose the standard protocol on different >>> resource server endpoints. In my opinion, it is fundamental to >>> clearly distinguish scope values (standardized, static) and >>> resource server addresses (deployment specific) and to manage >>> their relationships. The current scope definition is much to >>> weak and insufficient. Probably, the UMA concepts of hosts, >>> resources sets, and corresponding scopes could be adopted for >>> that purpose. >>> >>> OAuth today requires clients to register with the service >>> provider before they are deployed. Would you really expect IMAP >>> clients, e.g. Thunderbird, to register with any a-Mail services >>> upfront? So clients should be given a way to register >>> dynamically to the authorization servers. This should also allow >>> us to cover "client instance" aspects. It is interesting to >>> note, that such a mechanism would allow us to get rid of >>> secret-less clients and the one-time usage requirement for >>> authorization codes. >>> >>> We also assume the client to know the URLs of the resource >>> server and the corresponding authorization server and to use >>> HTTPS server authentication to verify the resource server's >>> authenticity. This is impossible in the standard scenario. >>> Clients must be able to discover the authorization server a >>> particular resource server relies on at runtime. The discovery >>> mechanism could be specified by the OAuth WG, but could also be >>> part of an application protocols specification. But we MUST find >>> another way to prevent token phishing by counterfeit resource >>> servers. >>> >>> As one approach, the client could pass the (previously HTTPS >>> validated) resource server's URL with the authorization request. >>> The authorization server should then refuse such requests for >>> any unknown (counterfeit) resource servers. Such an additional >>> parameter could also serve as namespace for scope values and >>> enable service providers to run multiple instances of the same >>> service within a single deployment. >>> >>> If the additional data enlarges the request payload to much, we >>> could consider to adopt the "request by reference" proposal. >>> >>> Let's now assume, OAuth is successful in the world of standard >>> protocols and we will see plenty of deployments with a bunch of >>> different OAuth protected resource servers. Shall this servers >>> all be accessible with a single token? In my opinion, this would >>> cause security, privacy and/or scalability/performance problems. >>> To give just the most obvious example, the target audience of >>> such a token cannot be restricted enough, which may allow a >>> resource server (or an attacker in control of it) to abuse the >>> token on other servers. But the current design of the code grant >>> type forces deployments to use the same token for all services. >>> What is needed from my point of view is a way to request and >>> issue multiple server-specific access tokens with a single >>> authorization process. >>> >>> I've been advocating this topic for a long time now and I'm >>> still convinced this is required to really complete the core >>> design. We at Deutsche Telekom needed and implemented this >>> function on top of the existing core. In my opinion, a core >>> enhancement would be easier to handle and more powerful. If >>> others support this topic, I would be willed to submit an I-D >>> describing a possible solution. >>> >>> If we take standards really seriously, then service providers >>> should be given the opportunity to implement their service by >>> utilizing standard server implementations. This creates the >>> challenge to find a standardized protocol between authorization >>> server and resource server to exchange authorization data. >>> Depending on the token design (self-contained vs. handle) this >>> could be solved by either standardizing a token format (JWT) or >>> an authorization API. >>> >>> Based on the rationale given above, my list is as follows >>> (topics w/o I-D are marked with *): >>> >>> - Revocation (low hanging fruit since I-D is ready and >>> implemented in some places) >>> - Resource server notion* >>> - Multiple access tokens* >>> - Dynamic client registration >>> >>> 1) Dynamic Client Registration Protocol >>> 4) Client Instance Extension >>> - Discovery >>> (10) Simple Web Discovery, probably other specs as well >>> - (6) JSON Web Token >>> - (7) JSON Web Token (JWT) Bearer Profile >>> - 8) User Experience Extension >>> - Device flow >>> - 9) Request by Reference >>> (depending resource server notion and multiple access tokens) >>> >>> regards, >>> Torsten. >>> Zitat von Hannes Tschofenig >> >: >>> >>> >>> Hi all, >>> >>> in preparation of the upcoming IETF meeting Barry and I >>> would like to start a re-chartering discussion. We both are >>> currently attending the Internet Identity Workshop and so we >>> had the chance to solicit input from the participants. This >>> should serve as a discussion starter. >>> >>> Potential future OAuth charter items (in random order): >>> >>> ---------------- >>> >>> 1) Dynamic Client Registration Protocol >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>> >>> 2) Token Revocation >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>> >>> 3) UMA >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>> >>> 4) Client Instance Extension >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>> >>> 5) XML Encoding >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>> >>> 6) JSON Web Token >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>> >>> 7) JSON Web Token (JWT) Bearer Profile >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>> >>> 8) User Experience Extension >>> >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>> >>> 9) Request by Reference >>> >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>> >>> 10) Simple Web Discovery >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>> >>> ---------------- >>> >>> We have the following questions: >>> >>> a) Are you interested in any of the above-listed items? (as >>> a reviewer, co-author, implementer, or someone who would >>> like to deploy). It is also useful to know if you think that >>> we shouldn't work on a specific item. >>> >>> b) Are there other items you would like to see the group >>> working on? >>> >>> Note: In case your document is expired please re-submit it. >>> >>> Ciao >>> Hannes & Barry >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --------------040704030006000201080906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in openID Connect to make signed requests to the Authorization server.

We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension.

Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on.

Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:

Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 

Just a clarification: 

Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and  resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

 1) Dynamic Client Registration Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion.  We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------040704030006000201080906-- From craigmcc@gmail.com Wed Oct 26 23:10:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDA021F88B6 for ; Wed, 26 Oct 2011 23:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvajz+-64drq for ; Wed, 26 Oct 2011 23:10:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6175E21F8997 for ; Wed, 26 Oct 2011 23:10:10 -0700 (PDT) Received: by wyh22 with SMTP id 22so2857148wyh.31 for ; Wed, 26 Oct 2011 23:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qOXcKh4BiwMnMjMfyMIM7V75LbaJKNFSsab1X2HHiW4=; b=g4nyuSouX++AFjDTFn3JQZSgPZ/lmPeGwpLIC5/ztl4//F3Cg5385U5GIe3dFbDKTR ugdGE8f1AQbcO7oLulRbef3kgze8pjM53QUT6k5nc1EqenZDBIi+mJgAk6tx/yN7/Hyw pFoiCu35wemMl++asrwsMyt22Xe5cNrSdO62Q= MIME-Version: 1.0 Received: by 10.227.208.71 with SMTP id gb7mr13853633wbb.7.1319695805429; Wed, 26 Oct 2011 23:10:05 -0700 (PDT) Received: by 10.180.107.134 with HTTP; Wed, 26 Oct 2011 23:10:05 -0700 (PDT) In-Reply-To: <4E73A431.2020205@lodderstedt.net> References: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> <4E73A431.2020205@lodderstedt.net> Date: Wed, 26 Oct 2011 23:10:05 -0700 Message-ID: From: Craig McClanahan To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001517448430b1b87b04b0419f91 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: craigmcc@gmail.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 06:10:12 -0000 --001517448430b1b87b04b0419f91 Content-Type: text/plain; charset=ISO-8859-1 As a substantive comment on the draft (I'm in favor of it being a working group item), it is not clear whether "Basic" is a required value on the "Authorization" header included in a revocation request. In some scenarios (particularly three legged), the client app will not possess the username and password of they end user -- it might only possess a currently valid access token. It would seem that including such a token should be a viable authentication mechanism. Craig McClanahan On Fri, Sep 16, 2011 at 12:32 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi all, > > I just published a new revision of the token revocation draft. We added > JSONP support (thanks to Marius) and aligned the text with draft 21 of the > core spec. > > We would like to bring this draft forward as working group item (once the > WG is ready). We think its relevance is illustrated by the fact that this > draft (or its predecessor) has already been implemented by Google, > Salesforce, and Deutsche Telekom. > > regards, > Torsten. > > -------- Original-Nachricht -------- Betreff: New Version Notification > for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 > 12:20:14 -0700 Von: internet-drafts@ietf.org An: torsten@lodderstedt.net CC: > sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com > > A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. > > Filename: draft-lodderstedt-oauth-revocation > Revision: 03 > Title: Token Revocation > Creation date: 2011-09-16 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This draft proposes an additional endpoint for OAuth authorization > servers for revoking tokens. > > > > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001517448430b1b87b04b0419f91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a substantive comment on the draft (I'm in favor of it being a worki= ng group item), it is not clear whether "Basic" is a required val= ue on the "Authorization" header included in a revocation request= . =A0In some scenarios (particularly three legged), the client app will not= possess the username and password of they end user -- it might only posses= s a currently valid access token. =A0It would seem that including such a to= ken should be a viable authentication mechanism.

Craig McClanahan

On Fri, S= ep 16, 2011 at 12:32 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
=20 =20 =20
Hi all,

I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec.

We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom.

regards,
Torsten.

-------- Original-Nachricht --------
Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
Datum: Fri, 16 Sep 2011 12:20:14 -0700
Von: internet-drafts@ietf.org
An: = torsten@lodderstedt.net
CC: sdronia@g= mx.de, tor= sten@lodderstedt.net, mscu= rtescu@google.com 


A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt ha=
s been successfully submitted by Torsten Lodderstedt and posted to the IETF=
 repository.

Filename:	 draft-lodderstedt-oauth-revocation
Revision:	 03
Title:		 Token Revocation
Creation date:	 2011-09-16
WG ID:		 Individual Submission
Number of pages: 6

Abstract:
   This draft proposes an additional endpoint for OAuth authorization
   servers for revoking tokens.

                                                                           =
      =20


The IETF Secretariat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--001517448430b1b87b04b0419f91-- From torsten@lodderstedt.net Thu Oct 27 08:06:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4121F8573 for ; Thu, 27 Oct 2011 08:06:54 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpT0pCoRNFkc for ; Thu, 27 Oct 2011 08:06:53 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by ietfa.amsl.com (Postfix) with ESMTP id 439E021F8593 for ; Thu, 27 Oct 2011 08:06:52 -0700 (PDT) Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1RJRXf-0003fB-5S; Thu, 27 Oct 2011 17:06:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2000fa0084b7af4abe14da28579fa45c" Date: Thu, 27 Oct 2011 17:06:51 +0200 From: Torsten Lodderstedt To: In-Reply-To: References: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> <4E73A431.2020205@lodderstedt.net> Message-ID: <03d705c8b2c4194234a67d836e0086d2@lodderstedt-online.de> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.6 X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:06:54 -0000 --=_2000fa0084b7af4abe14da28579fa45c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi Craig, thanks for your comment. The revocation endpoint uses the same authentication policy as the core spec. Confidential client must authenticate using their client secret (or any other credential). The end-user's credentials are not involved at all. regards, Torsten. Am 27.10.2011 08:10, schrieb Craig McClanahan: > As a substantive comment on the draft (I'm in favor of it being a working group item), it is not clear whether "Basic" is a required value on the "Authorization" header included in a revocation request. In some scenarios (particularly three legged), the client app will not possess the username and password of they end user -- it might only possess a currently valid access token. It would seem that including such a token should be a viable authentication mechanism. > Craig McClanahan > > On Fri, Sep 16, 2011 at 12:32 PM, Torsten Lodderstedt wrote: > >> Hi all, >> >> I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec. >> >> We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom. >> >> regards, >> Torsten. >> >> -------- Original-Nachricht -------- >> >> BETREFF: >> New Version Notification for draft-lodderstedt-oauth-revocation-03.txt >> >> DATUM: >> Fri, 16 Sep 2011 12:20:14 -0700 >> >> VON: >> internet-drafts@ietf.org [1] >> >> AN: >> torsten@lodderstedt.net [2] >> >> CC: >> sdronia@gmx.de [3], torsten@lodderstedt.net [4], mscurtescu@google.com [5] >> >> A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. >> >> Filename: draft-lodderstedt-oauth-revocation >> Revision: 03 >> Title: Token Revocation >> Creation date: 2011-09-16 >> WG ID: Individual Submission >> Number of pages: 6 >> >> Abstract: >> This draft proposes an additional endpoint for OAuth authorization >> servers for revoking tokens. >> >> The IETF Secretariat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org [6] >> https://www.ietf.org/mailman/listinfo/oauth [7] Links: ------ [1] mailto:internet-drafts@ietf.org [2] mailto:torsten@lodderstedt.net [3] mailto:sdronia@gmx.de [4] mailto:torsten@lodderstedt.net [5] mailto:mscurtescu@google.com [6] mailto:OAuth@ietf.org [7] https://www.ietf.org/mailman/listinfo/oauth [8] mailto:torsten@lodderstedt.net --=_2000fa0084b7af4abe14da28579fa45c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Craig,

thanks for your comment.

The revocation endpoint uses the same authentication policy as the core = spec. Confidential client must authenticate using their client secret (or a= ny other credential). The end-user's credentials are not involved at all.

regards,
Torsten.

 

Am 27.10.2011 08:10, schrieb Craig McClanahan:

As a substantive comment on the draft (I'm in favor of it being a workin= g group item), it is not clear whether "Basic" is a required value on the "= Authorization" header included in a revocation request.  In some scena= rios (particularly three legged), the client app will not possess the usern= ame and password of they end user -- it might only possess a currently vali= d access token.  It would seem that including such a token should be a= viable authentication mechanism.

Craig McClanahan

On Fri, Sep 16, 2011 at 12:32 PM, Torsten Lodder= stedt <torsten@lodderst= edt.net> wrote:
Hi all,

I just published a new revision of the token revoc= ation draft. We added JSONP support (thanks to Marius) and aligned the text= with draft 21 of the core spec.

We would like to bring this dr= aft forward as working group item (once the WG is ready). We think its rele= vance is illustrated by the fact that this draft (or its predecessor) has a= lready been implemented by Google, Salesforce, and Deutsche Telekom.
<= br /> regards,
Torsten.

-------- Original-Nachricht ------= --
Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt<= /td>
Datum: Fri, 16 Sep 2011 12:20:14 -0700
Von: internet-drafts@ietf.org
An: torsten@lodderstedt.net<= /td>
CC: sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com 


A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has be=
en successfully submitted by Torsten Lodderstedt and posted to the IETF rep=
ository.

Filename:	 draft-lodderstedt-oauth-revocation
Revision:	 03
Title:		 Token Revocation
Creation date:	 2011-09-16
WG ID:		 Individual Submission
Number of pages: 6

Abstract:
   This draft proposes an additional endpoint for OAuth authorization
   servers for revoking tokens.

                                                                           =
      =20


The IETF Secretariat

_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth

 
--=_2000fa0084b7af4abe14da28579fa45c-- From igor.faynberg@alcatel-lucent.com Thu Oct 27 09:22:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376AF21F8663 for ; Thu, 27 Oct 2011 09:22:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjGJgvRarh4N for ; Thu, 27 Oct 2011 09:22:00 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A7B1821F861E for ; Thu, 27 Oct 2011 09:22:00 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9RGLxK3009759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Oct 2011 11:21:59 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9RGLwBl012751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 27 Oct 2011 11:21:59 -0500 Received: from [135.222.134.155] (USMUYN0L055118.mh.lucent.com [135.222.134.155]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9RGLwh8010012; Thu, 27 Oct 2011 11:21:58 -0500 (CDT) Message-ID: <4EA98526.3060704@alcatel-lucent.com> Date: Thu, 27 Oct 2011 12:21:58 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:22:01 -0000 On 10/26/2011 6:31 PM, John Bradley wrote: From igor.faynberg@alcatel-lucent.com Thu Oct 27 09:25:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D14A21F8B18 for ; Thu, 27 Oct 2011 09:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIcANZBxBqHK for ; Thu, 27 Oct 2011 09:25:16 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5A05621F8696 for ; Thu, 27 Oct 2011 09:25:16 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p9RGPFXH007438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Oct 2011 11:25:15 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9RGPEja031543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 27 Oct 2011 11:25:15 -0500 Received: from [135.222.134.155] (USMUYN0L055118.mh.lucent.com [135.222.134.155]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9RGP9pZ012579; Thu, 27 Oct 2011 11:25:09 -0500 (CDT) Message-ID: <4EA985E4.8020101@alcatel-lucent.com> Date: Thu, 27 Oct 2011 12:25:08 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010504020007060804060103" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:25:18 -0000 This is a multi-part message in MIME format. --------------010504020007060804060103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Many thanks for pointing this! It is *absolutely* (not "probably") worth studying. Igor On 10/26/2011 6:31 PM, John Bradley wrote: > Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. > > It is essentially a standardization of the method we are using in > openID Connect to make signed requests to the Authorization server. > > We do have the issue that parameters in the signed/encrypted request > necessarily duplicate the query parameters to keep it a valid OAuth > request plus an extension. > > Even if it doesn't wind up as a OAuth WG item it is probably worth > people looking at it before the final openID spec is voted on. > > Regards > John B. > > On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: > >> Hi Nat, >> >> I think your proposal would be a useful OAuth enhancement. A >> JSON-based request format would allow for more complex requests (e.g. >> carrying resource server URLs and corresponding scope values ;-)). >> >> Please note: I also think the way this mechanism is introduced and >> used in the current OpenID connect spec requires OpenID connect >> clients and servers to handle OAuth request parameters differently >> than for standard OAuth requests. Introducing the JSON based claim >> request capability to OAuth would be a way to cope with this. >> >> regards, >> Torsten. >> >> Am 22.10.2011 16:00, schrieb Nat Sakimura: >>> Hi. >>> >>> Just a clarification: >>> >>> Although my expired draft is 'request by reference', what was >>> proposed through it at the iiw really is a generalized JSON based >>> claim request capability. It could be passed by value as JSON or >>> could be passed by reference. The later is an optimization for >>> bandwidth constrained network as well as strengthening security in >>> some ways. This capability already exists in OpenID Connect but it >>> is actually an underpinning transport, so it probably should belong >>> to OAuth instead. This was the primary reason for the proposal. >>> >>> Nat >>> >>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt >>> > wrote: >>> >>> Hi all, >>> >>> my prioritization is driven by the goal to make OAuth the >>> authorization framework of choice for any internet standard >>> protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first >>> explain what is missing from my point of view and explain some >>> thoughts how to fill the gaps. >>> >>> A standard protocol is defined in terms of resource types and >>> messages by a body (e.g. IETF, OIDF, OMA), (hopefully) >>> implemented in many places, and used by different but >>> deployment-independent clients. OAuth-based protocol >>> specifications must also define scope values (e.g. read, write, >>> send) and their relation to the resource types and messages. The >>> different deployments expose the standard protocol on different >>> resource server endpoints. In my opinion, it is fundamental to >>> clearly distinguish scope values (standardized, static) and >>> resource server addresses (deployment specific) and to manage >>> their relationships. The current scope definition is much to >>> weak and insufficient. Probably, the UMA concepts of hosts, >>> resources sets, and corresponding scopes could be adopted for >>> that purpose. >>> >>> OAuth today requires clients to register with the service >>> provider before they are deployed. Would you really expect IMAP >>> clients, e.g. Thunderbird, to register with any a-Mail services >>> upfront? So clients should be given a way to register >>> dynamically to the authorization servers. This should also allow >>> us to cover "client instance" aspects. It is interesting to >>> note, that such a mechanism would allow us to get rid of >>> secret-less clients and the one-time usage requirement for >>> authorization codes. >>> >>> We also assume the client to know the URLs of the resource >>> server and the corresponding authorization server and to use >>> HTTPS server authentication to verify the resource server's >>> authenticity. This is impossible in the standard scenario. >>> Clients must be able to discover the authorization server a >>> particular resource server relies on at runtime. The discovery >>> mechanism could be specified by the OAuth WG, but could also be >>> part of an application protocols specification. But we MUST find >>> another way to prevent token phishing by counterfeit resource >>> servers. >>> >>> As one approach, the client could pass the (previously HTTPS >>> validated) resource server's URL with the authorization request. >>> The authorization server should then refuse such requests for >>> any unknown (counterfeit) resource servers. Such an additional >>> parameter could also serve as namespace for scope values and >>> enable service providers to run multiple instances of the same >>> service within a single deployment. >>> >>> If the additional data enlarges the request payload to much, we >>> could consider to adopt the "request by reference" proposal. >>> >>> Let's now assume, OAuth is successful in the world of standard >>> protocols and we will see plenty of deployments with a bunch of >>> different OAuth protected resource servers. Shall this servers >>> all be accessible with a single token? In my opinion, this would >>> cause security, privacy and/or scalability/performance problems. >>> To give just the most obvious example, the target audience of >>> such a token cannot be restricted enough, which may allow a >>> resource server (or an attacker in control of it) to abuse the >>> token on other servers. But the current design of the code grant >>> type forces deployments to use the same token for all services. >>> What is needed from my point of view is a way to request and >>> issue multiple server-specific access tokens with a single >>> authorization process. >>> >>> I've been advocating this topic for a long time now and I'm >>> still convinced this is required to really complete the core >>> design. We at Deutsche Telekom needed and implemented this >>> function on top of the existing core. In my opinion, a core >>> enhancement would be easier to handle and more powerful. If >>> others support this topic, I would be willed to submit an I-D >>> describing a possible solution. >>> >>> If we take standards really seriously, then service providers >>> should be given the opportunity to implement their service by >>> utilizing standard server implementations. This creates the >>> challenge to find a standardized protocol between authorization >>> server and resource server to exchange authorization data. >>> Depending on the token design (self-contained vs. handle) this >>> could be solved by either standardizing a token format (JWT) or >>> an authorization API. >>> >>> Based on the rationale given above, my list is as follows >>> (topics w/o I-D are marked with *): >>> >>> - Revocation (low hanging fruit since I-D is ready and >>> implemented in some places) >>> - Resource server notion* >>> - Multiple access tokens* >>> - Dynamic client registration >>> >>> 1) Dynamic Client Registration Protocol >>> 4) Client Instance Extension >>> - Discovery >>> (10) Simple Web Discovery, probably other specs as well >>> - (6) JSON Web Token >>> - (7) JSON Web Token (JWT) Bearer Profile >>> - 8) User Experience Extension >>> - Device flow >>> - 9) Request by Reference >>> (depending resource server notion and multiple access tokens) >>> >>> regards, >>> Torsten. >>> Zitat von Hannes Tschofenig >> >: >>> >>> >>> Hi all, >>> >>> in preparation of the upcoming IETF meeting Barry and I >>> would like to start a re-chartering discussion. We both are >>> currently attending the Internet Identity Workshop and so we >>> had the chance to solicit input from the participants. This >>> should serve as a discussion starter. >>> >>> Potential future OAuth charter items (in random order): >>> >>> ---------------- >>> >>> 1) Dynamic Client Registration Protocol >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>> >>> 2) Token Revocation >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>> >>> 3) UMA >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>> >>> 4) Client Instance Extension >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>> >>> 5) XML Encoding >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>> >>> 6) JSON Web Token >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>> >>> 7) JSON Web Token (JWT) Bearer Profile >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>> >>> 8) User Experience Extension >>> >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>> >>> 9) Request by Reference >>> >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>> >>> 10) Simple Web Discovery >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>> >>> ---------------- >>> >>> We have the following questions: >>> >>> a) Are you interested in any of the above-listed items? (as >>> a reviewer, co-author, implementer, or someone who would >>> like to deploy). It is also useful to know if you think that >>> we shouldn't work on a specific item. >>> >>> b) Are there other items you would like to see the group >>> working on? >>> >>> Note: In case your document is expired please re-submit it. >>> >>> Ciao >>> Hannes & Barry >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >> _______________________________________________ >> 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 --------------010504020007060804060103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Many thanks for pointing this!  It is *absolutely* (not "probably") worth studying.

Igor

On 10/26/2011 6:31 PM, John Bradley wrote:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in openID Connect to make signed requests to the Authorization server.

We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension.

Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on.

Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:

Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 

Just a clarification: 

Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and  resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

 1) Dynamic Client Registration Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion.  We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
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
--------------010504020007060804060103-- From ve7jtb@ve7jtb.com Thu Oct 27 09:52:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3105A21F8AD8 for ; Thu, 27 Oct 2011 09:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xtfxQkPEB-3 for ; Thu, 27 Oct 2011 09:52:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44EFC21F8AAC for ; Thu, 27 Oct 2011 09:52:41 -0700 (PDT) Received: by ywt2 with SMTP id 2so3348539ywt.31 for ; Thu, 27 Oct 2011 09:52:39 -0700 (PDT) Received: by 10.150.244.6 with SMTP id r6mr3324909ybh.97.1319734359757; Thu, 27 Oct 2011 09:52:39 -0700 (PDT) Received: from [192.168.1.213] ([190.22.32.0]) by mx.google.com with ESMTPS id 4sm16403258ano.9.2011.10.27.09.52.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Oct 2011 09:52:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_000E5359-594D-4543-9030-C720CBE12A5A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4EA8EA99.4010203@lodderstedt.net> Date: Thu, 27 Oct 2011 13:52:31 -0300 Message-Id: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> <4EA8EA99.4010203@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:52:43 -0000 --Apple-Mail=_000E5359-594D-4543-9030-C720CBE12A5A Content-Type: multipart/alternative; boundary="Apple-Mail=_A2F92E11-E86C-44C6-AD76-219ACEF254FD" --Apple-Mail=_A2F92E11-E86C-44C6-AD76-219ACEF254FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hopefully to make it more compatible with existing OAuth 2 libraries. = At least leave open the possibility of dealing with it at a higher = level. The argument has been made that you probably need to modify the library = anyway to check that the duplicate parameters are a match. If there is consensus that the parameters should only be in the JSON = then we would happily not duplicate them. It is mostly a case of trying to fit in to the existing OAuth work and = libraries. John B. On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: > why is it neccessary to duplicate the OAuth request parameters? >=20 > Am 27.10.2011 00:31, schrieb John Bradley: >>=20 >> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. >>=20 >> It is essentially a standardization of the method we are using in = openID Connect to make signed requests to the Authorization server. >>=20 >> We do have the issue that parameters in the signed/encrypted request = necessarily duplicate the query parameters to keep it a valid OAuth = request plus an extension. >>=20 >> Even if it doesn't wind up as a OAuth WG item it is probably worth = people looking at it before the final openID spec is voted on. >>=20 >> Regards >> John B. >>=20 >> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: >>=20 >>> Hi Nat, >>>=20 >>> I think your proposal would be a useful OAuth enhancement. A = JSON-based request format would allow for more complex requests (e.g. = carrying resource server URLs and corresponding scope values ;-)).=20 >>>=20 >>> Please note: I also think the way this mechanism is introduced and = used in the current OpenID connect spec requires OpenID connect clients = and servers to handle OAuth request parameters differently than for = standard OAuth requests. Introducing the JSON based claim request = capability to OAuth would be a way to cope with this. >>>=20 >>> regards, >>> Torsten. >>>=20 >>> Am 22.10.2011 16:00, schrieb Nat Sakimura: >>>>=20 >>>> Hi.=20 >>>>=20 >>>> Just a clarification:=20 >>>>=20 >>>> Although my expired draft is 'request by reference', what was = proposed through it at the iiw really is a generalized JSON based claim = request capability. It could be passed by value as JSON or could be = passed by reference. The later is an optimization for bandwidth = constrained network as well as strengthening security in some ways. This = capability already exists in OpenID Connect but it is actually an = underpinning transport, so it probably should belong to OAuth instead. = This was the primary reason for the proposal.=20 >>>>=20 >>>> Nat >>>>=20 >>>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt = wrote: >>>> Hi all, >>>>=20 >>>> my prioritization is driven by the goal to make OAuth the = authorization framework of choice for any internet standard protocol, = such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is = missing from my point of view and explain some thoughts how to fill the = gaps. >>>>=20 >>>> A standard protocol is defined in terms of resource types and = messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in = many places, and used by different but deployment-independent clients. = OAuth-based protocol specifications must also define scope values (e.g. = read, write, send) and their relation to the resource types and = messages. The different deployments expose the standard protocol on = different resource server endpoints. In my opinion, it is fundamental to = clearly distinguish scope values (standardized, static) and resource = server addresses (deployment specific) and to manage their = relationships. The current scope definition is much to weak and = insufficient. Probably, the UMA concepts of hosts, resources sets, and = corresponding scopes could be adopted for that purpose. >>>>=20 >>>> OAuth today requires clients to register with the service provider = before they are deployed. Would you really expect IMAP clients, e.g. = Thunderbird, to register with any a-Mail services upfront? So clients = should be given a way to register dynamically to the authorization = servers. This should also allow us to cover "client instance" aspects. = It is interesting to note, that such a mechanism would allow us to get = rid of secret-less clients and the one-time usage requirement for = authorization codes. >>>>=20 >>>> We also assume the client to know the URLs of the resource server = and the corresponding authorization server and to use HTTPS server = authentication to verify the resource server's authenticity. This is = impossible in the standard scenario. Clients must be able to discover = the authorization server a particular resource server relies on at = runtime. The discovery mechanism could be specified by the OAuth WG, but = could also be part of an application protocols specification. But we = MUST find another way to prevent token phishing by counterfeit resource = servers. >>>>=20 >>>> As one approach, the client could pass the (previously HTTPS = validated) resource server's URL with the authorization request. The = authorization server should then refuse such requests for any unknown = (counterfeit) resource servers. Such an additional parameter could also = serve as namespace for scope values and enable service providers to run = multiple instances of the same service within a single deployment. >>>>=20 >>>> If the additional data enlarges the request payload to much, we = could consider to adopt the "request by reference" proposal. >>>>=20 >>>> Let's now assume, OAuth is successful in the world of standard = protocols and we will see plenty of deployments with a bunch of = different OAuth protected resource servers. Shall this servers all be = accessible with a single token? In my opinion, this would cause = security, privacy and/or scalability/performance problems. To give just = the most obvious example, the target audience of such a token cannot be = restricted enough, which may allow a resource server (or an attacker in = control of it) to abuse the token on other servers. But the current = design of the code grant type forces deployments to use the same token = for all services. What is needed from my point of view is a way to = request and issue multiple server-specific access tokens with a single = authorization process. >>>>=20 >>>> I've been advocating this topic for a long time now and I'm still = convinced this is required to really complete the core design. We at = Deutsche Telekom needed and implemented this function on top of the = existing core. In my opinion, a core enhancement would be easier to = handle and more powerful. If others support this topic, I would be = willed to submit an I-D describing a possible solution. >>>>=20 >>>> If we take standards really seriously, then service providers = should be given the opportunity to implement their service by utilizing = standard server implementations. This creates the challenge to find a = standardized protocol between authorization server and resource server = to exchange authorization data. Depending on the token design = (self-contained vs. handle) this could be solved by either standardizing = a token format (JWT) or an authorization API. >>>>=20 >>>> Based on the rationale given above, my list is as follows (topics = w/o I-D are marked with *): >>>>=20 >>>> - Revocation (low hanging fruit since I-D is ready and implemented = in some places) >>>> - Resource server notion* >>>> - Multiple access tokens* >>>> - Dynamic client registration >>>>=20 >>>> 1) Dynamic Client Registration Protocol >>>> 4) Client Instance Extension >>>> - Discovery >>>> (10) Simple Web Discovery, probably other specs as well >>>> - (6) JSON Web Token >>>> - (7) JSON Web Token (JWT) Bearer Profile >>>> - 8) User Experience Extension >>>> - Device flow >>>> - 9) Request by Reference >>>> (depending resource server notion and multiple access tokens) >>>>=20 >>>> regards, >>>> Torsten. >>>> Zitat von Hannes Tschofenig : >>>>=20 >>>>=20 >>>> Hi all, >>>>=20 >>>> in preparation of the upcoming IETF meeting Barry and I would like = to start a re-chartering discussion. We both are currently attending = the Internet Identity Workshop and so we had the chance to solicit input = from the participants. This should serve as a discussion starter. >>>>=20 >>>> Potential future OAuth charter items (in random order): >>>>=20 >>>> ---------------- >>>>=20 >>>> 1) Dynamic Client Registration Protocol >>>>=20 >>>> Available document: >>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>>>=20 >>>> 2) Token Revocation >>>>=20 >>>> Available document: >>>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>>>=20 >>>> 3) UMA >>>>=20 >>>> Available document: >>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>>>=20 >>>> 4) Client Instance Extension >>>>=20 >>>> Available document: >>>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>>>=20 >>>> 5) XML Encoding >>>>=20 >>>> Available document: >>>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>>>=20 >>>> 6) JSON Web Token >>>>=20 >>>> Available document: >>>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>>>=20 >>>> 7) JSON Web Token (JWT) Bearer Profile >>>>=20 >>>> Available document: >>>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>>>=20 >>>> 8) User Experience Extension >>>>=20 >>>> Available document: >>>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>>>=20 >>>> 9) Request by Reference >>>>=20 >>>> Available document: >>>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>>>=20 >>>> 10) Simple Web Discovery >>>>=20 >>>> Available document: >>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>>>=20 >>>> ---------------- >>>>=20 >>>> We have the following questions: >>>>=20 >>>> a) Are you interested in any of the above-listed items? (as a = reviewer, co-author, implementer, or someone who would like to deploy). = It is also useful to know if you think that we shouldn't work on a = specific item. >>>>=20 >>>> b) Are there other items you would like to see the group working = on? >>>>=20 >>>> Note: In case your document is expired please re-submit it. >>>>=20 >>>> Ciao >>>> Hannes & Barry >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail=_A2F92E11-E86C-44C6-AD76-219ACEF254FD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hopefully to make it more compatible with existing OAuth 2 libraries.    At least leave open the possibility of dealing with it at a higher level.

The argument has been made that you probably need to modify the library anyway to check that the duplicate parameters are a match.

If there is consensus that the parameters should only be in the JSON then we would happily not duplicate them.

It is mostly a case of trying to fit in to the existing OAuth work and libraries.

John B.

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:

why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in openID Connect to make signed requests to the Authorization server.

We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension.

Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on.

Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:

Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 

Just a clarification: 

Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and  resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

 1) Dynamic Client Registration Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion.  We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

--Apple-Mail=_A2F92E11-E86C-44C6-AD76-219ACEF254FD-- --Apple-Mail=_000E5359-594D-4543-9030-C720CBE12A5A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEw MjcxNjUyMzJaMCMGCSqGSIb3DQEJBDEWBBTw7O8INSwWFSLudV6fOb23GXboIzCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQBOLyE/OL/4vciduTWo8+ODnj5AJCK+I5ZaxbKddIcVeHno+KPGWXj/rb59A4dy9Zi8I1tyZokN 4+tpT6711FJT4u8VUVizgPf27Z/EucKAZmSydWAt7lR7kBc2mDHCUgc0pZ6pvKI5VnVk2h4jxigg ZVKB1cT5SdJ1bamtBMuWrRPveGye3CybEF2vcHiNuxfrUEOWvHjaY7RNcl2fbZRYNqUiAstuP3hl vJg4L/pE3oLNF+mpiLMP9DDnq+J3B1zZDOvFHHbwJ+SySKoJAtgIQeEin/llevr/Aw9wVWbTsgXA 31W0pz0SNtaP+SYLH+24Qcv25iDQAsgiw33h3MiXAAAAAAAA --Apple-Mail=_000E5359-594D-4543-9030-C720CBE12A5A-- From SRS0=9NeDYN=5K=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Thu Oct 27 10:34:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E6021F8AFC for ; Thu, 27 Oct 2011 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF07PRwLUvxr for ; Thu, 27 Oct 2011 10:33:58 -0700 (PDT) Received: from smtp07.bis7.eu.blackberry.com (smtp07.bis7.eu.blackberry.com [178.239.85.12]) by ietfa.amsl.com (Postfix) with ESMTP id 650F021F8AF7 for ; Thu, 27 Oct 2011 10:33:55 -0700 (PDT) Received: from b16.c11.bise7.blackberry ([192.168.0.116]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p9RHXr9u004117; Thu, 27 Oct 2011 17:33:53 GMT Received: from 172.18.204.202 (cmp32.c11.bise7.blackberry [172.18.204.202]) by b16.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p9RHXmm3020301; Thu, 27 Oct 2011 17:33:48 GMT X-rim-org-msg-ref-id: 502551594 Message-ID: <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> X-Priority: Normal References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> <4EA8EA99.4010203@lodderstedt.net> In-Reply-To: Sensitivity: Normal Importance: Normal To: "John Bradley" From: torsten@lodderstedt.net Date: Thu, 27 Oct 2011 17:33:13 +0000 Content-Type: multipart/alternative; boundary="part4072-boundary-703840555-1169105555" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:38:42 -0000 --part4072-boundary-703840555-1169105555 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="Windows-1252" SGkgSm9obiwNCg0Kd2h5IGRvIHlvdSBuZWVkIHRvIGluY2x1ZGUgdGhlIE9BdXRoIHJlcXVlc3Qg cGFyYW1ldGVycyBpbnRvIHRoZSBKU09OIGRvY3VtZW50PyBJIHdvdWxkIGV4cGVjdCBPcGVuSWQg Q29ubmVjdCB0byBleHRlbmQgT0F1dGggbm9uZS1pbnRydXNpdmVseS4gVGhpcyB3b3VsZCBtZWFu IHRvIHVzZSB0aGUgSlNPTiBkb2N1bWVudCBmb3IgT3BlbklkIGNvbm5lY3Qgc3BlY2lmaWMgcGFy YW1ldGVycyBvbmx5LiBBbHRlcm5hdGl2ZWx5LCB0aGUgSlNPTiByZXF1ZXN0IHN0eWxlIGNvdWxk IGJlIGFkb3B0ZWQgYXMgcGFydCBvZiBPQXV0aC4gVGhlbiwgdGhlIFVSSSByZXF1ZXN0IHBhcmFt ZXRlcnMgY291bGQgYmUgb21pdHRlZC4NCg0KcmVnYXJkcywNClRvcnN0ZW4uDQpHZXNlbmRldCBt aXQgQmxhY2tCZXJyea4gV2VibWFpbCB2b24gVGVsZWtvbSBEZXV0c2NobGFuZCAgDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIu Y29tPg0KRGF0ZTogVGh1LCAyNyBPY3QgMjAxMSAxMzo1MjozMSANClRvOiBUb3JzdGVuIExvZGRl cnN0ZWR0PHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KQ2M6IE5hdCBTYWtpbXVyYTxzYWtpbXVy YUBnbWFpbC5jb20+OyBPQXV0aCBXRzxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIFJlY2hhcnRlcmluZyBKU09OIGJhc2VkIHJlcXVlc3QuDQoNCkhvcGVmdWxseSB0byBt YWtlIGl0IG1vcmUgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIE9BdXRoIDIgbGlicmFyaWVzLiAg ICBBdCBsZWFzdCBsZWF2ZSBvcGVuIHRoZSBwb3NzaWJpbGl0eSBvZiBkZWFsaW5nIHdpdGggaXQg YXQgYSBoaWdoZXIgbGV2ZWwuDQoNClRoZSBhcmd1bWVudCBoYXMgYmVlbiBtYWRlIHRoYXQgeW91 IHByb2JhYmx5IG5lZWQgdG8gbW9kaWZ5IHRoZSBsaWJyYXJ5IGFueXdheSB0byBjaGVjayB0aGF0 IHRoZSBkdXBsaWNhdGUgcGFyYW1ldGVycyBhcmUgYSBtYXRjaC4NCg0KSWYgdGhlcmUgaXMgY29u c2Vuc3VzIHRoYXQgdGhlIHBhcmFtZXRlcnMgc2hvdWxkIG9ubHkgYmUgaW4gdGhlIEpTT04gdGhl biB3ZSB3b3VsZCBoYXBwaWx5IG5vdCBkdXBsaWNhdGUgdGhlbS4NCg0KSXQgaXMgbW9zdGx5IGEg Y2FzZSBvZiB0cnlpbmcgdG8gZml0IGluIHRvIHRoZSBleGlzdGluZyBPQXV0aCB3b3JrIGFuZCBs aWJyYXJpZXMuDQoNCkpvaG4gQi4NCg0KT24gMjAxMS0xMC0yNywgYXQgMjoyMiBBTSwgVG9yc3Rl biBMb2RkZXJzdGVkdCB3cm90ZToNCg0KPiB3aHkgaXMgaXQgbmVjY2Vzc2FyeSB0byBkdXBsaWNh dGUgdGhlIE9BdXRoIHJlcXVlc3QgcGFyYW1ldGVycz8NCj4gDQo+IEFtIDI3LjEwLjIwMTEgMDA6 MzEsIHNjaHJpZWIgSm9obiBCcmFkbGV5Og0KPj4gDQo+PiBOYXQgYW5kIEkganVzdCByZWZyZXNo ZWQgdGhlIEktRCBmb3IgZHJhZnQtc2FraW11cmEtb2F1dGgtcmVxdXJsLg0KPj4gDQo+PiBJdCBp cyBlc3NlbnRpYWxseSAgYSBzdGFuZGFyZGl6YXRpb24gb2YgdGhlIG1ldGhvZCB3ZSBhcmUgdXNp bmcgaW4gb3BlbklEIENvbm5lY3QgdG8gbWFrZSBzaWduZWQgcmVxdWVzdHMgdG8gdGhlIEF1dGhv cml6YXRpb24gc2VydmVyLg0KPj4gDQo+PiBXZSBkbyBoYXZlIHRoZSBpc3N1ZSB0aGF0IHBhcmFt ZXRlcnMgaW4gdGhlIHNpZ25lZC9lbmNyeXB0ZWQgcmVxdWVzdCBuZWNlc3NhcmlseSBkdXBsaWNh dGUgdGhlIHF1ZXJ5IHBhcmFtZXRlcnMgdG8ga2VlcCBpdCBhIHZhbGlkIE9BdXRoIHJlcXVlc3Qg cGx1cyBhbiBleHRlbnNpb24uDQo+PiANCj4+IEV2ZW4gaWYgaXQgZG9lc24ndCB3aW5kIHVwIGFz IGEgT0F1dGggV0cgaXRlbSBpdCBpcyBwcm9iYWJseSB3b3J0aCBwZW9wbGUgbG9va2luZyBhdCBp dCBiZWZvcmUgdGhlIGZpbmFsIG9wZW5JRCBzcGVjIGlzIHZvdGVkIG9uLg0KPj4gDQo+PiBSZWdh cmRzDQo+PiBKb2huIEIuDQo+PiANCj4+IE9uIDIwMTEtMTAtMjYsIGF0IDM6MTYgUE0sIFRvcnN0 ZW4gTG9kZGVyc3RlZHQgd3JvdGU6DQo+PiANCj4+PiBIaSBOYXQsDQo+Pj4gDQo+Pj4gSSB0aGlu ayB5b3VyIHByb3Bvc2FsIHdvdWxkIGJlIGEgdXNlZnVsIE9BdXRoIGVuaGFuY2VtZW50LiBBIEpT T04tYmFzZWQgcmVxdWVzdCBmb3JtYXQgd291bGQgYWxsb3cgZm9yIG1vcmUgY29tcGxleCByZXF1 ZXN0cyAoZS5nLiBjYXJyeWluZyByZXNvdXJjZSBzZXJ2ZXIgVVJMcyBhbmQgY29ycmVzcG9uZGlu ZyBzY29wZSB2YWx1ZXMgOy0pKS4gDQo+Pj4gDQo+Pj4gUGxlYXNlIG5vdGU6IEkgYWxzbyB0aGlu ayB0aGUgd2F5IHRoaXMgbWVjaGFuaXNtIGlzIGludHJvZHVjZWQgYW5kIHVzZWQgaW4gdGhlIGN1 cnJlbnQgT3BlbklEIGNvbm5lY3Qgc3BlYyByZXF1aXJlcyBPcGVuSUQgY29ubmVjdCBjbGllbnRz IGFuZCBzZXJ2ZXJzIHRvIGhhbmRsZSBPQXV0aCByZXF1ZXN0IHBhcmFtZXRlcnMgZGlmZmVyZW50 bHkgdGhhbiBmb3Igc3RhbmRhcmQgT0F1dGggcmVxdWVzdHMuIEludHJvZHVjaW5nIHRoZSBKU09O IGJhc2VkIGNsYWltIHJlcXVlc3QgY2FwYWJpbGl0eSB0byBPQXV0aCB3b3VsZCBiZSBhIHdheSB0 byBjb3BlIHdpdGggdGhpcy4NCj4+PiANCj4+PiByZWdhcmRzLA0KPj4+IFRvcnN0ZW4uDQo+Pj4g DQo+Pj4gQW0gMjIuMTAuMjAxMSAxNjowMCwgc2NocmllYiBOYXQgU2FraW11cmE6DQo+Pj4+IA0K Pj4+PiBIaS4gDQo+Pj4+IA0KPj4+PiBKdXN0IGEgY2xhcmlmaWNhdGlvbjogDQo+Pj4+IA0KPj4+ PiBBbHRob3VnaCBteSBleHBpcmVkIGRyYWZ0IGlzICdyZXF1ZXN0IGJ5IHJlZmVyZW5jZScsIHdo YXQgd2FzIHByb3Bvc2VkIHRocm91Z2ggaXQgYXQgdGhlIGlpdyByZWFsbHkgaXMgYSBnZW5lcmFs aXplZCBKU09OIGJhc2VkIGNsYWltIHJlcXVlc3QgY2FwYWJpbGl0eS4gSXQgY291bGQgYmUgcGFz c2VkIGJ5IHZhbHVlIGFzIEpTT04gb3IgY291bGQgYmUgcGFzc2VkIGJ5IHJlZmVyZW5jZS4gVGhl IGxhdGVyIGlzIGFuIG9wdGltaXphdGlvbiBmb3IgYmFuZHdpZHRoIGNvbnN0cmFpbmVkIG5ldHdv cmsgYXMgd2VsbCBhcyBzdHJlbmd0aGVuaW5nIHNlY3VyaXR5IGluIHNvbWUgd2F5cy4gVGhpcyBj YXBhYmlsaXR5IGFscmVhZHkgZXhpc3RzIGluIE9wZW5JRCBDb25uZWN0IGJ1dCBpdCBpcyBhY3R1 YWxseSBhbiB1bmRlcnBpbm5pbmcgdHJhbnNwb3J0LCBzbyBpdCBwcm9iYWJseSBzaG91bGQgYmVs b25nIHRvIE9BdXRoIGluc3RlYWQuIFRoaXMgd2FzIHRoZSBwcmltYXJ5IHJlYXNvbiBmb3IgdGhl IHByb3Bvc2FsLiANCj4+Pj4gDQo+Pj4+IE5hdA0KPj4+PiANCj4+Pj4gT24gVGh1LCBPY3QgMjAs IDIwMTEgYXQgMzo1NiBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ+IHdyb3RlOg0KPj4+PiBIaSBhbGwsDQo+Pj4+IA0KPj4+PiBteSBwcmlvcml0aXphdGlv biBpcyBkcml2ZW4gYnkgdGhlIGdvYWwgdG8gbWFrZSBPQXV0aCB0aGUgYXV0aG9yaXphdGlvbiBm cmFtZXdvcmsgb2YgY2hvaWNlIGZvciBhbnkgaW50ZXJuZXQgc3RhbmRhcmQgcHJvdG9jb2wsIHN1 Y2ggYXMgV2ViREFWLCBJTUFQLCBTTVRQIG9yIFNJUC4gU28gbGV0IG1lIGZpcnN0IGV4cGxhaW4g d2hhdCBpcyBtaXNzaW5nIGZyb20gbXkgcG9pbnQgb2YgdmlldyBhbmQgZXhwbGFpbiBzb21lIHRo b3VnaHRzIGhvdyB0byBmaWxsIHRoZSBnYXBzLg0KPj4+PiANCj4+Pj4gQSBzdGFuZGFyZCBwcm90 b2NvbCBpcyBkZWZpbmVkIGluIHRlcm1zIG9mIHJlc291cmNlIHR5cGVzIGFuZCBtZXNzYWdlcyBi eSBhIGJvZHkgKGUuZy4gSUVURiwgT0lERiwgT01BKSwgKGhvcGVmdWxseSkgaW1wbGVtZW50ZWQg aW4gbWFueSBwbGFjZXMsIGFuZCB1c2VkIGJ5IGRpZmZlcmVudCBidXQgZGVwbG95bWVudC1pbmRl cGVuZGVudCBjbGllbnRzLiBPQXV0aC1iYXNlZCBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyBtdXN0 IGFsc28gZGVmaW5lIHNjb3BlIHZhbHVlcyAoZS5nLiByZWFkLCB3cml0ZSwgc2VuZCkgYW5kIHRo ZWlyIHJlbGF0aW9uIHRvIHRoZSByZXNvdXJjZSB0eXBlcyBhbmQgbWVzc2FnZXMuIFRoZSBkaWZm ZXJlbnQgZGVwbG95bWVudHMgZXhwb3NlIHRoZSBzdGFuZGFyZCBwcm90b2NvbCBvbiBkaWZmZXJl bnQgcmVzb3VyY2Ugc2VydmVyIGVuZHBvaW50cy4gSW4gbXkgb3BpbmlvbiwgaXQgaXMgZnVuZGFt ZW50YWwgdG8gY2xlYXJseSBkaXN0aW5ndWlzaCBzY29wZSB2YWx1ZXMgKHN0YW5kYXJkaXplZCwg c3RhdGljKSBhbmQgIHJlc291cmNlIHNlcnZlciBhZGRyZXNzZXMgKGRlcGxveW1lbnQgc3BlY2lm aWMpIGFuZCB0byBtYW5hZ2UgdGhlaXIgcmVsYXRpb25zaGlwcy4gVGhlIGN1cnJlbnQgc2NvcGUg ZGVmaW5pdGlvbiBpcyBtdWNoIHRvIHdlYWsgYW5kIGluc3VmZmljaWVudC4gUHJvYmFibHksIHRo ZSBVTUEgY29uY2VwdHMgb2YgaG9zdHMsIHJlc291cmNlcyBzZXRzLCBhbmQgY29ycmVzcG9uZGlu ZyBzY29wZXMgY291bGQgYmUgYWRvcHRlZCBmb3IgdGhhdCBwdXJwb3NlLg0KPj4+PiANCj4+Pj4g T0F1dGggdG9kYXkgcmVxdWlyZXMgY2xpZW50cyB0byByZWdpc3RlciB3aXRoIHRoZSBzZXJ2aWNl IHByb3ZpZGVyIGJlZm9yZSB0aGV5IGFyZSBkZXBsb3llZC4gV291bGQgeW91IHJlYWxseSBleHBl Y3QgSU1BUCBjbGllbnRzLCBlLmcuIFRodW5kZXJiaXJkLCB0byByZWdpc3RlciB3aXRoIGFueSBh LU1haWwgc2VydmljZXMgdXBmcm9udD8gU28gY2xpZW50cyBzaG91bGQgYmUgZ2l2ZW4gYSB3YXkg dG8gcmVnaXN0ZXIgZHluYW1pY2FsbHkgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVycy4gVGhp cyBzaG91bGQgYWxzbyBhbGxvdyB1cyB0byBjb3ZlciAiY2xpZW50IGluc3RhbmNlIiBhc3BlY3Rz LiBJdCBpcyBpbnRlcmVzdGluZyB0byBub3RlLCB0aGF0IHN1Y2ggYSBtZWNoYW5pc20gd291bGQg YWxsb3cgdXMgdG8gZ2V0IHJpZCBvZiBzZWNyZXQtbGVzcyBjbGllbnRzIGFuZCB0aGUgb25lLXRp bWUgdXNhZ2UgcmVxdWlyZW1lbnQgZm9yIGF1dGhvcml6YXRpb24gY29kZXMuDQo+Pj4+IA0KPj4+ PiBXZSBhbHNvIGFzc3VtZSB0aGUgY2xpZW50IHRvIGtub3cgdGhlIFVSTHMgb2YgdGhlIHJlc291 cmNlIHNlcnZlciBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5k IHRvIHVzZSBIVFRQUyBzZXJ2ZXIgYXV0aGVudGljYXRpb24gdG8gdmVyaWZ5IHRoZSByZXNvdXJj ZSBzZXJ2ZXIncyBhdXRoZW50aWNpdHkuIFRoaXMgaXMgaW1wb3NzaWJsZSBpbiB0aGUgc3RhbmRh cmQgc2NlbmFyaW8uIENsaWVudHMgbXVzdCBiZSBhYmxlIHRvIGRpc2NvdmVyIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBhIHBhcnRpY3VsYXIgcmVzb3VyY2Ugc2VydmVyIHJlbGllcyBvbiBhdCBy dW50aW1lLiBUaGUgZGlzY292ZXJ5IG1lY2hhbmlzbSBjb3VsZCBiZSBzcGVjaWZpZWQgYnkgdGhl IE9BdXRoIFdHLCBidXQgY291bGQgYWxzbyBiZSBwYXJ0IG9mIGFuIGFwcGxpY2F0aW9uIHByb3Rv Y29scyBzcGVjaWZpY2F0aW9uLiBCdXQgd2UgTVVTVCBmaW5kIGFub3RoZXIgd2F5IHRvIHByZXZl bnQgdG9rZW4gcGhpc2hpbmcgYnkgY291bnRlcmZlaXQgcmVzb3VyY2Ugc2VydmVycy4NCj4+Pj4g DQo+Pj4+IEFzIG9uZSBhcHByb2FjaCwgdGhlIGNsaWVudCBjb3VsZCBwYXNzIHRoZSAocHJldmlv dXNseSBIVFRQUyB2YWxpZGF0ZWQpIHJlc291cmNlIHNlcnZlcidzIFVSTCB3aXRoIHRoZSBhdXRo b3JpemF0aW9uIHJlcXVlc3QuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgdGhlbiBy ZWZ1c2Ugc3VjaCByZXF1ZXN0cyBmb3IgYW55IHVua25vd24gKGNvdW50ZXJmZWl0KSByZXNvdXJj ZSBzZXJ2ZXJzLiBTdWNoIGFuIGFkZGl0aW9uYWwgcGFyYW1ldGVyIGNvdWxkIGFsc28gc2VydmUg YXMgbmFtZXNwYWNlIGZvciBzY29wZSB2YWx1ZXMgYW5kIGVuYWJsZSBzZXJ2aWNlIHByb3ZpZGVy cyB0byBydW4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIHNlcnZpY2Ugd2l0aGluIGEg c2luZ2xlIGRlcGxveW1lbnQuDQo+Pj4+IA0KPj4+PiBJZiB0aGUgYWRkaXRpb25hbCBkYXRhIGVu bGFyZ2VzIHRoZSByZXF1ZXN0IHBheWxvYWQgdG8gbXVjaCwgd2UgY291bGQgY29uc2lkZXIgdG8g YWRvcHQgdGhlICJyZXF1ZXN0IGJ5IHJlZmVyZW5jZSIgcHJvcG9zYWwuDQo+Pj4+IA0KPj4+PiBM ZXQncyBub3cgYXNzdW1lLCBPQXV0aCBpcyBzdWNjZXNzZnVsIGluIHRoZSB3b3JsZCBvZiBzdGFu ZGFyZCBwcm90b2NvbHMgYW5kIHdlIHdpbGwgc2VlIHBsZW50eSBvZiBkZXBsb3ltZW50cyB3aXRo IGEgYnVuY2ggb2YgZGlmZmVyZW50IE9BdXRoIHByb3RlY3RlZCByZXNvdXJjZSBzZXJ2ZXJzLiBT aGFsbCB0aGlzIHNlcnZlcnMgYWxsIGJlIGFjY2Vzc2libGUgd2l0aCBhIHNpbmdsZSB0b2tlbj8g SW4gbXkgb3BpbmlvbiwgdGhpcyB3b3VsZCBjYXVzZSBzZWN1cml0eSwgcHJpdmFjeSBhbmQvb3Ig c2NhbGFiaWxpdHkvcGVyZm9ybWFuY2UgcHJvYmxlbXMuIFRvIGdpdmUganVzdCB0aGUgbW9zdCBv YnZpb3VzIGV4YW1wbGUsIHRoZSB0YXJnZXQgYXVkaWVuY2Ugb2Ygc3VjaCBhIHRva2VuIGNhbm5v dCBiZSByZXN0cmljdGVkIGVub3VnaCwgd2hpY2ggbWF5IGFsbG93IGEgcmVzb3VyY2Ugc2VydmVy IChvciBhbiBhdHRhY2tlciBpbiBjb250cm9sIG9mIGl0KSB0byBhYnVzZSB0aGUgdG9rZW4gb24g b3RoZXIgc2VydmVycy4gQnV0IHRoZSBjdXJyZW50IGRlc2lnbiBvZiB0aGUgY29kZSBncmFudCB0 eXBlIGZvcmNlcyBkZXBsb3ltZW50cyB0byB1c2UgdGhlIHNhbWUgdG9rZW4gZm9yIGFsbCBzZXJ2 aWNlcy4gV2hhdCBpcyBuZWVkZWQgZnJvbSBteSBwb2ludCBvZiB2aWV3IGlzIGEgd2F5IHRvIHJl cXVlc3QgYW5kIGlzc3VlIG11bHRpcGxlIHNlcnZlci1zcGVjaWZpYyBhY2Nlc3MgdG9rZW5zIHdp dGggYSBzaW5nbGUgYXV0aG9yaXphdGlvbiBwcm9jZXNzLg0KPj4+PiANCj4+Pj4gSSd2ZSBiZWVu IGFkdm9jYXRpbmcgdGhpcyB0b3BpYyBmb3IgYSBsb25nIHRpbWUgbm93IGFuZCBJJ20gc3RpbGwg Y29udmluY2VkIHRoaXMgaXMgcmVxdWlyZWQgdG8gcmVhbGx5IGNvbXBsZXRlIHRoZSBjb3JlIGRl c2lnbi4gV2UgYXQgRGV1dHNjaGUgVGVsZWtvbSBuZWVkZWQgYW5kIGltcGxlbWVudGVkIHRoaXMg ZnVuY3Rpb24gb24gdG9wIG9mIHRoZSBleGlzdGluZyBjb3JlLiBJbiBteSBvcGluaW9uLCBhIGNv cmUgZW5oYW5jZW1lbnQgd291bGQgYmUgZWFzaWVyIHRvIGhhbmRsZSBhbmQgbW9yZSBwb3dlcmZ1 bC4gSWYgb3RoZXJzIHN1cHBvcnQgdGhpcyB0b3BpYywgSSB3b3VsZCBiZSB3aWxsZWQgdG8gc3Vi bWl0IGFuIEktRCBkZXNjcmliaW5nIGEgcG9zc2libGUgc29sdXRpb24uDQo+Pj4+IA0KPj4+PiBJ ZiB3ZSB0YWtlIHN0YW5kYXJkcyByZWFsbHkgc2VyaW91c2x5LCB0aGVuIHNlcnZpY2UgcHJvdmlk ZXJzIHNob3VsZCBiZSBnaXZlbiB0aGUgb3Bwb3J0dW5pdHkgdG8gaW1wbGVtZW50IHRoZWlyIHNl cnZpY2UgYnkgdXRpbGl6aW5nIHN0YW5kYXJkIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMuIFRoaXMg Y3JlYXRlcyB0aGUgY2hhbGxlbmdlIHRvIGZpbmQgYSBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wgYmV0 d2VlbiBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIHRvIGV4Y2hhbmdl IGF1dGhvcml6YXRpb24gZGF0YS4gRGVwZW5kaW5nIG9uIHRoZSB0b2tlbiBkZXNpZ24gKHNlbGYt Y29udGFpbmVkIHZzLiBoYW5kbGUpIHRoaXMgY291bGQgYmUgc29sdmVkIGJ5IGVpdGhlciBzdGFu ZGFyZGl6aW5nIGEgdG9rZW4gZm9ybWF0IChKV1QpIG9yIGFuIGF1dGhvcml6YXRpb24gQVBJLg0K Pj4+PiANCj4+Pj4gQmFzZWQgb24gdGhlIHJhdGlvbmFsZSBnaXZlbiBhYm92ZSwgbXkgbGlzdCBp cyBhcyBmb2xsb3dzICh0b3BpY3Mgdy9vIEktRCBhcmUgbWFya2VkIHdpdGggKik6DQo+Pj4+IA0K Pj4+PiAtIFJldm9jYXRpb24gKGxvdyBoYW5naW5nIGZydWl0IHNpbmNlIEktRCBpcyByZWFkeSBh bmQgaW1wbGVtZW50ZWQgaW4gc29tZSBwbGFjZXMpDQo+Pj4+IC0gUmVzb3VyY2Ugc2VydmVyIG5v dGlvbioNCj4+Pj4gLSBNdWx0aXBsZSBhY2Nlc3MgdG9rZW5zKg0KPj4+PiAtIER5bmFtaWMgY2xp ZW50IHJlZ2lzdHJhdGlvbg0KPj4+PiANCj4+Pj4gIDEpIER5bmFtaWMgQ2xpZW50IFJlZ2lzdHJh dGlvbiBQcm90b2NvbA0KPj4+PiAgNCkgQ2xpZW50IEluc3RhbmNlIEV4dGVuc2lvbg0KPj4+PiAt IERpc2NvdmVyeQ0KPj4+PiAgKDEwKSBTaW1wbGUgV2ViIERpc2NvdmVyeSwgcHJvYmFibHkgb3Ro ZXIgc3BlY3MgYXMgd2VsbA0KPj4+PiAtICg2KSBKU09OIFdlYiBUb2tlbg0KPj4+PiAtICg3KSBK U09OIFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgUHJvZmlsZQ0KPj4+PiAtIDgpIFVzZXIgRXhwZXJp ZW5jZSBFeHRlbnNpb24NCj4+Pj4gLSBEZXZpY2UgZmxvdw0KPj4+PiAtIDkpIFJlcXVlc3QgYnkg UmVmZXJlbmNlDQo+Pj4+ICAoZGVwZW5kaW5nIHJlc291cmNlIHNlcnZlciBub3Rpb24gYW5kIG11 bHRpcGxlIGFjY2VzcyB0b2tlbnMpDQo+Pj4+IA0KPj4+PiByZWdhcmRzLA0KPj4+PiBUb3JzdGVu Lg0KPj4+PiBaaXRhdCB2b24gSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdt eC5uZXQ+Og0KPj4+PiANCj4+Pj4gDQo+Pj4+IEhpIGFsbCwNCj4+Pj4gDQo+Pj4+IGluIHByZXBh cmF0aW9uIG9mIHRoZSB1cGNvbWluZyBJRVRGIG1lZXRpbmcgQmFycnkgYW5kIEkgd291bGQgbGlr ZSB0byBzdGFydCBhIHJlLWNoYXJ0ZXJpbmcgZGlzY3Vzc2lvbi4gIFdlIGJvdGggYXJlIGN1cnJl bnRseSBhdHRlbmRpbmcgdGhlIEludGVybmV0IElkZW50aXR5IFdvcmtzaG9wIGFuZCBzbyB3ZSBo YWQgdGhlIGNoYW5jZSB0byBzb2xpY2l0IGlucHV0IGZyb20gdGhlIHBhcnRpY2lwYW50cy4gVGhp cyBzaG91bGQgc2VydmUgYXMgYSBkaXNjdXNzaW9uIHN0YXJ0ZXIuDQo+Pj4+IA0KPj4+PiBQb3Rl bnRpYWwgZnV0dXJlIE9BdXRoIGNoYXJ0ZXIgaXRlbXMgKGluIHJhbmRvbSBvcmRlcik6DQo+Pj4+ IA0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IA0KPj4+PiAxKSBEeW5hbWljIENsaWVudCBS ZWdpc3RyYXRpb24gUHJvdG9jb2wNCj4+Pj4gDQo+Pj4+IEF2YWlsYWJsZSBkb2N1bWVudDoNCj4+ Pj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJkam9uby1vYXV0aC1k eW5yZWcvDQo+Pj4+IA0KPj4+PiAyKSBUb2tlbiBSZXZvY2F0aW9uDQo+Pj4+IA0KPj4+PiBBdmFp bGFibGUgZG9jdW1lbnQ6DQo+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmV2b2NhdGlvbi8NCj4+Pj4gDQo+Pj4+IDMpIFVNQQ0KPj4+ PiANCj4+Pj4gQXZhaWxhYmxlIGRvY3VtZW50Og0KPj4+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWhhcmRqb25vLW9hdXRoLXVtYWNvcmUvDQo+Pj4+IA0KPj4+PiA0KSBD bGllbnQgSW5zdGFuY2UgRXh0ZW5zaW9uDQo+Pj4+IA0KPj4+PiBBdmFpbGFibGUgZG9jdW1lbnQ6 DQo+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1yaWNoZXItb2F1dGgtaW5zdGFu Y2UtMDAudHh0DQo+Pj4+IA0KPj4+PiA1KSBYTUwgRW5jb2RpbmcNCj4+Pj4gDQo+Pj4+IEF2YWls YWJsZSBkb2N1bWVudDoNCj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXJpY2hl ci1vYXV0aC14bWwtMDAudHh0DQo+Pj4+IA0KPj4+PiA2KSBKU09OIFdlYiBUb2tlbg0KPj4+PiAN Cj4+Pj4gQXZhaWxhYmxlIGRvY3VtZW50Og0KPj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1qb25lcy1qc29uLXdlYi10b2tlbi0wNQ0KPj4+PiANCj4+Pj4gNykgSlNPTiBXZWIg VG9rZW4gKEpXVCkgQmVhcmVyIFByb2ZpbGUNCj4+Pj4gDQo+Pj4+IEF2YWlsYWJsZSBkb2N1bWVu dDoNCj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtand0 LWJlYXJlci0wMA0KPj4+PiANCj4+Pj4gOCkgVXNlciBFeHBlcmllbmNlIEV4dGVuc2lvbg0KPj4+ PiANCj4+Pj4gQXZhaWxhYmxlIGRvY3VtZW50Og0KPj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1yZWNvcmRvbi1vYXV0aC12Mi11eC0wMA0KPj4+PiANCj4+Pj4gOSkgUmVxdWVz dCBieSBSZWZlcmVuY2UNCj4+Pj4gDQo+Pj4+IEF2YWlsYWJsZSBkb2N1bWVudDoNCj4+Pj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtcmVxdXJsLTAwDQo+ Pj4+IA0KPj4+PiAxMCkgU2ltcGxlIFdlYiBEaXNjb3ZlcnkNCj4+Pj4gDQo+Pj4+IEF2YWlsYWJs ZSBkb2N1bWVudDoNCj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMt c2ltcGxlLXdlYi1kaXNjb3ZlcnktMDANCj4+Pj4gDQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0NCj4+ Pj4gDQo+Pj4+IFdlIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQo+Pj4+IA0KPj4+PiBh KSBBcmUgeW91IGludGVyZXN0ZWQgaW4gYW55IG9mIHRoZSBhYm92ZS1saXN0ZWQgaXRlbXM/IChh cyBhIHJldmlld2VyLCBjby1hdXRob3IsIGltcGxlbWVudGVyLCBvciBzb21lb25lIHdobyB3b3Vs ZCBsaWtlIHRvIGRlcGxveSkuIEl0IGlzIGFsc28gdXNlZnVsIHRvIGtub3cgaWYgeW91IHRoaW5r IHRoYXQgd2Ugc2hvdWxkbid0IHdvcmsgb24gYSBzcGVjaWZpYyBpdGVtLg0KPj4+PiANCj4+Pj4g YikgQXJlIHRoZXJlIG90aGVyIGl0ZW1zIHlvdSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgZ3JvdXAg d29ya2luZyBvbj8NCj4+Pj4gDQo+Pj4+IE5vdGU6IEluIGNhc2UgeW91ciBkb2N1bWVudCBpcyBl eHBpcmVkIHBsZWFzZSByZS1zdWJtaXQgaXQuDQo+Pj4+IA0KPj4+PiBDaWFvDQo+Pj4+IEhhbm5l cyAmIEJhcnJ5DQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhAaWV0Zi5v cmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+ PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+Pj4gT0F1dGhAaWV0Zi5v cmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+ PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiAtLSANCj4+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPj4+ PiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4+Pj4gaHR0cDovL25hdC5zYWtpbXVyYS5v cmcvDQo+Pj4+IEBfbmF0X2VuDQo+Pj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+Pj4gT0F1dGhA aWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQo+PiANCg0KDQo= --part4072-boundary-703840555-1169105555 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="Windows-1252" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj5IaSBKb2huLDxici8+PGJyLz53aHkgZG8geW91IG5lZWQgdG8gaW5jbHVkZSB0aGUg T0F1dGggcmVxdWVzdCBwYXJhbWV0ZXJzIGludG8gdGhlIEpTT04gZG9jdW1lbnQ/IEkgd291bGQg ZXhwZWN0IE9wZW5JZCBDb25uZWN0IHRvIGV4dGVuZCBPQXV0aCBub25lLWludHJ1c2l2ZWx5LiBU aGlzIHdvdWxkIG1lYW4gdG8gdXNlIHRoZSBKU09OIGRvY3VtZW50IGZvciBPcGVuSWQgY29ubmVj dCBzcGVjaWZpYyBwYXJhbWV0ZXJzIG9ubHkuIEFsdGVybmF0aXZlbHksIHRoZSBKU09OIHJlcXVl c3Qgc3R5bGUgY291bGQgYmUgYWRvcHRlZCBhcyBwYXJ0IG9mIE9BdXRoLiBUaGVuLCB0aGUgVVJJ IHJlcXVlc3QgcGFyYW1ldGVycyBjb3VsZCBiZSBvbWl0dGVkLjxici8+PGJyLz5yZWdhcmRzLDxi ci8+VG9yc3Rlbi48cD5HZXNlbmRldCBtaXQgQmxhY2tCZXJyea4gV2VibWFpbCB2b24gVGVsZWtv bSBEZXV0c2NobGFuZCAgPC9wPjxoci8+PGRpdj48Yj5Gcm9tOiA8L2I+IEpvaG4gQnJhZGxleSAm bHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7DQo8L2Rpdj48ZGl2PjxiPkRhdGU6IDwvYj5UaHUsIDI3 IE9jdCAyMDExIDEzOjUyOjMxIC0wMzAwPC9kaXY+PGRpdj48Yj5UbzogPC9iPlRvcnN0ZW4gTG9k ZGVyc3RlZHQmbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7PC9kaXY+PGRpdj48Yj5DYzog PC9iPk5hdCBTYWtpbXVyYSZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7OyBPQXV0aCBXRyZsdDtv YXV0aEBpZXRmLm9yZyZndDs8L2Rpdj48ZGl2PjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdH XSBSZWNoYXJ0ZXJpbmcgSlNPTiBiYXNlZCByZXF1ZXN0LjwvZGl2PjxkaXY+PGJyLz48L2Rpdj5I b3BlZnVsbHkgdG8gbWFrZSBpdCBtb3JlIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBPQXV0aCAy IGxpYnJhcmllcy4gJm5ic3A7ICZuYnNwO0F0IGxlYXN0IGxlYXZlIG9wZW4gdGhlIHBvc3NpYmls aXR5IG9mIGRlYWxpbmcgd2l0aCBpdCBhdCBhIGhpZ2hlciBsZXZlbC48ZGl2Pjxicj48L2Rpdj48 ZGl2PlRoZSBhcmd1bWVudCBoYXMgYmVlbiBtYWRlIHRoYXQgeW91IHByb2JhYmx5IG5lZWQgdG8g bW9kaWZ5IHRoZSBsaWJyYXJ5IGFueXdheSB0byBjaGVjayB0aGF0IHRoZSBkdXBsaWNhdGUgcGFy YW1ldGVycyBhcmUgYSBtYXRjaC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PklmIHRoZXJlIGlz IGNvbnNlbnN1cyB0aGF0IHRoZSBwYXJhbWV0ZXJzIHNob3VsZCBvbmx5IGJlIGluIHRoZSBKU09O IHRoZW4gd2Ugd291bGQgaGFwcGlseSBub3QgZHVwbGljYXRlIHRoZW0uPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5JdCBpcyBtb3N0bHkgYSBjYXNlIG9mIHRyeWluZyB0byBmaXQgaW4gdG8gdGhl IGV4aXN0aW5nIE9BdXRoIHdvcmsgYW5kIGxpYnJhcmllcy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PkpvaG4gQi48L2Rpdj48ZGl2Pjxicj48ZGl2PjxkaXY+T24gMjAxMS0xMC0yNywgYXQgMjoy MiBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICANCiAgICA8bWV0 YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSIgaHR0cC1lcXVpdj0iQ29u dGVudC1UeXBlIj4NCiAgDQogIDxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCI+ DQogICAgd2h5IGlzIGl0IG5lY2Nlc3NhcnkgdG8gZHVwbGljYXRlIHRoZSBPQXV0aCByZXF1ZXN0 IHBhcmFtZXRlcnM/PGJyPg0KICAgIDxicj4NCiAgICBBbSAyNy4xMC4yMDExIDAwOjMxLCBzY2hy aWViIEpvaG4gQnJhZGxleToNCiAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6RDNGQjUzNTktRERE RS00RUY3LUJENjktMDUzRjU2NDdGRTRFQHZlN2p0Yi5jb20iIHR5cGU9ImNpdGUiPjxzcGFuIGNs YXNzPSJBcHBsZS1zdHlsZS1zcGFuIj5OYXQgYW5kIEkganVzdA0KICAgICAgICByZWZyZXNoZWQg dGhlIEktRCBmb3ImbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0 eWxlPSJmb250LWZhbWlseTogbW9ub3NwYWNlOyAiPmRyYWZ0LXNha2ltdXJhLW9hdXRoLXJlcXVy bDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiI+Lg0KICAgICAgICA8ZGl2Pjxi cj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+SXQgaXMgZXNzZW50aWFsbHkgJm5ic3A7 YSBzdGFuZGFyZGl6YXRpb24gb2YgdGhlIG1ldGhvZCB3ZSBhcmUNCiAgICAgICAgICB1c2luZyBp biBvcGVuSUQgQ29ubmVjdCB0byBtYWtlIHNpZ25lZCByZXF1ZXN0cyB0byB0aGUNCiAgICAgICAg ICBBdXRob3JpemF0aW9uIHNlcnZlci48L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAg IDwvZGl2Pg0KICAgICAgICA8ZGl2PldlIGRvIGhhdmUgdGhlIGlzc3VlIHRoYXQgcGFyYW1ldGVy cyBpbiB0aGUNCiAgICAgICAgICBzaWduZWQvZW5jcnlwdGVkIHJlcXVlc3QgbmVjZXNzYXJpbHkg ZHVwbGljYXRlIHRoZSBxdWVyeQ0KICAgICAgICAgIHBhcmFtZXRlcnMgdG8ga2VlcCBpdCBhIHZh bGlkIE9BdXRoIHJlcXVlc3QgcGx1cyBhbiBleHRlbnNpb24uPC9kaXY+DQogICAgICAgIDxkaXY+ PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj5FdmVuIGlmIGl0IGRvZXNuJ3Qgd2lu ZCB1cCBhcyBhIE9BdXRoIFdHIGl0ZW0gaXQgaXMNCiAgICAgICAgICBwcm9iYWJseSB3b3J0aCBw ZW9wbGUgbG9va2luZyBhdCBpdCBiZWZvcmUgdGhlIGZpbmFsIG9wZW5JRA0KICAgICAgICAgIHNw ZWMgaXMgdm90ZWQgb24uPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4N CiAgICAgICAgPGRpdj5SZWdhcmRzPC9kaXY+DQogICAgICAgIDxkaXY+Sm9obiBCLjwvZGl2Pg0K ICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgPGRpdj5PbiAy MDExLTEwLTI2LCBhdCAzOjE2IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IHdyb3RlOjwvZGl2Pg0K ICAgICAgICAgICAgPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCiAgICAg ICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICA8bWV0YSBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSIgaHR0cC1lcXVpdj0iQ29udGVudC1U eXBlIj4NCiAgICAgICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAw Ij4gSGkgTmF0LDxicj4NCiAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgSSB0 aGluayB5b3VyIHByb3Bvc2FsIHdvdWxkIGJlIGEgdXNlZnVsIE9BdXRoDQogICAgICAgICAgICAg ICAgZW5oYW5jZW1lbnQuIEEgSlNPTi1iYXNlZCByZXF1ZXN0IGZvcm1hdCB3b3VsZCBhbGxvdyBm b3INCiAgICAgICAgICAgICAgICBtb3JlIGNvbXBsZXggcmVxdWVzdHMgKGUuZy4gY2Fycnlpbmcg cmVzb3VyY2Ugc2VydmVyDQogICAgICAgICAgICAgICAgVVJMcyBhbmQgY29ycmVzcG9uZGluZyBz Y29wZSB2YWx1ZXMgOy0pKS4gPGJyPg0KICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg ICAgICBQbGVhc2Ugbm90ZTogSSBhbHNvIHRoaW5rIHRoZSB3YXkgdGhpcyBtZWNoYW5pc20gaXMN CiAgICAgICAgICAgICAgICBpbnRyb2R1Y2VkIGFuZCB1c2VkIGluIHRoZSBjdXJyZW50IE9wZW5J RCBjb25uZWN0IHNwZWMNCiAgICAgICAgICAgICAgICByZXF1aXJlcyBPcGVuSUQgY29ubmVjdCBj bGllbnRzIGFuZCBzZXJ2ZXJzIHRvIGhhbmRsZQ0KICAgICAgICAgICAgICAgIE9BdXRoIHJlcXVl c3QgcGFyYW1ldGVycyBkaWZmZXJlbnRseSB0aGFuIGZvciBzdGFuZGFyZA0KICAgICAgICAgICAg ICAgIE9BdXRoIHJlcXVlc3RzLiBJbnRyb2R1Y2luZyB0aGUgSlNPTiBiYXNlZCBjbGFpbSByZXF1 ZXN0DQogICAgICAgICAgICAgICAgY2FwYWJpbGl0eSB0byBPQXV0aCB3b3VsZCBiZSBhIHdheSB0 byBjb3BlIHdpdGggdGhpcy48YnI+DQogICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg ICAgIHJlZ2FyZHMsPGJyPg0KICAgICAgICAgICAgICAgIFRvcnN0ZW4uPGJyPg0KICAgICAgICAg ICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICBBbSAyMi4xMC4yMDExIDE2OjAwLCBzY2hyaWVi IE5hdCBTYWtpbXVyYToNCiAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6Q0FC ekN5MkJMcD1IaDNIZHlEZE9HRjRuWjZUTUxSZGl1Uk16V0RQdkIzVDJZX2ZjZk5BQG1haWwuZ21h aWwuY29tIiB0eXBlPSJjaXRlIj5IaS4mbmJzcDsNCiAgICAgICAgICAgICAgICAgIDxkaXY+PGJy Pg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8ZGl2Pkp1c3Qg YSBjbGFyaWZpY2F0aW9uOiZuYnNwOzwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDxkaXY+QWx0aG91 Z2ggbXkgZXhwaXJlZCBkcmFmdCBpcyAncmVxdWVzdCBieQ0KICAgICAgICAgICAgICAgICAgICBy ZWZlcmVuY2UnLCB3aGF0IHdhcyBwcm9wb3NlZCB0aHJvdWdoIGl0IGF0IHRoZSBpaXcNCiAgICAg ICAgICAgICAgICAgICAgcmVhbGx5IGlzIGEgZ2VuZXJhbGl6ZWQgSlNPTiBiYXNlZCBjbGFpbSBy ZXF1ZXN0DQogICAgICAgICAgICAgICAgICAgIGNhcGFiaWxpdHkuIEl0IGNvdWxkIGJlIHBhc3Nl ZCBieSB2YWx1ZSBhcyBKU09OIG9yDQogICAgICAgICAgICAgICAgICAgIGNvdWxkIGJlIHBhc3Nl ZCBieSByZWZlcmVuY2UuIFRoZSBsYXRlciBpcyBhbg0KICAgICAgICAgICAgICAgICAgICBvcHRp bWl6YXRpb24gZm9yIGJhbmR3aWR0aCBjb25zdHJhaW5lZCBuZXR3b3JrIGFzDQogICAgICAgICAg ICAgICAgICAgIHdlbGwgYXMgc3RyZW5ndGhlbmluZyBzZWN1cml0eSBpbiBzb21lIHdheXMuIFRo aXMNCiAgICAgICAgICAgICAgICAgICAgY2FwYWJpbGl0eSBhbHJlYWR5IGV4aXN0cyBpbiBPcGVu SUQgQ29ubmVjdCBidXQgaXQNCiAgICAgICAgICAgICAgICAgICAgaXMgYWN0dWFsbHkgYW4gdW5k ZXJwaW5uaW5nIHRyYW5zcG9ydCwgc28gaXQNCiAgICAgICAgICAgICAgICAgICAgcHJvYmFibHkg c2hvdWxkIGJlbG9uZyB0byBPQXV0aCBpbnN0ZWFkLiBUaGlzIHdhcw0KICAgICAgICAgICAgICAg ICAgICB0aGUgcHJpbWFyeSByZWFzb24gZm9yIHRoZSBwcm9wb3NhbC4mbmJzcDs8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg ICAgICAgICAgICAgICA8ZGl2Pk5hdDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIE9j dCAyMCwgMjAxMSBhdA0KICAgICAgICAgICAgICAgICAgICAgIDM6NTYgUE0sIFRvcnN0ZW4gTG9k ZGVyc3RlZHQgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhy ZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ8L2E+Jmd0Ozwvc3Bhbj4NCiAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjDQogICAgICAgICAgICAgICAgICAgICAgICBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+ SGkgYWxsLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgIG15IHByaW9yaXRpemF0aW9uIGlzIGRyaXZlbiBieSB0aGUgZ29hbCB0byBtYWtl DQogICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCB0aGUgYXV0aG9yaXphdGlvbiBmcmFtZXdv cmsgb2YgY2hvaWNlIGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgYW55IGludGVybmV0IHN0 YW5kYXJkIHByb3RvY29sLCBzdWNoIGFzIFdlYkRBViwNCiAgICAgICAgICAgICAgICAgICAgICAg IElNQVAsIFNNVFAgb3IgU0lQLiBTbyBsZXQgbWUgZmlyc3QgZXhwbGFpbiB3aGF0DQogICAgICAg ICAgICAgICAgICAgICAgICBpcyBtaXNzaW5nIGZyb20gbXkgcG9pbnQgb2YgdmlldyBhbmQgZXhw bGFpbg0KICAgICAgICAgICAgICAgICAgICAgICAgc29tZSB0aG91Z2h0cyBob3cgdG8gZmlsbCB0 aGUgZ2Fwcy48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICBBIHN0YW5kYXJkIHByb3RvY29sIGlzIGRlZmluZWQgaW4gdGVybXMgb2YNCiAg ICAgICAgICAgICAgICAgICAgICAgIHJlc291cmNlIHR5cGVzIGFuZCBtZXNzYWdlcyBieSBhIGJv ZHkgKGUuZy4NCiAgICAgICAgICAgICAgICAgICAgICAgIElFVEYsIE9JREYsIE9NQSksIChob3Bl ZnVsbHkpIGltcGxlbWVudGVkIGluDQogICAgICAgICAgICAgICAgICAgICAgICBtYW55IHBsYWNl cywgYW5kIHVzZWQgYnkgZGlmZmVyZW50IGJ1dA0KICAgICAgICAgICAgICAgICAgICAgICAgZGVw bG95bWVudC1pbmRlcGVuZGVudCBjbGllbnRzLiBPQXV0aC1iYXNlZA0KICAgICAgICAgICAgICAg ICAgICAgICAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMgbXVzdCBhbHNvIGRlZmluZSBzY29wZQ0K ICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWVzIChlLmcuIHJlYWQsIHdyaXRlLCBzZW5kKSBh bmQgdGhlaXINCiAgICAgICAgICAgICAgICAgICAgICAgIHJlbGF0aW9uIHRvIHRoZSByZXNvdXJj ZSB0eXBlcyBhbmQgbWVzc2FnZXMuIFRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgZGlmZmVy ZW50IGRlcGxveW1lbnRzIGV4cG9zZSB0aGUgc3RhbmRhcmQNCiAgICAgICAgICAgICAgICAgICAg ICAgIHByb3RvY29sIG9uIGRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXIgZW5kcG9pbnRzLg0KICAg ICAgICAgICAgICAgICAgICAgICAgSW4gbXkgb3BpbmlvbiwgaXQgaXMgZnVuZGFtZW50YWwgdG8g Y2xlYXJseQ0KICAgICAgICAgICAgICAgICAgICAgICAgZGlzdGluZ3Vpc2ggc2NvcGUgdmFsdWVz IChzdGFuZGFyZGl6ZWQsIHN0YXRpYykNCiAgICAgICAgICAgICAgICAgICAgICAgIGFuZCAmbmJz cDtyZXNvdXJjZSBzZXJ2ZXIgYWRkcmVzc2VzIChkZXBsb3ltZW50DQogICAgICAgICAgICAgICAg ICAgICAgICBzcGVjaWZpYykgYW5kIHRvIG1hbmFnZSB0aGVpciByZWxhdGlvbnNoaXBzLiBUaGUN CiAgICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnQgc2NvcGUgZGVmaW5pdGlvbiBpcyBtdWNo IHRvIHdlYWsgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICBpbnN1ZmZpY2llbnQuIFByb2Jh Ymx5LCB0aGUgVU1BIGNvbmNlcHRzIG9mDQogICAgICAgICAgICAgICAgICAgICAgICBob3N0cywg cmVzb3VyY2VzIHNldHMsIGFuZCBjb3JyZXNwb25kaW5nIHNjb3Blcw0KICAgICAgICAgICAgICAg ICAgICAgICAgY291bGQgYmUgYWRvcHRlZCBmb3IgdGhhdCBwdXJwb3NlLjxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIE9BdXRoIHRvZGF5 IHJlcXVpcmVzIGNsaWVudHMgdG8gcmVnaXN0ZXIgd2l0aA0KICAgICAgICAgICAgICAgICAgICAg ICAgdGhlIHNlcnZpY2UgcHJvdmlkZXIgYmVmb3JlIHRoZXkgYXJlIGRlcGxveWVkLg0KICAgICAg ICAgICAgICAgICAgICAgICAgV291bGQgeW91IHJlYWxseSBleHBlY3QgSU1BUCBjbGllbnRzLCBl LmcuDQogICAgICAgICAgICAgICAgICAgICAgICBUaHVuZGVyYmlyZCwgdG8gcmVnaXN0ZXIgd2l0 aCBhbnkgYS1NYWlsDQogICAgICAgICAgICAgICAgICAgICAgICBzZXJ2aWNlcyB1cGZyb250PyBT byBjbGllbnRzIHNob3VsZCBiZSBnaXZlbiBhDQogICAgICAgICAgICAgICAgICAgICAgICB3YXkg dG8gcmVnaXN0ZXIgZHluYW1pY2FsbHkgdG8gdGhlIGF1dGhvcml6YXRpb24NCiAgICAgICAgICAg ICAgICAgICAgICAgIHNlcnZlcnMuIFRoaXMgc2hvdWxkIGFsc28gYWxsb3cgdXMgdG8gY292ZXIN CiAgICAgICAgICAgICAgICAgICAgICAgICJjbGllbnQgaW5zdGFuY2UiIGFzcGVjdHMuIEl0IGlz IGludGVyZXN0aW5nIHRvDQogICAgICAgICAgICAgICAgICAgICAgICBub3RlLCB0aGF0IHN1Y2gg YSBtZWNoYW5pc20gd291bGQgYWxsb3cgdXMgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgIGdl dCByaWQgb2Ygc2VjcmV0LWxlc3MgY2xpZW50cyBhbmQgdGhlIG9uZS10aW1lDQogICAgICAgICAg ICAgICAgICAgICAgICB1c2FnZSByZXF1aXJlbWVudCBmb3IgYXV0aG9yaXphdGlvbiBjb2Rlcy48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAg ICBXZSBhbHNvIGFzc3VtZSB0aGUgY2xpZW50IHRvIGtub3cgdGhlIFVSTHMgb2YNCiAgICAgICAg ICAgICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIHRoZSBjb3JyZXNwb25kaW5n DQogICAgICAgICAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgdG8gdXNl IEhUVFBTIHNlcnZlcg0KICAgICAgICAgICAgICAgICAgICAgICAgYXV0aGVudGljYXRpb24gdG8g dmVyaWZ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIncw0KICAgICAgICAgICAgICAgICAgICAgICAgYXV0 aGVudGljaXR5LiBUaGlzIGlzIGltcG9zc2libGUgaW4gdGhlIHN0YW5kYXJkDQogICAgICAgICAg ICAgICAgICAgICAgICBzY2VuYXJpby4gQ2xpZW50cyBtdXN0IGJlIGFibGUgdG8gZGlzY292ZXIg dGhlDQogICAgICAgICAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBhIHBhcnRp Y3VsYXIgcmVzb3VyY2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlciByZWxpZXMgb24g YXQgcnVudGltZS4gVGhlIGRpc2NvdmVyeQ0KICAgICAgICAgICAgICAgICAgICAgICAgbWVjaGFu aXNtIGNvdWxkIGJlIHNwZWNpZmllZCBieSB0aGUgT0F1dGggV0csDQogICAgICAgICAgICAgICAg ICAgICAgICBidXQgY291bGQgYWxzbyBiZSBwYXJ0IG9mIGFuIGFwcGxpY2F0aW9uDQogICAgICAg ICAgICAgICAgICAgICAgICBwcm90b2NvbHMgc3BlY2lmaWNhdGlvbi4gQnV0IHdlIE1VU1QgZmlu ZA0KICAgICAgICAgICAgICAgICAgICAgICAgYW5vdGhlciB3YXkgdG8gcHJldmVudCB0b2tlbiBw aGlzaGluZyBieQ0KICAgICAgICAgICAgICAgICAgICAgICAgY291bnRlcmZlaXQgcmVzb3VyY2Ug c2VydmVycy48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICBBcyBvbmUgYXBwcm9hY2gsIHRoZSBjbGllbnQgY291bGQgcGFzcyB0aGUNCiAg ICAgICAgICAgICAgICAgICAgICAgIChwcmV2aW91c2x5IEhUVFBTIHZhbGlkYXRlZCkgcmVzb3Vy Y2Ugc2VydmVyJ3MNCiAgICAgICAgICAgICAgICAgICAgICAgIFVSTCB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIHJlcXVlc3QuIFRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgYXV0aG9yaXphdGlv biBzZXJ2ZXIgc2hvdWxkIHRoZW4gcmVmdXNlIHN1Y2gNCiAgICAgICAgICAgICAgICAgICAgICAg IHJlcXVlc3RzIGZvciBhbnkgdW5rbm93biAoY291bnRlcmZlaXQpIHJlc291cmNlDQogICAgICAg ICAgICAgICAgICAgICAgICBzZXJ2ZXJzLiBTdWNoIGFuIGFkZGl0aW9uYWwgcGFyYW1ldGVyIGNv dWxkIGFsc28NCiAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlIGFzIG5hbWVzcGFjZSBmb3Ig c2NvcGUgdmFsdWVzIGFuZCBlbmFibGUNCiAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZpY2Ug cHJvdmlkZXJzIHRvIHJ1biBtdWx0aXBsZSBpbnN0YW5jZXMgb2YNCiAgICAgICAgICAgICAgICAg ICAgICAgIHRoZSBzYW1lIHNlcnZpY2Ugd2l0aGluIGEgc2luZ2xlIGRlcGxveW1lbnQuPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgSWYg dGhlIGFkZGl0aW9uYWwgZGF0YSBlbmxhcmdlcyB0aGUgcmVxdWVzdA0KICAgICAgICAgICAgICAg ICAgICAgICAgcGF5bG9hZCB0byBtdWNoLCB3ZSBjb3VsZCBjb25zaWRlciB0byBhZG9wdCB0aGUN CiAgICAgICAgICAgICAgICAgICAgICAgICJyZXF1ZXN0IGJ5IHJlZmVyZW5jZSIgcHJvcG9zYWwu PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgTGV0J3Mgbm93IGFzc3VtZSwgT0F1dGggaXMgc3VjY2Vzc2Z1bCBpbiB0aGUNCiAgICAgICAg ICAgICAgICAgICAgICAgIHdvcmxkIG9mIHN0YW5kYXJkIHByb3RvY29scyBhbmQgd2Ugd2lsbCBz ZWUNCiAgICAgICAgICAgICAgICAgICAgICAgIHBsZW50eSBvZiBkZXBsb3ltZW50cyB3aXRoIGEg YnVuY2ggb2YgZGlmZmVyZW50DQogICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCBwcm90ZWN0 ZWQgcmVzb3VyY2Ugc2VydmVycy4gU2hhbGwgdGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAg c2VydmVycyBhbGwgYmUgYWNjZXNzaWJsZSB3aXRoIGEgc2luZ2xlIHRva2VuPw0KICAgICAgICAg ICAgICAgICAgICAgICAgSW4gbXkgb3BpbmlvbiwgdGhpcyB3b3VsZCBjYXVzZSBzZWN1cml0eSwN CiAgICAgICAgICAgICAgICAgICAgICAgIHByaXZhY3kgYW5kL29yIHNjYWxhYmlsaXR5L3BlcmZv cm1hbmNlIHByb2JsZW1zLg0KICAgICAgICAgICAgICAgICAgICAgICAgVG8gZ2l2ZSBqdXN0IHRo ZSBtb3N0IG9idmlvdXMgZXhhbXBsZSwgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICB0YXJn ZXQgYXVkaWVuY2Ugb2Ygc3VjaCBhIHRva2VuIGNhbm5vdCBiZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgcmVzdHJpY3RlZCBlbm91Z2gsIHdoaWNoIG1heSBhbGxvdyBhIHJlc291cmNlDQogICAg ICAgICAgICAgICAgICAgICAgICBzZXJ2ZXIgKG9yIGFuIGF0dGFja2VyIGluIGNvbnRyb2wgb2Yg aXQpIHRvDQogICAgICAgICAgICAgICAgICAgICAgICBhYnVzZSB0aGUgdG9rZW4gb24gb3RoZXIg c2VydmVycy4gQnV0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudCBkZXNpZ24g b2YgdGhlIGNvZGUgZ3JhbnQgdHlwZSBmb3JjZXMNCiAgICAgICAgICAgICAgICAgICAgICAgIGRl cGxveW1lbnRzIHRvIHVzZSB0aGUgc2FtZSB0b2tlbiBmb3IgYWxsDQogICAgICAgICAgICAgICAg ICAgICAgICBzZXJ2aWNlcy4gV2hhdCBpcyBuZWVkZWQgZnJvbSBteSBwb2ludCBvZiB2aWV3DQog ICAgICAgICAgICAgICAgICAgICAgICBpcyBhIHdheSB0byByZXF1ZXN0IGFuZCBpc3N1ZSBtdWx0 aXBsZQ0KICAgICAgICAgICAgICAgICAgICAgICAgc2VydmVyLXNwZWNpZmljIGFjY2VzcyB0b2tl bnMgd2l0aCBhIHNpbmdsZQ0KICAgICAgICAgICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBw cm9jZXNzLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgIEkndmUgYmVlbiBhZHZvY2F0aW5nIHRoaXMgdG9waWMgZm9yIGEgbG9uZyB0aW1l DQogICAgICAgICAgICAgICAgICAgICAgICBub3cgYW5kIEknbSBzdGlsbCBjb252aW5jZWQgdGhp cyBpcyByZXF1aXJlZCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgcmVhbGx5IGNvbXBsZXRl IHRoZSBjb3JlIGRlc2lnbi4gV2UgYXQgRGV1dHNjaGUNCiAgICAgICAgICAgICAgICAgICAgICAg IFRlbGVrb20gbmVlZGVkIGFuZCBpbXBsZW1lbnRlZCB0aGlzIGZ1bmN0aW9uIG9uDQogICAgICAg ICAgICAgICAgICAgICAgICB0b3Agb2YgdGhlIGV4aXN0aW5nIGNvcmUuIEluIG15IG9waW5pb24s IGEgY29yZQ0KICAgICAgICAgICAgICAgICAgICAgICAgZW5oYW5jZW1lbnQgd291bGQgYmUgZWFz aWVyIHRvIGhhbmRsZSBhbmQgbW9yZQ0KICAgICAgICAgICAgICAgICAgICAgICAgcG93ZXJmdWwu IElmIG90aGVycyBzdXBwb3J0IHRoaXMgdG9waWMsIEkgd291bGQNCiAgICAgICAgICAgICAgICAg ICAgICAgIGJlIHdpbGxlZCB0byBzdWJtaXQgYW4gSS1EIGRlc2NyaWJpbmcgYSBwb3NzaWJsZQ0K ICAgICAgICAgICAgICAgICAgICAgICAgc29sdXRpb24uPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgd2UgdGFrZSBzdGFuZGFyZHMg cmVhbGx5IHNlcmlvdXNseSwgdGhlbg0KICAgICAgICAgICAgICAgICAgICAgICAgc2VydmljZSBw cm92aWRlcnMgc2hvdWxkIGJlIGdpdmVuIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgb3Bw b3J0dW5pdHkgdG8gaW1wbGVtZW50IHRoZWlyIHNlcnZpY2UgYnkNCiAgICAgICAgICAgICAgICAg ICAgICAgIHV0aWxpemluZyBzdGFuZGFyZCBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zLiBUaGlzDQog ICAgICAgICAgICAgICAgICAgICAgICBjcmVhdGVzIHRoZSBjaGFsbGVuZ2UgdG8gZmluZCBhIHN0 YW5kYXJkaXplZA0KICAgICAgICAgICAgICAgICAgICAgICAgcHJvdG9jb2wgYmV0d2VlbiBhdXRo b3JpemF0aW9uIHNlcnZlciBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgIHJlc291cmNlIHNl cnZlciB0byBleGNoYW5nZSBhdXRob3JpemF0aW9uIGRhdGEuDQogICAgICAgICAgICAgICAgICAg ICAgICBEZXBlbmRpbmcgb24gdGhlIHRva2VuIGRlc2lnbiAoc2VsZi1jb250YWluZWQNCiAgICAg ICAgICAgICAgICAgICAgICAgIHZzLiBoYW5kbGUpIHRoaXMgY291bGQgYmUgc29sdmVkIGJ5IGVp dGhlcg0KICAgICAgICAgICAgICAgICAgICAgICAgc3RhbmRhcmRpemluZyBhIHRva2VuIGZvcm1h dCAoSldUKSBvciBhbg0KICAgICAgICAgICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBBUEku PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgQmFzZWQgb24gdGhlIHJhdGlvbmFsZSBnaXZlbiBhYm92ZSwgbXkgbGlzdCBpcw0KICAgICAg ICAgICAgICAgICAgICAgICAgYXMgZm9sbG93cyAodG9waWNzIHcvbyBJLUQgYXJlIG1hcmtlZCB3 aXRoICopOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgIC0gUmV2b2NhdGlvbiAobG93IGhhbmdpbmcgZnJ1aXQgc2luY2UgSS1EIGlzDQog ICAgICAgICAgICAgICAgICAgICAgICByZWFkeSBhbmQgaW1wbGVtZW50ZWQgaW4gc29tZSBwbGFj ZXMpPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgLSBSZXNvdXJjZSBzZXJ2ZXIgbm90aW9u Kjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIC0gTXVsdGlwbGUgYWNjZXNzIHRva2Vucyo8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAtIER5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlv bg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iaW0iPjxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgJm5ic3A7MSkgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9uIFBy b3RvY29sPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg ICAgICAgICAgICAmbmJzcDs0KSBDbGllbnQgSW5zdGFuY2UgRXh0ZW5zaW9uPGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgLSBEaXNjb3Zlcnk8YnI+DQogICAgICAgICAgICAgICAgICAgICAg ICAmbmJzcDsoMTApIFNpbXBsZSBXZWIgRGlzY292ZXJ5LCBwcm9iYWJseSBvdGhlciBzcGVjcw0K ICAgICAgICAgICAgICAgICAgICAgICAgYXMgd2VsbDxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgIC0gKDYpIEpTT04gV2ViIFRva2VuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgLSAo NykgSlNPTiBXZWIgVG9rZW4gKEpXVCkgQmVhcmVyIFByb2ZpbGU8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAtIDgpIFVzZXIgRXhwZXJpZW5jZSBFeHRlbnNpb248YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAtIERldmljZSBmbG93PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg LSA5KSBSZXF1ZXN0IGJ5IFJlZmVyZW5jZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICZu YnNwOyhkZXBlbmRpbmcgcmVzb3VyY2Ugc2VydmVyIG5vdGlvbiBhbmQgbXVsdGlwbGUNCiAgICAg ICAgICAgICAgICAgICAgICAgIGFjY2VzcyB0b2tlbnMpPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgcmVnYXJkcyw8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICBUb3JzdGVuLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIFpp dGF0IHZvbiBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBo cmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhh bm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OzoNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iaDUiPjxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPiBIaSBhbGwsPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gcHJlcGFy YXRpb24gb2YgdGhlIHVwY29taW5nIElFVEYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IG1lZXRpbmcgQmFycnkgYW5kIEkgd291bGQgbGlrZSB0byBzdGFydCBhDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICByZS1jaGFydGVyaW5nIGRpc2N1c3Npb24uICZuYnNwO1dlIGJvdGgg YXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50bHkgYXR0ZW5kaW5nIHRo ZSBJbnRlcm5ldCBJZGVudGl0eQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV29ya3No b3AgYW5kIHNvIHdlIGhhZCB0aGUgY2hhbmNlIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzb2xpY2l0IGlucHV0IGZyb20gdGhlIHBhcnRpY2lwYW50cy4gVGhpcw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc2hvdWxkIHNlcnZlIGFzIGEgZGlzY3Vzc2lvbiBzdGFydGVy Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFBvdGVudGlhbCBmdXR1cmUgT0F1dGggY2hhcnRlciBpdGVtcyAoaW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJhbmRvbSBvcmRlcik6PGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0tLS0tLS0tLS0tLS0tLTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEpIER5bmFtaWMgQ2xpZW50IFJlZ2lz dHJhdGlvbiBQcm90b2NvbDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF2YWlsYWJsZSBkb2N1bWVudDo8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhy ZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZGpvbm8tb2F1dGgt ZHlucmVnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaGFyZGpvbm8tb2F1dGgtZHlucmVnLzwvYT48YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyKSBUb2tlbiBS ZXZvY2F0aW9uPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQXZhaWxhYmxlIGRvY3VtZW50Ojxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yZXZv Y2F0aW9uLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmV2b2NhdGlvbi88L2E+PGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMykg VU1BPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQXZhaWxhYmxlIGRvY3VtZW50Ojxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJkam9uby1vYXV0aC11bWFjb3JlLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZGpv bm8tb2F1dGgtdW1hY29yZS88L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNCkgQ2xpZW50IEluc3RhbmNlIEV4 dGVuc2lvbjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEF2YWlsYWJsZSBkb2N1bWVudDo8YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1yaWNoZXItb2F1dGgtaW5zdGFuY2UtMDAudHh0IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXJpY2hlci1vYXV0 aC1pbnN0YW5jZS0wMC50eHQ8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNSkgWE1MIEVuY29kaW5nPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQXZhaWxhYmxlIGRvY3VtZW50Ojxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LXJpY2hlci1vYXV0aC14bWwtMDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXJpY2hlci1vYXV0aC14bWwtMDAudHh0PC9hPjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDYpIEpTT04gV2ViIFRva2VuPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXZhaWxhYmxlIGRv Y3VtZW50Ojxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qt c2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMt anNvbi13ZWItdG9rZW4tMDUiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1qb25lcy1qc29uLXdlYi10b2tlbi0wNTwvYT48YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3KSBK U09OIFdlYiBUb2tlbiAoSldUKSBCZWFyZXIgUHJvZmlsZTxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF2YWlsYWJs ZSBkb2N1bWVudDo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBtb3otZG8t bm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpv bmVzLW9hdXRoLWp3dC1iZWFyZXItMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1qd3QtYmVhcmVyLTAwPC9hPjxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDgpIFVzZXIgRXhwZXJpZW5jZSBFeHRlbnNpb248YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdmFpbGFibGUg ZG9jdW1lbnQ6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGEgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWNv cmRvbi1vYXV0aC12Mi11eC0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXJlY29yZG9uLW9hdXRoLXYyLXV4LTAwPC9hPjxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkp IFJlcXVlc3QgYnkgUmVmZXJlbmNlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXZhaWxhYmxlIGRvY3VtZW50Ojxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgt cmVxdXJsLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc2FraW11cmEtb2F1dGgtcmVxdXJsLTAwPC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEwKSBTaW1wbGUg V2ViIERpc2NvdmVyeTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF2YWlsYWJsZSBkb2N1bWVudDo8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLXNpbXBsZS13ZWItZGlzY292 ZXJ5LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt am9uZXMtc2ltcGxlLXdlYi1kaXNjb3ZlcnktMDA8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0t LS0tLS0tLTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFdlIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6PGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgYSkgQXJlIHlvdSBpbnRlcmVzdGVkIGluIGFueSBvZiB0aGUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGFib3ZlLWxpc3RlZCBpdGVtcz8gKGFzIGEgcmV2aWV3ZXIs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjby1hdXRob3IsIGltcGxlbWVudGVyLCBv ciBzb21lb25lIHdobw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd291bGQgbGlrZSB0 byBkZXBsb3kpLiBJdCBpcyBhbHNvIHVzZWZ1bA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdG8ga25vdyBpZiB5b3UgdGhpbmsgdGhhdCB3ZSBzaG91bGRuJ3QNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHdvcmsgb24gYSBzcGVjaWZpYyBpdGVtLjxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGIp IEFyZSB0aGVyZSBvdGhlciBpdGVtcyB5b3Ugd291bGQgbGlrZSB0bw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc2VlIHRoZSBncm91cCB3b3JraW5nIG9uPzxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5v dGU6IEluIGNhc2UgeW91ciBkb2N1bWVudCBpcyBleHBpcmVkDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBwbGVhc2UgcmUtc3VibWl0IGl0Ljxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpYW88YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIYW5uZXMgJmFtcDsgQmFycnk8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0 PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qt c2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2tx dW90ZT4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxi cj4NCiAgICAgICAgICAgICAgICAgICAgPGJyIGNsZWFyPSJhbGwiPg0KICAgICAgICAgICAgICAg ICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg ICAgICAgIC0tIDxicj4NCiAgICAgICAgICAgICAgICAgICAgTmF0IFNha2ltdXJhICg9bmF0KQ0K ICAgICAgICAgICAgICAgICAgICA8ZGl2PkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4N CiAgICAgICAgICAgICAgICAgICAgICA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLzwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgQF9uYXRfZW48L2Rpdj4NCiAg ICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg ICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQog ICAgICAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgPGEgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQogICAg ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGJyPg0K ICAgICAgICA8L2Rpdj4NCiAgICAgIDwvc3Bhbj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogIDwvZGl2 Pg0KDQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvYm9keT48L2h0bWw+DQo= --part4072-boundary-703840555-1169105555-- From phil.hunt@oracle.com Thu Oct 27 10:50:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F6A21F8888 for ; Thu, 27 Oct 2011 10:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcttrBfdBhsi for ; Thu, 27 Oct 2011 10:50:06 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1335D21F8772 for ; Thu, 27 Oct 2011 10:50:06 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9RHo35Y014628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Oct 2011 17:50:04 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9RHo26u023010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2011 17:50:03 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9RHnuAH015687; Thu, 27 Oct 2011 12:49:57 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Oct 2011 10:49:56 -0700 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_A656AB51-1664-4DAD-AB10-D40074138584" From: Phil Hunt X-Priority: Normal In-Reply-To: <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> Date: Thu, 27 Oct 2011 10:49:23 -0700 Message-Id: <486BD16C-070D-48CF-A82E-3382E67439AA@oracle.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> <4EA8EA99.4010203@lodderstedt.net> <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> To: torsten@lodderstedt.net X-Mailer: Apple Mail (2.1251.1) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4EA999CC.00D0:SCFMA922111,ss=1,re=-10.500,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:50:08 -0000 --Apple-Mail=_A656AB51-1664-4DAD-AB10-D40074138584 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 John, What is the reason behind having a separate ID_Token from the access = Token? I understand the tokens are used to retrieve different = information, but not sure I fully understand why separate tokens are = needed. I ask because I recall others have asked for multi-token = response=85.trying to understand if there is a general use case behind = this requirement. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-10-27, at 10:33 AM, torsten@lodderstedt.net wrote: > Hi John, >=20 > why do you need to include the OAuth request parameters into the JSON = document? I would expect OpenId Connect to extend OAuth = none-intrusively. This would mean to use the JSON document for OpenId = connect specific parameters only. Alternatively, the JSON request style = could be adopted as part of OAuth. Then, the URI request parameters = could be omitted. >=20 > regards, > Torsten. > Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland >=20 > From: John Bradley > Date: Thu, 27 Oct 2011 13:52:31 -0300 > To: Torsten Lodderstedt > Cc: Nat Sakimura; OAuth WG > Subject: Re: [OAUTH-WG] Rechartering JSON based request. >=20 > Hopefully to make it more compatible with existing OAuth 2 libraries. = At least leave open the possibility of dealing with it at a higher = level. >=20 > The argument has been made that you probably need to modify the = library anyway to check that the duplicate parameters are a match. >=20 > If there is consensus that the parameters should only be in the JSON = then we would happily not duplicate them. >=20 > It is mostly a case of trying to fit in to the existing OAuth work and = libraries. >=20 > John B. >=20 > On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: >=20 >> why is it neccessary to duplicate the OAuth request parameters? >>=20 >> Am 27.10.2011 00:31, schrieb John Bradley: >>>=20 >>> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. >>>=20 >>> It is essentially a standardization of the method we are using in = openID Connect to make signed requests to the Authorization server. >>>=20 >>> We do have the issue that parameters in the signed/encrypted request = necessarily duplicate the query parameters to keep it a valid OAuth = request plus an extension. >>>=20 >>> Even if it doesn't wind up as a OAuth WG item it is probably worth = people looking at it before the final openID spec is voted on. >>>=20 >>> Regards >>> John B. >>>=20 >>> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: >>>=20 >>>> Hi Nat, >>>>=20 >>>> I think your proposal would be a useful OAuth enhancement. A = JSON-based request format would allow for more complex requests (e.g. = carrying resource server URLs and corresponding scope values ;-)).=20 >>>>=20 >>>> Please note: I also think the way this mechanism is introduced and = used in the current OpenID connect spec requires OpenID connect clients = and servers to handle OAuth request parameters differently than for = standard OAuth requests. Introducing the JSON based claim request = capability to OAuth would be a way to cope with this. >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>> Am 22.10.2011 16:00, schrieb Nat Sakimura: >>>>>=20 >>>>> Hi.=20 >>>>>=20 >>>>> Just a clarification:=20 >>>>>=20 >>>>> Although my expired draft is 'request by reference', what was = proposed through it at the iiw really is a generalized JSON based claim = request capability. It could be passed by value as JSON or could be = passed by reference. The later is an optimization for bandwidth = constrained network as well as strengthening security in some ways. This = capability already exists in OpenID Connect but it is actually an = underpinning transport, so it probably should belong to OAuth instead. = This was the primary reason for the proposal.=20 >>>>>=20 >>>>> Nat >>>>>=20 >>>>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt = wrote: >>>>> Hi all, >>>>>=20 >>>>> my prioritization is driven by the goal to make OAuth the = authorization framework of choice for any internet standard protocol, = such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is = missing from my point of view and explain some thoughts how to fill the = gaps. >>>>>=20 >>>>> A standard protocol is defined in terms of resource types and = messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in = many places, and used by different but deployment-independent clients. = OAuth-based protocol specifications must also define scope values (e.g. = read, write, send) and their relation to the resource types and = messages. The different deployments expose the standard protocol on = different resource server endpoints. In my opinion, it is fundamental to = clearly distinguish scope values (standardized, static) and resource = server addresses (deployment specific) and to manage their = relationships. The current scope definition is much to weak and = insufficient. Probably, the UMA concepts of hosts, resources sets, and = corresponding scopes could be adopted for that purpose. >>>>>=20 >>>>> OAuth today requires clients to register with the service provider = before they are deployed. Would you really expect IMAP clients, e.g. = Thunderbird, to register with any a-Mail services upfront? So clients = should be given a way to register dynamically to the authorization = servers. This should also allow us to cover "client instance" aspects. = It is interesting to note, that such a mechanism would allow us to get = rid of secret-less clients and the one-time usage requirement for = authorization codes. >>>>>=20 >>>>> We also assume the client to know the URLs of the resource server = and the corresponding authorization server and to use HTTPS server = authentication to verify the resource server's authenticity. This is = impossible in the standard scenario. Clients must be able to discover = the authorization server a particular resource server relies on at = runtime. The discovery mechanism could be specified by the OAuth WG, but = could also be part of an application protocols specification. But we = MUST find another way to prevent token phishing by counterfeit resource = servers. >>>>>=20 >>>>> As one approach, the client could pass the (previously HTTPS = validated) resource server's URL with the authorization request. The = authorization server should then refuse such = requests for any unknown (counterfeit) resource servers. Such an = additional parameter could also serve as namespace for scope values and = enable service providers to run multiple instances of the same service = within a single deployment. >>>>>=20 >>>>> If the additional data enlarges the request payload to much, we = could consider to adopt the "request by reference" proposal. >>>>>=20 >>>>> Let's now assume, OAuth is successful in the world of standard = protocols and we will see plenty of deployments with a bunch of = different OAuth protected resource servers. Shall this servers all be = accessible with a single token? In my opinion, this would cause = security, privacy and/or scalability/performance problems. To give just = the most obvious example, the target audience of such a token cannot be = restricted enough, which may allow a resource server (or an attacker in = control of it) to abuse the token on other servers. But the current = design of the code grant type forces deployments to use the same token = for all services. What is needed from my point of view is a way to = request and issue multiple server-specific access tokens with a single = authorization process. >>>>>=20 >>>>> I've been advocating this topic for a long time now and I'm still = convinced this is required to really complete the core design. We at = Deutsche Telekom needed and implemented this function on top of the = existing core. In my opinion, a core enhancement would be easier to = handle and more powerful. If others support this topic, I would be = willed to submit an I-D describing a possible solution. >>>>>=20 >>>>> If we take standards really seriously, then service providers = should be given the opportunity to implement their service by utilizing = standard server implementations. This creates the challenge to find a = standardized protocol between authorization server and resource server = to exchange authorization data. Depending on the token design = (self-contained vs. handle) this could be solved by either standardizing = a token format (JWT) or an authorization API. >>>>>=20 >>>>> Based on the rationale given above, my list is as follows (topics = w/o I-D are marked with *): >>>>>=20 >>>>> - Revocation (low hanging fruit since I-D is ready and implemented = in some places) >>>>> - Resource server notion* >>>>> - Multiple access tokens* >>>>> - Dynamic client registration >>>>>=20 >>>>> 1) Dynamic Client Registration Protocol >>>>> 4) Client Instance Extension >>>>> - Discovery >>>>> (10) Simple Web Discovery, probably other specs as well >>>>> - (6) JSON Web Token >>>>> - (7) JSON Web Token (JWT) Bearer Profile >>>>> - 8) User Experience Extension >>>>> - Device flow >>>>> - 9) Request by Reference >>>>> (depending resource server notion and multiple access tokens) >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>> Zitat von Hannes Tschofenig : >>>>>=20 >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> in preparation of the upcoming IETF meeting Barry and I would like = to start a re-chartering discussion. We both are currently attending = the Internet Identity Workshop and so we had the chance to solicit input = from the participants. This should serve as a discussion starter. >>>>>=20 >>>>> Potential future OAuth charter items (in random order): >>>>>=20 >>>>> ---------------- >>>>>=20 >>>>> 1) Dynamic Client Registration Protocol >>>>>=20 >>>>> Available document: >>>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>>>>=20 >>>>> 2) Token Revocation >>>>>=20 >>>>> Available document: >>>>> = http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>>>>=20 >>>>> 3) UMA >>>>>=20 >>>>> Available document: >>>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>>>>=20 >>>>> 4) Client Instance Extension >>>>>=20 >>>>> Available document: >>>>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>>>>=20 >>>>> 5) XML Encoding >>>>>=20 >>>>> Available document: >>>>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>>>>=20 >>>>> 6) JSON Web Token >>>>>=20 >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>>>>=20 >>>>> 7) JSON Web Token (JWT) Bearer Profile >>>>>=20 >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>>>>=20 >>>>> 8) User Experience Extension >>>>>=20 >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>>>>=20 >>>>> 9) Request by Reference >>>>>=20 >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>>>>=20 >>>>> 10) Simple Web Discovery >>>>>=20 >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>>>>=20 >>>>> ---------------- >>>>>=20 >>>>> We have the following questions: >>>>>=20 >>>>> a) Are you interested in any of the above-listed items? (as a = reviewer, co-author, implementer, or someone who would like to deploy). = It is also useful to know if you think that we shouldn't work on a = specific item. >>>>>=20 >>>>> b) Are there other items you would like to see the group working = on? >>>>>=20 >>>>> Note: In case your document is expired please re-submit it. >>>>>=20 >>>>> Ciao >>>>> Hannes & Barry >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>>=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 --Apple-Mail=_A656AB51-1664-4DAD-AB10-D40074138584 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-10-27, at 10:33 AM, torsten@lodderstedt.net = wrote:

Hi John,

why do = you need to include the OAuth request parameters into the JSON document? = I would expect OpenId Connect to extend OAuth none-intrusively. This = would mean to use the JSON document for OpenId connect specific = parameters only. Alternatively, the JSON request style could be adopted = as part of OAuth. Then, the URI request parameters could be = omitted.

regards,
Torsten.

Gesendet mit BlackBerry=AE = Webmail von Telekom Deutschland

From: John Bradley = <ve7jtb@ve7jtb.com>
Date: Thu, 27 Oct 2011 13:52:31 -0300
To: = Torsten Lodderstedt<torsten@lodderstedt.net>
Cc: Nat Sakimura<sakimura@gmail.com>; OAuth = WG<oauth@ietf.org>
Subject= : Re: [OAUTH-WG] Rechartering JSON based = request.

Hopefully to make it more compatible with = existing OAuth 2 libraries.    At least leave open the = possibility of dealing with it at a higher level.

The = argument has been made that you probably need to modify the library = anyway to check that the duplicate parameters are a = match.

If there is consensus that the = parameters should only be in the JSON then we would happily not = duplicate them.

It is mostly a case of trying = to fit in to the existing OAuth work and = libraries.

John B.

On = 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:

=20 =20
why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:
Nat and I just refreshed the I-D for .

It is essentially  a standardization of the method we = are using in openID Connect to make signed requests to the Authorization server.

We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an = extension.

Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on.

Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt = wrote:

Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with = this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 

Just a clarification: 

Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and  resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with = *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

 1) Dynamic Client Registration = Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other = specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and = multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion.  We both = are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration = Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dyn= reg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-= revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-uma= core/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.= txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05=

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-= 00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00=

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-0= 0

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-discov= ery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
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

= --Apple-Mail=_A656AB51-1664-4DAD-AB10-D40074138584-- From Michael.Jones@microsoft.com Thu Oct 27 10:56:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A899E21F84BB for ; Thu, 27 Oct 2011 10:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF1rlI4r0bkY for ; Thu, 27 Oct 2011 10:56:03 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA811E807F for ; Thu, 27 Oct 2011 10:56:03 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 27 Oct 2011 10:55:42 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.67]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Thu, 27 Oct 2011 10:55:41 -0700 From: Mike Jones To: Phil Hunt , "torsten@lodderstedt.net" Thread-Topic: [OAUTH-WG] Rechartering JSON based request. Thread-Index: AQHMlC9lO7exyy1jmkiUOmvwO4Fp/5WQHdWAgADAx4CAAAtfgIAABISA//+LH5A= Date: Thu, 27 Oct 2011 17:55:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F6C0446@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> <4EA8EA99.4010203@lodderstedt.net> <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> <486BD16C-070D-48CF-A82E-3382E67439AA@oracle.com> In-Reply-To: <486BD16C-070D-48CF-A82E-3382E67439AA@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F6C0446TK5EX14MBXC283r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:56:10 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F6C0446TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In OpenID Connect, the two tokens are used to access two different sets of = resources: the "id_token" for claims about the logged-in session and the "= code" token to access the UserInfo endpoint for claims about the user. FYI, see http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html = for a write-up on encoding multiple response types. (I'm told that at leas= t parts of this are already being used by Google and Facebook.) -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Thursday, October 27, 2011 10:49 AM To: torsten@lodderstedt.net Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. John, What is the reason behind having a separate ID_Token from the access Token?= I understand the tokens are used to retrieve different information, but n= ot sure I fully understand why separate tokens are needed. I ask because I recall others have asked for multi-token response....trying= to understand if there is a general use case behind this requirement. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-10-27, at 10:33 AM, torsten@lodderstedt.net wrote: Hi John, why do you need to include the OAuth request parameters into the JSON docum= ent? I would expect OpenId Connect to extend OAuth none-intrusively. This w= ould mean to use the JSON document for OpenId connect specific parameters o= nly. Alternatively, the JSON request style could be adopted as part of OAut= h. Then, the URI request parameters could be omitted. regards, Torsten. Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland ________________________________ From: John Bradley > Date: Thu, 27 Oct 2011 13:52:31 -0300 To: Torsten Lodderstedt> Cc: Nat Sakimura>; OAuth WG> Subject: Re: [OAUTH-WG] Rechartering JSON based request. Hopefully to make it more compatible with existing OAuth 2 libraries. At= least leave open the possibility of dealing with it at a higher level. The argument has been made that you probably need to modify the library any= way to check that the duplicate parameters are a match. If there is consensus that the parameters should only be in the JSON then w= e would happily not duplicate them. It is mostly a case of trying to fit in to the existing OAuth work and libr= aries. John B. On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: why is it neccessary to duplicate the OAuth request parameters? Am 27.10.2011 00:31, schrieb John Bradley: Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. It is essentially a standardization of the method we are using in openID C= onnect to make signed requests to the Authorization server. We do have the issue that parameters in the signed/encrypted request necess= arily duplicate the query parameters to keep it a valid OAuth request plus = an extension. Even if it doesn't wind up as a OAuth WG item it is probably worth people l= ooking at it before the final openID spec is voted on. Regards John B. On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: Hi Nat, I think your proposal would be a useful OAuth enhancement. A JSON-based req= uest format would allow for more complex requests (e.g. carrying resource s= erver URLs and corresponding scope values ;-)). Please note: I also think the way this mechanism is introduced and used in = the current OpenID connect spec requires OpenID connect clients and servers= to handle OAuth request parameters differently than for standard OAuth req= uests. Introducing the JSON based claim request capability to OAuth would b= e a way to cope with this. regards, Torsten. Am 22.10.2011 16:00, schrieb Nat Sakimura: Hi. Just a clarification: Although my expired draft is 'request by reference', what was proposed thro= ugh it at the iiw really is a generalized JSON based claim request capabili= ty. It could be passed by value as JSON or could be passed by reference. Th= e later is an optimization for bandwidth constrained network as well as str= engthening security in some ways. This capability already exists in OpenID = Connect but it is actually an underpinning transport, so it probably should= belong to OAuth instead. This was the primary reason for the proposal. Nat On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt > wrote: Hi all, my prioritization is driven by the goal to make OAuth the authorization fra= mework of choice for any internet standard protocol, such as WebDAV, IMAP, = SMTP or SIP. So let me first explain what is missing from my point of view = and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a= body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and u= sed by different but deployment-independent clients. OAuth-based protocol s= pecifications must also define scope values (e.g. read, write, send) and th= eir relation to the resource types and messages. The different deployments = expose the standard protocol on different resource server endpoints. In my = opinion, it is fundamental to clearly distinguish scope values (standardize= d, static) and resource server addresses (deployment specific) and to mana= ge their relationships. The current scope definition is much to weak and in= sufficient. Probably, the UMA concepts of hosts, resources sets, and corres= ponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider before t= hey are deployed. Would you really expect IMAP clients, e.g. Thunderbird, t= o register with any a-Mail services upfront? So clients should be given a w= ay to register dynamically to the authorization servers. This should also a= llow us to cover "client instance" aspects. It is interesting to note, that= such a mechanism would allow us to get rid of secret-less clients and the = one-time usage requirement for authorization codes. We also assume the client to know the URLs of the resource server and the c= orresponding authorization server and to use HTTPS server authentication to= verify the resource server's authenticity. This is impossible in the stand= ard scenario. Clients must be able to discover the authorization server a p= articular resource server relies on at runtime. The discovery mechanism cou= ld be specified by the OAuth WG, but could also be part of an application p= rotocols specification. But we MUST find another way to prevent token phish= ing by counterfeit resource servers. As one approach, the client could pass the (previously HTTPS validated) res= ource server's URL with the authorization request. The authorization server= should then refuse such requests for any unknown (counterfeit) resource se= rvers. Such an additional parameter could also serve as namespace for scope= values and enable service providers to run multiple instances of the same = service within a single deployment. If the additional data enlarges the request payload to much, we could consi= der to adopt the "request by reference" proposal. Let's now assume, OAuth is successful in the world of standard protocols an= d we will see plenty of deployments with a bunch of different OAuth protect= ed resource servers. Shall this servers all be accessible with a single tok= en? In my opinion, this would cause security, privacy and/or scalability/pe= rformance problems. To give just the most obvious example, the target audie= nce of such a token cannot be restricted enough, which may allow a resource= server (or an attacker in control of it) to abuse the token on other serve= rs. But the current design of the code grant type forces deployments to use= the same token for all services. What is needed from my point of view is a= way to request and issue multiple server-specific access tokens with a sin= gle authorization process. I've been advocating this topic for a long time now and I'm still convinced= this is required to really complete the core design. We at Deutsche Teleko= m needed and implemented this function on top of the existing core. In my o= pinion, a core enhancement would be easier to handle and more powerful. If = others support this topic, I would be willed to submit an I-D describing a = possible solution. If we take standards really seriously, then service providers should be giv= en the opportunity to implement their service by utilizing standard server = implementations. This creates the challenge to find a standardized protocol= between authorization server and resource server to exchange authorization= data. Depending on the token design (self-contained vs. handle) this could= be solved by either standardizing a token format (JWT) or an authorization= API. Based on the rationale given above, my list is as follows (topics w/o I-D a= re marked with *): - Revocation (low hanging fruit since I-D is ready and implemented in some = places) - Resource server notion* - Multiple access tokens* - Dynamic client registration 1) Dynamic Client Registration Protocol 4) Client Instance Extension - Discovery (10) Simple Web Discovery, probably other specs as well - (6) JSON Web Token - (7) JSON Web Token (JWT) Bearer Profile - 8) User Experience Extension - Device flow - 9) Request by Reference (depending resource server notion and multiple access tokens) regards, Torsten. Zitat von Hannes Tschofenig >: Hi all, in preparation of the upcoming IETF meeting Barry and I would like to start= a re-chartering discussion. We both are currently attending the Internet = Identity Workshop and so we had the chance to solicit input from the partic= ipants. This should serve as a discussion starter. Potential future OAuth charter items (in random order): ---------------- 1) Dynamic Client Registration Protocol Available document: http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ 2) Token Revocation Available document: http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ 3) UMA Available document: http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ 4) Client Instance Extension Available document: http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt 5) XML Encoding Available document: http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt 6) JSON Web Token Available document: http://tools.ietf.org/html/draft-jones-json-web-token-05 7) JSON Web Token (JWT) Bearer Profile Available document: http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 8) User Experience Extension Available document: http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 9) Request by Reference Available document: http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 10) Simple Web Discovery Available document: http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 ---------------- We have the following questions: a) Are you interested in any of the above-listed items? (as a reviewer, co-= author, implementer, or someone who would like to deploy). It is also usefu= l to know if you think that we shouldn't work on a specific item. b) Are there other items you would like to see the group working on? Note: In case your document is expired please re-submit it. Ciao Hannes & Barry _______________________________________________ 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ 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_4E1F6AAD24975D4BA5B16804296739435F6C0446TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In OpenID Connect, the tw= o tokens are used to access two different sets of resources:  the R= 20;id_token” for claims about the logged-in session and the “co= de” token to access the UserInfo endpoint for claims about the user.

 <= /p>

FYI, see http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html fo= r a write-up on encoding multiple response types.  (I’m told tha= t at least parts of this are already being used by Google and Facebook.)

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, October 27, 2011 10:49 AM
To: torsten@lodderstedt.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering JSON based request.<= /span>

 

John,

 

What is the reason behind having a separate ID_Token= from the access Token?  I understand the tokens are used to retrieve = different information, but not sure I fully understand why separate tokens = are needed.

 

I ask because I recall others have asked for multi-t= oken response….trying to understand if there is a general use case be= hind this requirement.

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com=

 <= /p>



 

On 2011-10-27, at 10:33 AM, torsten@lodderstedt.net wrote:



Hi John,

why do you need to include the OAuth request parameters into the JSON docum= ent? I would expect OpenId Connect to extend OAuth none-intrusively. This w= ould mean to use the JSON document for OpenId connect specific parameters o= nly. Alternatively, the JSON request style could be adopted as part of OAuth. Then, the URI request parameters = could be omitted.

regards,
Torsten.

Gesendet mit BlackBerry® Webmail von Telekom Deutschland =

From: John Bradley <ve7jtb@ve7jtb.com>

Date: Thu, 27 Oct 2011 13:52:31 -0300

To: Torsten Lodderstedt<torsten@lodderstedt.net>

Cc: Nat Sakimura<sakimura@gmail.com>; OAuth WG<oauth@ietf.org>

Subject: Re: [OAUTH-WG] Rechartering JSON bas= ed request.

 

Hopefully to make it more compatible with existing O= Auth 2 libraries.    At least leave open the possibility of deali= ng with it at a higher level.

 

The argument has been made that you probably need to= modify the library anyway to check that the duplicate parameters are a mat= ch.

 

If there is consensus that the parameters should onl= y be in the JSON then we would happily not duplicate them.

 

It is mostly a case of trying to fit in to the exist= ing OAuth work and libraries.

 

John B.

 

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote= :



why is it neccessary to duplicate the OAuth request = parameters?

Am 27.10.2011 00:31, schrieb John Bradley:

Nat and I just refr= eshed the I-D for draft-sakimura-oauth-requrl= .

 

It is essentially  a standardization of the met= hod we are using in openID Connect to make signed requests to the Authoriza= tion server.

 

We do have the issue that parameters in the signed/e= ncrypted request necessarily duplicate the query parameters to keep it a va= lid OAuth request plus an extension.

 

Even if it doesn't wind up as a OAuth WG item it is = probably worth people looking at it before the final openID spec is voted o= n.

 

Regards

John B.

 

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote= :



Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based req= uest format would allow for more complex requests (e.g. carrying resource s= erver URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in = the current OpenID connect spec requires OpenID connect clients and servers= to handle OAuth request parameters differently than for standard OAuth req= uests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:

Hi. 

 

Just a clarification: 

 

Although my expired draft is 'request by reference',= what was proposed through it at the iiw really is a generalized JSON based= claim request capability. It could be passed by value as JSON or could be = passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening= security in some ways. This capability already exists in OpenID Connect bu= t it is actually an underpinning transport, so it probably should belong to= OAuth instead. This was the primary reason for the proposal. 

 

Nat

 

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt= <torsten@lodderstedt.net= > wrote:

Hi all,

my prioritization is driven by the goal to make OAuth the authorization fra= mework of choice for any internet standard protocol, such as WebDAV, IMAP, = SMTP or SIP. So let me first explain what is missing from my point of view = and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a= body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and u= sed by different but deployment-independent clients. OAuth-based protocol s= pecifications must also define scope values (e.g. read, write, send) and their relation to the resource types a= nd messages. The different deployments expose the standard protocol on diff= erent resource server endpoints. In my opinion, it is fundamental to clearl= y distinguish scope values (standardized, static) and  resource server addresses (deployment specific) and to m= anage their relationships. The current scope definition is much to weak and= insufficient. Probably, the UMA concepts of hosts, resources sets, and cor= responding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before t= hey are deployed. Would you really expect IMAP clients, e.g. Thunderbird, t= o register with any a-Mail services upfront? So clients should be given a w= ay to register dynamically to the authorization servers. This should also allow us to cover "client ins= tance" aspects. It is interesting to note, that such a mechanism would= allow us to get rid of secret-less clients and the one-time usage requirem= ent for authorization codes.

We also assume the client to know the URLs of the resource server and the c= orresponding authorization server and to use HTTPS server authentication to= verify the resource server's authenticity. This is impossible in the stand= ard scenario. Clients must be able to discover the authorization server a particular resource server relies o= n at runtime. The discovery mechanism could be specified by the OAuth WG, b= ut could also be part of an application protocols specification. But we MUS= T find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) res= ource server's URL with the authorization request. The authorization server= should then refuse such requests for any unknown (counterfeit) resource se= rvers. Such an additional parameter could also serve as namespace for scope values and enable service provider= s to run multiple instances of the same service within a single deployment.=

If the additional data enlarges the request payload to much, we could consi= der to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols an= d we will see plenty of deployments with a bunch of different OAuth protect= ed resource servers. Shall this servers all be accessible with a single tok= en? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just th= e most obvious example, the target audience of such a token cannot be restr= icted enough, which may allow a resource server (or an attacker in control = of it) to abuse the token on other servers. But the current design of the code grant type forces deployments = to use the same token for all services. What is needed from my point of vie= w is a way to request and issue multiple server-specific access tokens with= a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced= this is required to really complete the core design. We at Deutsche Teleko= m needed and implemented this function on top of the existing core. In my o= pinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I wou= ld be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be giv= en the opportunity to implement their service by utilizing standard server = implementations. This creates the challenge to find a standardized protocol= between authorization server and resource server to exchange authorization data. Depending on the token des= ign (self-contained vs. handle) this could be solved by either standardizin= g a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D a= re marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some = places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration


 1) Dynamic Client Registration Protocol

 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:

 

Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start= a re-chartering discussion.  We both are currently attending the Inte= rnet Identity Workshop and so we had the chance to solicit input from the p= articipants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg= /

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodderstedt-oa= uth-revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-umaco= re/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt<= /a>

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05
7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00<= br>
10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-discove= ry-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-= author, implementer, or someone who would like to deploy). It is also usefu= l to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

 

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B16804296739435F6C0446TK5EX14MBXC283r_-- From phil.hunt@oracle.com Thu Oct 27 11:42:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB5C21F8B95 for ; Thu, 27 Oct 2011 11:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLHwMAPRrYDb for ; Thu, 27 Oct 2011 11:42:13 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8811A21F8B91 for ; Thu, 27 Oct 2011 11:42:13 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9RIgBBa015891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Oct 2011 18:42:12 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9RIg9RI010441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2011 18:42:10 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9RIg43b022563; Thu, 27 Oct 2011 13:42:04 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Oct 2011 11:42:03 -0700 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_FF959480-AAE5-41EA-8A60-7BA8CDCFB09D" From: Phil Hunt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F6C0446@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 27 Oct 2011 11:42:01 -0700 Message-Id: <921DAECE-5A59-4297-916F-B23683798C3E@oracle.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> <4EA8EA99.4010203@lodderstedt.net> <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> <486BD16C-070D-48CF-A82E-3382E67439AA@oracle.com> <4E1F6AAD24975D4BA5B16804296739435F6C0446@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1251.1) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090207.4EA9A604.0118,ss=1,re=-6.500,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 18:42:16 -0000 --Apple-Mail=_FF959480-AAE5-41EA-8A60-7BA8CDCFB09D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Mike, Why can't the same access token be used for both services? Is it = because the services have different security systems and demand = different tokens? Why not a single token for both? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-10-27, at 10:55 AM, Mike Jones wrote: > In OpenID Connect, the two tokens are used to access two different = sets of resources: the =93id_token=94 for claims about the logged-in = session and the =93code=94 token to access the UserInfo endpoint for = claims about the user. > =20 > FYI, see = http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html for a = write-up on encoding multiple response types. (I=92m told that at least = parts of this are already being used by Google and Facebook.) > =20 > -- = Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Thursday, October 27, 2011 10:49 AM > To: torsten@lodderstedt.net > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering JSON based request. > =20 > John, > =20 > What is the reason behind having a separate ID_Token from the access = Token? I understand the tokens are used to retrieve different = information, but not sure I fully understand why separate tokens are = needed. > =20 > I ask because I recall others have asked for multi-token = response=85.trying to understand if there is a general use case behind = this requirement. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > =20 >=20 >=20 > =20 > On 2011-10-27, at 10:33 AM, torsten@lodderstedt.net wrote: >=20 >=20 > Hi John, >=20 > why do you need to include the OAuth request parameters into the JSON = document? I would expect OpenId Connect to extend OAuth = none-intrusively. This would mean to use the JSON document for OpenId = connect specific parameters only. Alternatively, the JSON request style = could be adopted as part of OAuth. Then, the URI request parameters = could be omitted. >=20 > regards, > Torsten. > Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland >=20 > From: John Bradley > Date: Thu, 27 Oct 2011 13:52:31 -0300 > To: Torsten Lodderstedt > Cc: Nat Sakimura; OAuth WG > Subject: Re: [OAUTH-WG] Rechartering JSON based request. > =20 > Hopefully to make it more compatible with existing OAuth 2 libraries. = At least leave open the possibility of dealing with it at a higher = level. > =20 > The argument has been made that you probably need to modify the = library anyway to check that the duplicate parameters are a match. > =20 > If there is consensus that the parameters should only be in the JSON = then we would happily not duplicate them. > =20 > It is mostly a case of trying to fit in to the existing OAuth work and = libraries. > =20 > John B. > =20 > On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: >=20 >=20 > why is it neccessary to duplicate the OAuth request parameters? >=20 > Am 27.10.2011 00:31, schrieb John Bradley: > Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. > =20 > It is essentially a standardization of the method we are using in = openID Connect to make signed requests to the Authorization server. > =20 > We do have the issue that parameters in the signed/encrypted request = necessarily duplicate the query parameters to keep it a valid OAuth = request plus an extension. > =20 > Even if it doesn't wind up as a OAuth WG item it is probably worth = people looking at it before the final openID spec is voted on. > =20 > Regards > John B. > =20 > On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: >=20 >=20 > Hi Nat, >=20 > I think your proposal would be a useful OAuth enhancement. A = JSON-based request format would allow for more complex requests (e.g. = carrying resource server URLs and corresponding scope values ;-)).=20 >=20 > Please note: I also think the way this mechanism is introduced and = used in the current OpenID connect spec requires OpenID connect clients = and servers to handle OAuth request parameters differently than for = standard OAuth requests. Introducing the JSON based claim request = capability to OAuth would be a way to cope with this. >=20 > regards, > Torsten. >=20 > Am 22.10.2011 16:00, schrieb Nat Sakimura: > Hi.=20 > =20 > Just a clarification:=20 > =20 > Although my expired draft is 'request by reference', what was proposed = through it at the iiw really is a generalized JSON based claim request = capability. It could be passed by value as JSON or could be passed by = reference. The later is an optimization for bandwidth constrained = network as well as strengthening security in some ways. This capability = already exists in OpenID Connect but it is actually an underpinning = transport, so it probably should belong to OAuth instead. This was the = primary reason for the proposal.=20 > =20 > Nat > =20 > On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt = wrote: > Hi all, >=20 > my prioritization is driven by the goal to make OAuth the = authorization framework of choice for any internet standard protocol, = such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is = missing from my point of view and explain some thoughts how to fill the = gaps. >=20 > A standard protocol is defined in terms of resource types and messages = by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many = places, and used by different but deployment-independent clients. = OAuth-based protocol specifications must also define scope values (e.g. = read, write, send) and their relation to the resource types and = messages. The different deployments expose the standard protocol on = different resource server endpoints. In my opinion, it is fundamental to = clearly distinguish scope values (standardized, static) and resource = server addresses (deployment specific) and to manage their = relationships. The current scope definition is much to weak and = insufficient. Probably, the UMA concepts of hosts, resources sets, and = corresponding scopes could be adopted for that purpose. >=20 > OAuth today requires clients to register with the service provider = before they are deployed. Would you really expect IMAP clients, e.g. = Thunderbird, to register with any a-Mail services upfront? So clients = should be given a way to register dynamically to the authorization = servers. This should also allow us to cover "client instance" aspects. = It is interesting to note, that such a mechanism would allow us to get = rid of secret-less clients and the one-time usage requirement for = authorization codes. >=20 > We also assume the client to know the URLs of the resource server and = the corresponding authorization server and to use HTTPS server = authentication to verify the resource server's authenticity. This is = impossible in the standard scenario. Clients must be able to discover = the authorization server a particular resource server relies on at = runtime. The discovery mechanism could be specified by the OAuth WG, but = could also be part of an application protocols specification. But we = MUST find another way to prevent token phishing by counterfeit resource = servers. >=20 > As one approach, the client could pass the (previously HTTPS = validated) resource server's URL with the authorization request. The = authorization server should then refuse such requests for any unknown = (counterfeit) resource servers. Such an additional parameter could also = serve as namespace for scope values and enable service providers to run = multiple instances of the same service within a single deployment. >=20 > If the additional data enlarges the request payload to much, we could = consider to adopt the "request by reference" proposal. >=20 > Let's now assume, OAuth is successful in the world of standard = protocols and we will see plenty of deployments with a bunch of = different OAuth protected resource servers. Shall this servers all be = accessible with a single token? In my opinion, this would cause = security, privacy and/or scalability/performance problems. To give just = the most obvious example, the target audience of such a token cannot be = restricted enough, which may allow a resource server (or an attacker in = control of it) to abuse the token on other servers. But the current = design of the code grant type forces deployments to use the same token = for all services. What is needed from my point of view is a way to = request and issue multiple server-specific access tokens with a single = authorization process. >=20 > I've been advocating this topic for a long time now and I'm still = convinced this is required to really complete the core design. We at = Deutsche Telekom needed and implemented this function on top of the = existing core. In my opinion, a core enhancement would be easier to = handle and more powerful. If others support this topic, I would be = willed to submit an I-D describing a possible solution. >=20 > If we take standards really seriously, then service providers should = be given the opportunity to implement their service by utilizing = standard server implementations. This creates the challenge to find a = standardized protocol between authorization server and resource server = to exchange authorization data. Depending on the token design = (self-contained vs. handle) this could be solved by either standardizing = a token format (JWT) or an authorization API. >=20 > Based on the rationale given above, my list is as follows (topics w/o = I-D are marked with *): >=20 > - Revocation (low hanging fruit since I-D is ready and implemented in = some places) > - Resource server notion* > - Multiple access tokens* > - Dynamic client registration >=20 > 1) Dynamic Client Registration Protocol > 4) Client Instance Extension > - Discovery > (10) Simple Web Discovery, probably other specs as well > - (6) JSON Web Token > - (7) JSON Web Token (JWT) Bearer Profile > - 8) User Experience Extension > - Device flow > - 9) Request by Reference > (depending resource server notion and multiple access tokens) >=20 > regards, > Torsten. > Zitat von Hannes Tschofenig : > =20 >=20 > Hi all, >=20 > in preparation of the upcoming IETF meeting Barry and I would like to = start a re-chartering discussion. We both are currently attending the = Internet Identity Workshop and so we had the chance to solicit input = from the participants. This should serve as a discussion starter. >=20 > Potential future OAuth charter items (in random order): >=20 > ---------------- >=20 > 1) Dynamic Client Registration Protocol >=20 > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >=20 > 2) Token Revocation >=20 > Available document: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >=20 > 3) UMA >=20 > Available document: > http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >=20 > 4) Client Instance Extension >=20 > Available document: > http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >=20 > 5) XML Encoding >=20 > Available document: > http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >=20 > 6) JSON Web Token >=20 > Available document: > http://tools.ietf.org/html/draft-jones-json-web-token-05 >=20 > 7) JSON Web Token (JWT) Bearer Profile >=20 > Available document: > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >=20 > 8) User Experience Extension >=20 > Available document: > http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >=20 > 9) Request by Reference >=20 > Available document: > http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >=20 > 10) Simple Web Discovery >=20 > Available document: > http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >=20 > ---------------- >=20 > We have the following questions: >=20 > a) Are you interested in any of the above-listed items? (as a = reviewer, co-author, implementer, or someone who would like to deploy). = It is also useful to know if you think that we shouldn't work on a = specific item. >=20 > b) Are there other items you would like to see the group working on? >=20 > Note: In case your document is expired please re-submit it. >=20 > Ciao > Hannes & Barry >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > =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 --Apple-Mail=_FF959480-AAE5-41EA-8A60-7BA8CDCFB09D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-10-27, at 10:55 AM, Mike Jones wrote:

In OpenID Connect, the two tokens are used to access = two different sets of resources:  the =93id_token=94 for claims = about the logged-in session and the =93code=94 token to access the = UserInfo endpoint for claims about the user.
 
 oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Thursday, October 27, 2011 = 10:49 AM
To: torsten@lodderstedt.net
= Cc: OAuth = WG
Subject: Re: [OAUTH-WG] Rechartering = JSON based request.
 
What is the reason = behind having a separate ID_Token from the access Token?  I = understand the tokens are used to retrieve different information, but = not sure I fully understand why separate tokens are = needed.
I ask because I = recall others have asked for multi-token response=85.trying to = understand if there is a general use case behind this = requirement.
Phil
@independentid


=


Hi John,

why = do you need to include the OAuth request parameters into the JSON = document? I would expect OpenId Connect to extend OAuth = none-intrusively. This would mean to use the JSON document for OpenId = connect specific parameters only. Alternatively, the JSON request style = could be adopted as part of OAuth. Then, the URI request parameters = could be omitted.

regards,
Torsten.

Gesendet mit BlackBerry=AE = Webmail von Telekom Deutschland

From: John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 27 Oct 2011 = 13:52:31 -0300
To: Torsten = Lodderstedt<Cc: Nat Sakimura<sakimura@gmail.com>; OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] = Rechartering JSON based request.
 
Hopefully to make it = more compatible with existing OAuth 2 libraries.    At least = leave open the possibility of dealing with it at a higher = level.
The argument has been = made that you probably need to modify the library anyway to check that = the duplicate parameters are a match.
 
If there is consensus = that the parameters should only be in the JSON then we would happily not = duplicate them.
It is mostly a case = of trying to fit in to the existing OAuth work and = libraries.
John = B.
On 2011-10-27, at = 2:22 AM, Torsten Lodderstedt wrote:


why is it neccessary = to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, = schrieb John Bradley:
Nat and I just refreshed the I-D = for .
 
It is essentially =  a standardization of the method we are using in openID Connect to = make signed requests to the Authorization = server.
We do have the issue = that parameters in the signed/encrypted request necessarily duplicate = the query parameters to keep it a valid OAuth request plus an = extension.
Even if it doesn't = wind up as a OAuth WG item it is probably worth people looking at it = before the final openID spec is voted = on.
John = B.
On 2011-10-26, at = 3:16 PM, Torsten Lodderstedt wrote:


Hi Nat,

I = think your proposal would be a useful OAuth enhancement. A JSON-based = request format would allow for more complex requests (e.g. carrying = resource server URLs and corresponding scope values ;-)). 

Please note: I also = think the way this mechanism is introduced and used in the current = OpenID connect spec requires OpenID connect clients and servers to = handle OAuth request parameters differently than for standard OAuth = requests. Introducing the JSON based claim request capability to OAuth = would be a way to cope with this.

regards,
Torsten.

Am = 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 
Just a = clarification: 
 
Although my expired = draft is 'request by reference', what was proposed through it at the iiw = really is a generalized JSON based claim request capability. It could be = passed by value as JSON or could be passed by reference. The later is an = optimization for bandwidth constrained network as well as strengthening = security in some ways. This capability already exists in OpenID Connect = but it is actually an underpinning transport, so it probably should = belong to OAuth instead. This was the primary reason for the = proposal. 
On Thu, Oct 20, 2011 = at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
Hi all,

my prioritization is = driven by the goal to make OAuth the authorization framework of choice = for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. = So let me first explain what is missing from my point of view and = explain some thoughts how to fill the gaps.

A standard protocol = is defined in terms of resource types and messages by a body (e.g. IETF, = OIDF, OMA), (hopefully) implemented in many places, and used by = different but deployment-independent clients. OAuth-based protocol = specifications must also define scope values (e.g. read, write, send) = and their relation to the resource types and messages. The different = deployments expose the standard protocol on different resource server = endpoints. In my opinion, it is fundamental to clearly distinguish scope = values (standardized, static) and  resource server addresses = (deployment specific) and to manage their relationships. The current = scope definition is much to weak and insufficient. Probably, the UMA = concepts of hosts, resources sets, and corresponding scopes could be = adopted for that purpose.

OAuth today requires clients to = register with the service provider before they are deployed. Would you = really expect IMAP clients, e.g. Thunderbird, to register with any = a-Mail services upfront? So clients should be given a way to register = dynamically to the authorization servers. This should also allow us to = cover "client instance" aspects. It is interesting to note, that such a = mechanism would allow us to get rid of secret-less clients and the = one-time usage requirement for authorization codes.

We also = assume the client to know the URLs of the resource server and the = corresponding authorization server and to use HTTPS server = authentication to verify the resource server's authenticity. This is = impossible in the standard scenario. Clients must be able to discover = the authorization server a particular resource server relies on at = runtime. The discovery mechanism could be specified by the OAuth WG, but = could also be part of an application protocols specification. But we = MUST find another way to prevent token phishing by counterfeit resource = servers.

As one approach, the client could pass the (previously = HTTPS validated) resource server's URL with the authorization request. = The authorization server should then refuse such requests for any = unknown (counterfeit) resource servers. Such an additional parameter = could also serve as namespace for scope values and enable service = providers to run multiple instances of the same service within a single = deployment.

If the additional data enlarges the request payload = to much, we could consider to adopt the "request by reference" = proposal.

Let's now assume, OAuth is successful in the world of = standard protocols and we will see plenty of deployments with a bunch of = different OAuth protected resource servers. Shall this servers all be = accessible with a single token? In my opinion, this would cause = security, privacy and/or scalability/performance problems. To give just = the most obvious example, the target audience of such a token cannot be = restricted enough, which may allow a resource server (or an attacker in = control of it) to abuse the token on other servers. But the current = design of the code grant type forces deployments to use the same token = for all services. What is needed from my point of view is a way to = request and issue multiple server-specific access tokens with a single = authorization process.

I've been advocating this topic for a long = time now and I'm still convinced this is required to really complete the = core design. We at Deutsche Telekom needed and implemented this function = on top of the existing core. In my opinion, a core enhancement would be = easier to handle and more powerful. If others support this topic, I = would be willed to submit an I-D describing a possible = solution.

If we take standards really seriously, then service = providers should be given the opportunity to implement their service by = utilizing standard server implementations. This creates the challenge to = find a standardized protocol between authorization server and resource = server to exchange authorization data. Depending on the token design = (self-contained vs. handle) this could be solved by either standardizing = a token format (JWT) or an authorization API.

Based on the = rationale given above, my list is as follows (topics w/o I-D are marked = with *):

- Revocation (low hanging fruit since I-D is ready and = implemented in some places)
- Resource server notion*
- Multiple = access tokens*
- Dynamic client = registration

 1) Dynamic = Client Registration Protocol
 4) Client Instance Extension
- = Discovery
 (10) Simple Web Discovery, probably other specs as = well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer = Profile
- 8) User Experience Extension
- Device flow
- 9) = Request by Reference
 (depending resource server notion and = multiple access tokens)

regards,
Torsten.
Zitat von Hannes = Tschofenig <

 

OAuth@ietf.org
In-Reply-To: <921DAECE-5A59-4297-916F-B23683798C3E@oracle.com> Date: Thu, 27 Oct 2011 15:58:14 -0300 Message-Id: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> <4EA8EA99.4010203@lodderstedt.net> <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> <486BD16C-070D-48CF-A82E-3382E67439AA@oracle.com> <4E1F6AAD24975D4BA5B16804296739435F6C0446@TK5EX14MBXC283.redmond.corp.microsoft.com> <921DAECE-5A59-4297-916F-B23683798C3E@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering Multi Token Ressponse. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 18:58:30 -0000 --Apple-Mail=_DFF9672A-27EA-452A-9E1C-320AA1567345 Content-Type: multipart/alternative; boundary="Apple-Mail=_74790ADF-1FE4-4850-AF28-FCCB48EC1E9D" --Apple-Mail=_74790ADF-1FE4-4850-AF28-FCCB48EC1E9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Changing the subject to reflect the question. Good question. We did try to come up with a way to only have one token. One of the requirements from the social network RP's was to get a = identity token in the from channel that they could directly parse to = customize the user experience. Getting a code then exchanging it for a access token then getting the = user_id was not acceptable. Thus we needed to have a signed id_token, that however ran into conflict = with providers current user-info endpoints and other OAuth protected = resources. The decision was made to keep the access tokens opaque to allow scopes = for multiple resources to be attached to the access token. Given that the id_token is signed JSON it is not a good thing to start = passing it around with the user ID in it for privacy reasons. I think that everyone agrees that sometimes you need differently scoped = tokens from the same authorization. =20 Using code and refresh tokens you can do that, However not all flows = support refresh tokens and down scoping. John B. On 2011-10-27, at 3:42 PM, Phil Hunt wrote: > Mike, >=20 > Why can't the same access token be used for both services? Is it = because the services have different security systems and demand = different tokens? Why not a single token for both? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2011-10-27, at 10:55 AM, Mike Jones wrote: >=20 >> In OpenID Connect, the two tokens are used to access two different = sets of resources: the =93id_token=94 for claims about the logged-in = session and the =93code=94 token to access the UserInfo endpoint for = claims about the user. >> =20 >> FYI, see = http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html for a = write-up on encoding multiple response types. (I=92m told that at least = parts of this are already being used by Google and Facebook.) >> =20 >> -- = Mike >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Phil Hunt >> Sent: Thursday, October 27, 2011 10:49 AM >> To: torsten@lodderstedt.net >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering JSON based request. >> =20 >> John, >> =20 >> What is the reason behind having a separate ID_Token from the access = Token? I understand the tokens are used to retrieve different = information, but not sure I fully understand why separate tokens are = needed. >> =20 >> I ask because I recall others have asked for multi-token = response=85.trying to understand if there is a general use case behind = this requirement. >> =20 >> Phil >> =20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >>=20 >> =20 >> On 2011-10-27, at 10:33 AM, torsten@lodderstedt.net wrote: >>=20 >>=20 >> Hi John, >>=20 >> why do you need to include the OAuth request parameters into the JSON = document? I would expect OpenId Connect to extend OAuth = none-intrusively. This would mean to use the JSON document for OpenId = connect specific parameters only. Alternatively, the JSON request style = could be adopted as part of OAuth. Then, the URI request parameters = could be omitted. >>=20 >> regards, >> Torsten. >> Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland >>=20 >> From: John Bradley >> Date: Thu, 27 Oct 2011 13:52:31 -0300 >> To: Torsten Lodderstedt >> Cc: Nat Sakimura; OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering JSON based request. >> =20 >> Hopefully to make it more compatible with existing OAuth 2 libraries. = At least leave open the possibility of dealing with it at a higher = level. >> =20 >> The argument has been made that you probably need to modify the = library anyway to check that the duplicate parameters are a match. >> =20 >> If there is consensus that the parameters should only be in the JSON = then we would happily not duplicate them. >> =20 >> It is mostly a case of trying to fit in to the existing OAuth work = and libraries. >> =20 >> John B. >> =20 >> On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: >>=20 >>=20 >> why is it neccessary to duplicate the OAuth request parameters? >>=20 >> Am 27.10.2011 00:31, schrieb John Bradley: >> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. >> =20 >> It is essentially a standardization of the method we are using in = openID Connect to make signed requests to the Authorization server. >> =20 >> We do have the issue that parameters in the signed/encrypted request = necessarily duplicate the query parameters to keep it a valid OAuth = request plus an extension. >> =20 >> Even if it doesn't wind up as a OAuth WG item it is probably worth = people looking at it before the final openID spec is voted on. >> =20 >> Regards >> John B. >> =20 >> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: >>=20 >>=20 >> Hi Nat, >>=20 >> I think your proposal would be a useful OAuth enhancement. A = JSON-based request format would allow for more complex requests (e.g. = carrying resource server URLs and corresponding scope values ;-)).=20 >>=20 >> Please note: I also think the way this mechanism is introduced and = used in the current OpenID connect spec requires OpenID connect clients = and servers to handle OAuth request parameters differently than for = standard OAuth requests. Introducing the JSON based claim request = capability to OAuth would be a way to cope with this. >>=20 >> regards, >> Torsten. >>=20 >> Am 22.10.2011 16:00, schrieb Nat Sakimura: >> Hi.=20 >> =20 >> Just a clarification:=20 >> =20 >> Although my expired draft is 'request by reference', what was = proposed through it at the iiw really is a generalized JSON based claim = request capability. It could be passed by value as JSON or could be = passed by reference. The later is an optimization for bandwidth = constrained network as well as strengthening security in some ways. This = capability already exists in OpenID Connect but it is actually an = underpinning transport, so it probably should belong to OAuth instead. = This was the primary reason for the proposal.=20 >> =20 >> Nat >> =20 >> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt = wrote: >> Hi all, >>=20 >> my prioritization is driven by the goal to make OAuth the = authorization framework of choice for any internet standard protocol, = such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is = missing from my point of view and explain some thoughts how to fill the = gaps. >>=20 >> A standard protocol is defined in terms of resource types and = messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in = many places, and used by different but deployment-independent clients. = OAuth-based protocol specifications must also define scope values (e.g. = read, write, send) and their relation to the resource types and = messages. The different deployments expose the standard protocol on = different resource server endpoints. In my opinion, it is fundamental to = clearly distinguish scope values (standardized, static) and resource = server addresses (deployment specific) and to manage their = relationships. The current scope definition is much to weak and = insufficient. Probably, the UMA concepts of hosts, resources sets, and = corresponding scopes could be adopted for that purpose. >>=20 >> OAuth today requires clients to register with the service provider = before they are deployed. Would you really expect IMAP clients, e.g. = Thunderbird, to register with any a-Mail services upfront? So clients = should be given a way to register dynamically to the authorization = servers. This should also allow us to cover "client instance" aspects. = It is interesting to note, that such a mechanism would allow us to get = rid of secret-less clients and the one-time usage requirement for = authorization codes. >>=20 >> We also assume the client to know the URLs of the resource server and = the corresponding authorization server and to use HTTPS server = authentication to verify the resource server's authenticity. This is = impossible in the standard scenario. Clients must be able to discover = the authorization server a particular resource server relies on at = runtime. The discovery mechanism could be specified by the OAuth WG, but = could also be part of an application protocols specification. But we = MUST find another way to prevent token phishing by counterfeit resource = servers. >>=20 >> As one approach, the client could pass the (previously HTTPS = validated) resource server's URL with the authorization request. The = authorization server should then refuse such requests for any unknown = (counterfeit) resource servers. Such an additional parameter could also = serve as namespace for scope values and enable service providers to run = multiple instances of the same service within a single deployment. >>=20 >> If the additional data enlarges the request payload to much, we could = consider to adopt the "request by reference" proposal. >>=20 >> Let's now assume, OAuth is successful in the world of standard = protocols and we will see plenty of deployments with a bunch of = different OAuth protected resource servers. Shall this servers all be = accessible with a single token? In my opinion, this would cause = security, privacy and/or scalability/performance problems. To give just = the most obvious example, the target audience of such a token cannot be = restricted enough, which may allow a resource server (or an attacker in = control of it) to abuse the token on other servers. But the current = design of the code grant type forces deployments to use the same token = for all services. What is needed from my point of view is a way to = request and issue multiple server-specific access tokens with a single = authorization process. >>=20 >> I've been advocating this topic for a long time now and I'm still = convinced this is required to really complete the core design. We at = Deutsche Telekom needed and implemented this function on top of the = existing core. In my opinion, a core enhancement would be easier to = handle and more powerful. If others support this topic, I would be = willed to submit an I-D describing a possible solution. >>=20 >> If we take standards really seriously, then service providers should = be given the opportunity to implement their service by utilizing = standard server implementations. This creates the challenge to find a = standardized protocol between authorization server and resource server = to exchange authorization data. Depending on the token design = (self-contained vs. handle) this could be solved by either standardizing = a token format (JWT) or an authorization API. >>=20 >> Based on the rationale given above, my list is as follows (topics w/o = I-D are marked with *): >>=20 >> - Revocation (low hanging fruit since I-D is ready and implemented in = some places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >>=20 >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >>=20 >> regards, >> Torsten. >> Zitat von Hannes Tschofenig : >> =20 >>=20 >> Hi all, >>=20 >> in preparation of the upcoming IETF meeting Barry and I would like to = start a re-chartering discussion. We both are currently attending the = Internet Identity Workshop and so we had the chance to solicit input = from the participants. This should serve as a discussion starter. >>=20 >> Potential future OAuth charter items (in random order): >>=20 >> ---------------- >>=20 >> 1) Dynamic Client Registration Protocol >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>=20 >> 2) Token Revocation >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>=20 >> 3) UMA >>=20 >> Available document: >> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>=20 >> 4) Client Instance Extension >>=20 >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>=20 >> 5) XML Encoding >>=20 >> Available document: >> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>=20 >> 6) JSON Web Token >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>=20 >> 7) JSON Web Token (JWT) Bearer Profile >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>=20 >> 8) User Experience Extension >>=20 >> Available document: >> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>=20 >> 9) Request by Reference >>=20 >> Available document: >> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>=20 >> 10) Simple Web Discovery >>=20 >> Available document: >> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>=20 >> ---------------- >>=20 >> We have the following questions: >>=20 >> a) Are you interested in any of the above-listed items? (as a = reviewer, co-author, implementer, or someone who would like to deploy). = It is also useful to know if you think that we shouldn't work on a = specific item. >>=20 >> b) Are there other items you would like to see the group working on? >>=20 >> Note: In case your document is expired please re-submit it. >>=20 >> Ciao >> Hannes & Barry >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> =20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> =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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_74790ADF-1FE4-4850-AF28-FCCB48EC1E9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Mike,

Why = can't the same access token be used for both services?  Is it = because the services have different security systems and demand = different tokens?  Why not a single token for = both?


On 2011-10-27, at 10:55 AM, Mike Jones wrote:

In OpenID Connect, the two tokens are used to access = two different sets of resources:  the =93id_token=94 for claims = about the logged-in session and the =93code=94 token to access the = UserInfo endpoint for claims about the user.
 
 oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Phil = Hunt
Sent: Thursday, October 27, 2011 = 10:49 AM
To: torsten@lodderstedt.net
= Cc: OAuth = WG
Subject: Re: [OAUTH-WG] Rechartering = JSON based request.
 
What is the reason = behind having a separate ID_Token from the access Token?  I = understand the tokens are used to retrieve different information, but = not sure I fully understand why separate tokens are = needed.
I ask because I = recall others have asked for multi-token response=85.trying to = understand if there is a general use case behind this = requirement.
Phil
@independentid


=


Hi John,

why = do you need to include the OAuth request parameters into the JSON = document? I would expect OpenId Connect to extend OAuth = none-intrusively. This would mean to use the JSON document for OpenId = connect specific parameters only. Alternatively, the JSON request style = could be adopted as part of OAuth. Then, the URI request parameters = could be omitted.

regards,
Torsten.

Gesendet mit BlackBerry=AE = Webmail von Telekom Deutschland

From: John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 27 Oct 2011 = 13:52:31 -0300
To: Torsten = Lodderstedt<Cc: Nat Sakimura<sakimura@gmail.com>; OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] = Rechartering JSON based request.
 
Hopefully to make it = more compatible with existing OAuth 2 libraries.    At least = leave open the possibility of dealing with it at a higher = level.
The argument has been = made that you probably need to modify the library anyway to check that = the duplicate parameters are a match.
 
If there is consensus = that the parameters should only be in the JSON then we would happily not = duplicate them.
It is mostly a case = of trying to fit in to the existing OAuth work and = libraries.
John = B.
On 2011-10-27, at = 2:22 AM, Torsten Lodderstedt wrote:


why is it neccessary = to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, = schrieb John Bradley:
Nat and I just refreshed the I-D = for .
 
It is essentially =  a standardization of the method we are using in openID Connect to = make signed requests to the Authorization = server.
We do have the issue = that parameters in the signed/encrypted request necessarily duplicate = the query parameters to keep it a valid OAuth request plus an = extension.
Even if it doesn't = wind up as a OAuth WG item it is probably worth people looking at it = before the final openID spec is voted = on.
John = B.
On 2011-10-26, at = 3:16 PM, Torsten Lodderstedt wrote:


Hi Nat,

I = think your proposal would be a useful OAuth enhancement. A JSON-based = request format would allow for more complex requests (e.g. carrying = resource server URLs and corresponding scope values ;-)). 

Please note: I also = think the way this mechanism is introduced and used in the current = OpenID connect spec requires OpenID connect clients and servers to = handle OAuth request parameters differently than for standard OAuth = requests. Introducing the JSON based claim request capability to OAuth = would be a way to cope with this.

regards,
Torsten.

Am = 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 
Just a = clarification: 
 
Although my expired = draft is 'request by reference', what was proposed through it at the iiw = really is a generalized JSON based claim request capability. It could be = passed by value as JSON or could be passed by reference. The later is an = optimization for bandwidth constrained network as well as strengthening = security in some ways. This capability already exists in OpenID Connect = but it is actually an underpinning transport, so it probably should = belong to OAuth instead. This was the primary reason for the = proposal. 
On Thu, Oct 20, 2011 = at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
Hi all,

my prioritization is = driven by the goal to make OAuth the authorization framework of choice = for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. = So let me first explain what is missing from my point of view and = explain some thoughts how to fill the gaps.

A standard protocol = is defined in terms of resource types and messages by a body (e.g. IETF, = OIDF, OMA), (hopefully) implemented in many places, and used by = different but deployment-independent clients. OAuth-based protocol = specifications must also define scope values (e.g. read, write, send) = and their relation to the resource types and messages. The different = deployments expose the standard protocol on different resource server = endpoints. In my opinion, it is fundamental to clearly distinguish scope = values (standardized, static) and  resource server addresses = (deployment specific) and to manage their relationships. The current = scope definition is much to weak and insufficient. Probably, the UMA = concepts of hosts, resources sets, and corresponding scopes could be = adopted for that purpose.

OAuth today requires clients to = register with the service provider before they are deployed. Would you = really expect IMAP clients, e.g. Thunderbird, to register with any = a-Mail services upfront? So clients should be given a way to register = dynamically to the authorization servers. This should also allow us to = cover "client instance" aspects. It is interesting to note, that such a = mechanism would allow us to get rid of secret-less clients and the = one-time usage requirement for authorization codes.

We also = assume the client to know the URLs of the resource server and the = corresponding authorization server and to use HTTPS server = authentication to verify the resource server's authenticity. This is = impossible in the standard scenario. Clients must be able to discover = the authorization server a particular resource server relies on at = runtime. The discovery mechanism could be specified by the OAuth WG, but = could also be part of an application protocols specification. But we = MUST find another way to prevent token phishing by counterfeit resource = servers.

As one approach, the client could pass the (previously = HTTPS validated) resource server's URL with the authorization request. = The authorization server should then refuse such requests for any = unknown (counterfeit) resource servers. Such an additional parameter = could also serve as namespace for scope values and enable service = providers to run multiple instances of the same service within a single = deployment.

If the additional data enlarges the request payload = to much, we could consider to adopt the "request by reference" = proposal.

Let's now assume, OAuth is successful in the world of = standard protocols and we will see plenty of deployments with a bunch of = different OAuth protected resource servers. Shall this servers all be = accessible with a single token? In my opinion, this would cause = security, privacy and/or scalability/performance problems. To give just = the most obvious example, the target audience of such a token cannot be = restricted enough, which may allow a resource server (or an attacker in = control of it) to abuse the token on other servers. But the current = design of the code grant type forces deployments to use the same token = for all services. What is needed from my point of view is a way to = request and issue multiple server-specific access tokens with a single = authorization process.

I've been advocating this topic for a long = time now and I'm still convinced this is required to really complete the = core design. We at Deutsche Telekom needed and implemented this function = on top of the existing core. In my opinion, a core enhancement would be = easier to handle and more powerful. If others support this topic, I = would be willed to submit an I-D describing a possible = solution.

If we take standards really seriously, then service = providers should be given the opportunity to implement their service by = utilizing standard server implementations. This creates the challenge to = find a standardized protocol between authorization server and resource = server to exchange authorization data. Depending on the token design = (self-contained vs. handle) this could be solved by either standardizing = a token format (JWT) or an authorization API.

Based on the = rationale given above, my list is as follows (topics w/o I-D are marked = with *):

- Revocation (low hanging fruit since I-D is ready and = implemented in some places)
- Resource server notion*
- Multiple = access tokens*
- Dynamic client = registration

 1) Dynamic = Client Registration Protocol
 4) Client Instance Extension
- = Discovery
 (10) Simple Web Discovery, probably other specs as = well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer = Profile
- 8) User Experience Extension
- Device flow
- 9) = Request by Reference
 (depending resource server notion and = multiple access tokens)

regards,
Torsten.
Zitat von Hannes = Tschofenig <

 

OAuth@ietf.org
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_74790ADF-1FE4-4850-AF28-FCCB48EC1E9D-- --Apple-Mail=_DFF9672A-27EA-452A-9E1C-320AA1567345 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEw MjcxODU4MTVaMCMGCSqGSIb3DQEJBDEWBBTLXp8bPRizma4Z132APUhlVsdmODCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAc1BntIMf6/miG0/iorF0amsZrFas2mNgq4XX5J1u2Q13/t5pcexydH8+C0Re+xHMOAbOiwS+Y GT0ycJaCoG4PnbroOlIm/ZQqPFZAmUef9Uri/AA4pbB/nMVVVsDWH7cRfYosN9bJt7XLeaUWGa5c 6/RV/s93ZlI44uYgKaRy3+0bx3QuOrCc+p0XemfbzUU6BnWGSx8rCzExgHZOYiGFcurSZ2j9DweV 0L/9PQ1AK1JioYbFJ3pbWKw80GRTz43FOydfuXV/lCCFQgAOEp9s/4yPXIvVkv9yzltvcmxKuL9l rv4Vg+tx7Dcyupt/s11anWNc0ZtercTDcsFHngIuAAAAAAAA --Apple-Mail=_DFF9672A-27EA-452A-9E1C-320AA1567345-- From gffletch@aol.com Thu Oct 27 13:25:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51921F86F6 for ; Thu, 27 Oct 2011 13:25:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W1JZuZYjn2G for ; Thu, 27 Oct 2011 13:24:59 -0700 (PDT) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by ietfa.amsl.com (Postfix) with ESMTP id 346D321F8AD2 for ; Thu, 27 Oct 2011 13:24:59 -0700 (PDT) Received: from mtaout-mb04.r1000.mx.aol.com (mtaout-mb04.r1000.mx.aol.com [172.29.41.68]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id p9RKOcF6015699; Thu, 27 Oct 2011 16:24:38 -0400 Received: from palantir.local (unknown [10.181.183.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 6C1C7E0000B4; Thu, 27 Oct 2011 16:24:37 -0400 (EDT) Message-ID: <4EA9BE04.9060607@aol.com> Date: Thu, 27 Oct 2011 16:24:36 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: torsten@lodderstedt.net References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> <4EA8EA99.4010203@lodderstedt.net> <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> In-Reply-To: <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> Content-Type: multipart/alternative; boundary="------------070007050806090508000806" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:462042912:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29444ea9be0550a3 X-AOL-IP: 10.181.183.152 Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 20:25:01 -0000 This is a multi-part message in MIME format. --------------070007050806090508000806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The main reason to include the OAuth parameters in the request is to ensure that the request object was not modified in transit since the JSON request object can be signed. Agreed that it would be simpler if OAuth adopted the JSON request style. Thanks, George On 10/27/11 1:33 PM, torsten@lodderstedt.net wrote: > Hi John, > > why do you need to include the OAuth request parameters into the JSON > document? I would expect OpenId Connect to extend OAuth > none-intrusively. This would mean to use the JSON document for OpenId > connect specific parameters only. Alternatively, the JSON request > style could be adopted as part of OAuth. Then, the URI request > parameters could be omitted. > > regards, > Torsten. > > Gesendet mit BlackBerry® Webmail von Telekom Deutschland > > ------------------------------------------------------------------------ > *From: * John Bradley > *Date: *Thu, 27 Oct 2011 13:52:31 -0300 > *To: *Torsten Lodderstedt > *Cc: *Nat Sakimura; OAuth WG > *Subject: *Re: [OAUTH-WG] Rechartering JSON based request. > > Hopefully to make it more compatible with existing OAuth 2 libraries. > At least leave open the possibility of dealing with it at a higher > level. > > The argument has been made that you probably need to modify the > library anyway to check that the duplicate parameters are a match. > > If there is consensus that the parameters should only be in the JSON > then we would happily not duplicate them. > > It is mostly a case of trying to fit in to the existing OAuth work and > libraries. > > John B. > > On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: > >> why is it neccessary to duplicate the OAuth request parameters? >> >> Am 27.10.2011 00:31, schrieb John Bradley: >>> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. >>> >>> It is essentially a standardization of the method we are using in >>> openID Connect to make signed requests to the Authorization server. >>> >>> We do have the issue that parameters in the signed/encrypted request >>> necessarily duplicate the query parameters to keep it a valid OAuth >>> request plus an extension. >>> >>> Even if it doesn't wind up as a OAuth WG item it is probably worth >>> people looking at it before the final openID spec is voted on. >>> >>> Regards >>> John B. >>> >>> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: >>> >>>> Hi Nat, >>>> >>>> I think your proposal would be a useful OAuth enhancement. A >>>> JSON-based request format would allow for more complex requests >>>> (e.g. carrying resource server URLs and corresponding scope values >>>> ;-)). >>>> >>>> Please note: I also think the way this mechanism is introduced and >>>> used in the current OpenID connect spec requires OpenID connect >>>> clients and servers to handle OAuth request parameters differently >>>> than for standard OAuth requests. Introducing the JSON based claim >>>> request capability to OAuth would be a way to cope with this. >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 22.10.2011 16:00, schrieb Nat Sakimura: >>>>> Hi. >>>>> >>>>> Just a clarification: >>>>> >>>>> Although my expired draft is 'request by reference', what was >>>>> proposed through it at the iiw really is a generalized JSON based >>>>> claim request capability. It could be passed by value as JSON or >>>>> could be passed by reference. The later is an optimization for >>>>> bandwidth constrained network as well as strengthening security in >>>>> some ways. This capability already exists in OpenID Connect but it >>>>> is actually an underpinning transport, so it probably should >>>>> belong to OAuth instead. This was the primary reason for the >>>>> proposal. >>>>> >>>>> Nat >>>>> >>>>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt >>>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> my prioritization is driven by the goal to make OAuth the >>>>> authorization framework of choice for any internet standard >>>>> protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first >>>>> explain what is missing from my point of view and explain some >>>>> thoughts how to fill the gaps. >>>>> >>>>> A standard protocol is defined in terms of resource types and >>>>> messages by a body (e.g. IETF, OIDF, OMA), (hopefully) >>>>> implemented in many places, and used by different but >>>>> deployment-independent clients. OAuth-based protocol >>>>> specifications must also define scope values (e.g. read, >>>>> write, send) and their relation to the resource types and >>>>> messages. The different deployments expose the standard >>>>> protocol on different resource server endpoints. In my >>>>> opinion, it is fundamental to clearly distinguish scope values >>>>> (standardized, static) and resource server addresses >>>>> (deployment specific) and to manage their relationships. The >>>>> current scope definition is much to weak and insufficient. >>>>> Probably, the UMA concepts of hosts, resources sets, and >>>>> corresponding scopes could be adopted for that purpose. >>>>> >>>>> OAuth today requires clients to register with the service >>>>> provider before they are deployed. Would you really expect >>>>> IMAP clients, e.g. Thunderbird, to register with any a-Mail >>>>> services upfront? So clients should be given a way to register >>>>> dynamically to the authorization servers. This should also >>>>> allow us to cover "client instance" aspects. It is interesting >>>>> to note, that such a mechanism would allow us to get rid of >>>>> secret-less clients and the one-time usage requirement for >>>>> authorization codes. >>>>> >>>>> We also assume the client to know the URLs of the resource >>>>> server and the corresponding authorization server and to use >>>>> HTTPS server authentication to verify the resource server's >>>>> authenticity. This is impossible in the standard scenario. >>>>> Clients must be able to discover the authorization server a >>>>> particular resource server relies on at runtime. The discovery >>>>> mechanism could be specified by the OAuth WG, but could also >>>>> be part of an application protocols specification. But we MUST >>>>> find another way to prevent token phishing by counterfeit >>>>> resource servers. >>>>> >>>>> As one approach, the client could pass the (previously HTTPS >>>>> validated) resource server's URL with the authorization >>>>> request. The authorization server should then refuse such >>>>> requests for any unknown (counterfeit) resource servers. Such >>>>> an additional parameter could also serve as namespace for >>>>> scope values and enable service providers to run multiple >>>>> instances of the same service within a single deployment. >>>>> >>>>> If the additional data enlarges the request payload to much, >>>>> we could consider to adopt the "request by reference" proposal. >>>>> >>>>> Let's now assume, OAuth is successful in the world of standard >>>>> protocols and we will see plenty of deployments with a bunch >>>>> of different OAuth protected resource servers. Shall this >>>>> servers all be accessible with a single token? In my opinion, >>>>> this would cause security, privacy and/or >>>>> scalability/performance problems. To give just the most >>>>> obvious example, the target audience of such a token cannot be >>>>> restricted enough, which may allow a resource server (or an >>>>> attacker in control of it) to abuse the token on other >>>>> servers. But the current design of the code grant type forces >>>>> deployments to use the same token for all services. What is >>>>> needed from my point of view is a way to request and issue >>>>> multiple server-specific access tokens with a single >>>>> authorization process. >>>>> >>>>> I've been advocating this topic for a long time now and I'm >>>>> still convinced this is required to really complete the core >>>>> design. We at Deutsche Telekom needed and implemented this >>>>> function on top of the existing core. In my opinion, a core >>>>> enhancement would be easier to handle and more powerful. If >>>>> others support this topic, I would be willed to submit an I-D >>>>> describing a possible solution. >>>>> >>>>> If we take standards really seriously, then service providers >>>>> should be given the opportunity to implement their service by >>>>> utilizing standard server implementations. This creates the >>>>> challenge to find a standardized protocol between >>>>> authorization server and resource server to exchange >>>>> authorization data. Depending on the token design >>>>> (self-contained vs. handle) this could be solved by either >>>>> standardizing a token format (JWT) or an authorization API. >>>>> >>>>> Based on the rationale given above, my list is as follows >>>>> (topics w/o I-D are marked with *): >>>>> >>>>> - Revocation (low hanging fruit since I-D is ready and >>>>> implemented in some places) >>>>> - Resource server notion* >>>>> - Multiple access tokens* >>>>> - Dynamic client registration >>>>> >>>>> 1) Dynamic Client Registration Protocol >>>>> 4) Client Instance Extension >>>>> - Discovery >>>>> (10) Simple Web Discovery, probably other specs as well >>>>> - (6) JSON Web Token >>>>> - (7) JSON Web Token (JWT) Bearer Profile >>>>> - 8) User Experience Extension >>>>> - Device flow >>>>> - 9) Request by Reference >>>>> (depending resource server notion and multiple access tokens) >>>>> >>>>> regards, >>>>> Torsten. >>>>> Zitat von Hannes Tschofenig >>>> >: >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> in preparation of the upcoming IETF meeting Barry and I >>>>> would like to start a re-chartering discussion. We both >>>>> are currently attending the Internet Identity Workshop and >>>>> so we had the chance to solicit input from the >>>>> participants. This should serve as a discussion starter. >>>>> >>>>> Potential future OAuth charter items (in random order): >>>>> >>>>> ---------------- >>>>> >>>>> 1) Dynamic Client Registration Protocol >>>>> >>>>> Available document: >>>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>>>> >>>>> 2) Token Revocation >>>>> >>>>> Available document: >>>>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>>>> >>>>> 3) UMA >>>>> >>>>> Available document: >>>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>>>> >>>>> 4) Client Instance Extension >>>>> >>>>> Available document: >>>>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>>>> >>>>> 5) XML Encoding >>>>> >>>>> Available document: >>>>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>>>> >>>>> 6) JSON Web Token >>>>> >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>>>> >>>>> 7) JSON Web Token (JWT) Bearer Profile >>>>> >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>>>> >>>>> 8) User Experience Extension >>>>> >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>>>> >>>>> 9) Request by Reference >>>>> >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>>>> >>>>> 10) Simple Web Discovery >>>>> >>>>> Available document: >>>>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>>>> >>>>> ---------------- >>>>> >>>>> We have the following questions: >>>>> >>>>> a) Are you interested in any of the above-listed items? >>>>> (as a reviewer, co-author, implementer, or someone who >>>>> would like to deploy). It is also useful to know if you >>>>> think that we shouldn't work on a specific item. >>>>> >>>>> b) Are there other items you would like to see the group >>>>> working on? >>>>> >>>>> Note: In case your document is expired please re-submit it. >>>>> >>>>> Ciao >>>>> Hannes & Barry >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nat Sakimura (=nat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> >>>> _______________________________________________ >>>> 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 --------------070007050806090508000806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The main reason to include the OAuth parameters in the request is to ensure that the request object was not modified in transit since the JSON request object can be signed. Agreed that it would be simpler if OAuth adopted the JSON request style.

Thanks,
George

On 10/27/11 1:33 PM, torsten@lodderstedt.net wrote:
Hi John,

why do you need to include the OAuth request parameters into the JSON document? I would expect OpenId Connect to extend OAuth none-intrusively. This would mean to use the JSON document for OpenId connect specific parameters only. Alternatively, the JSON request style could be adopted as part of OAuth. Then, the URI request parameters could be omitted.

regards,
Torsten.

Gesendet mit BlackBerry® Webmail von Telekom Deutschland

From: John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 27 Oct 2011 13:52:31 -0300
To: Torsten Lodderstedt<torsten@lodderstedt.net>
Cc: Nat Sakimura<sakimura@gmail.com>; OAuth WG<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Rechartering JSON based request.

Hopefully to make it more compatible with existing OAuth 2 libraries.    At least leave open the possibility of dealing with it at a higher level.

The argument has been made that you probably need to modify the library anyway to check that the duplicate parameters are a match.

If there is consensus that the parameters should only be in the JSON then we would happily not duplicate them.

It is mostly a case of trying to fit in to the existing OAuth work and libraries.

John B.

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:

why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in openID Connect to make signed requests to the Authorization server.

We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension.

Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on.

Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:

Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi. 

Just a clarification: 

Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and  resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

 1) Dynamic Client Registration Protocol
 4) Client Instance Extension
- Discovery
 (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
 (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@gmx.net>:


Hi all,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion.  We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/

2) Token Revocation

Available document:
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

3) UMA

Available document:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

9) Request by Reference

Available document:
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00

10) Simple Web Discovery

Available document:
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00

----------------

We have the following questions:

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
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

--------------070007050806090508000806-- From internet-drafts@ietf.org Thu Oct 27 14:00:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947D821F8BF3; Thu, 27 Oct 2011 14:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDqaSnX8DaOD; Thu, 27 Oct 2011 14:00:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0E21F8BE5; Thu, 27 Oct 2011 14:00:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111027210029.27578.27106.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2011 14:00:29 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 21:00:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-12.txt Pages : 19 Date : 2011-10-27 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get ac= cess to granted resources (without demonstrating possession of a cryptographic key). To prevent misuse, the bearer token needs to be protected from disclosure in storage and in transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.txt From Michael.Jones@microsoft.com Thu Oct 27 14:02:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB4221F8C1F for ; Thu, 27 Oct 2011 14:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lm40VztZwHw for ; Thu, 27 Oct 2011 14:02:00 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0176721F8C1D for ; Thu, 27 Oct 2011 14:01:59 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 27 Oct 2011 14:01:59 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.67]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0339.002; Thu, 27 Oct 2011 14:01:59 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -12 Thread-Index: AcyU66qSzDJUwdoTThu6TkX2zYOiZA== Date: Thu, 27 Oct 2011 21:01:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F6C0AA9@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F6C0AA9TK5EX14MBXC283r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 21:02:01 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F6C0AA9TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 12 of the OAuth 2.0 Bearer Token Specification has been published. I believe that= the chairs will be submitting this version to the IESG. It contains the f= ollowing changes: * Made non-normative editorial changes that Hannes Tschofenig requested= be applied prior to forwarding the specification to the IESG. * Added rationale for the choice of the b64token syntax. * Added rationale stating that receivers are free to parse the scope at= tribute using a standard quoted-string parser, since it will correctly proc= ess all legal scope values. * Added additional active working group contributors to the Acknowledge= ments section. The draft is available at these locations: * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-12 * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12= .pdf * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12= .txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12= .xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.pdf * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (wil= l point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will= point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will= point to new versions as they are posted) * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will= point to new versions as they are posted) * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion= repository, with html, pdf, txt, and html versions available) -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435F6C0AA9TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 12 of the OAuth 2.0 Bearer Token Specification has been published.  I believ= e that the chairs will be submitting this version to the IESG.  It con= tains the following changes:

  • Made non-normative editorial changes that Hannes T= schofenig requested be applied prior to forwarding the specification to the= IESG.
  • Added rationale for the choice of the b64token syn= tax.
  • Added rationale stating that receivers are free to= parse the scope attribute = using a standard quoted-string parser, since it will correctly process all legal scope values.
  • Added additional active working group contributors= to the Acknowledgements section.

 

The draft is available at these locations:

·         http://tools.ietf.org/html/draft-ietf-oauth-v2-bea= rer-12

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-12.pdf

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-12.txt

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-12.xml

·         http://self-issued.info/docs/draft-ietf-oau= th-v2-bearer-12.html

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-12.pdf

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-12.txt

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-12.xml

·         http://self-issued.info/docs/draft-ietf-oauth-= v2-bearer.html (will point to new versions as they are posted)

·         http://self-issued.info/docs/draft-ietf-oauth-v= 2-bearer.pdf (will point to new versions as they are posted)=

·         http://self-issued.info/docs/draft-ietf-oauth-v= 2-bearer.txt (will point to new versions as they are posted)=

·         http://self-issued.info/docs/draft-ietf-oauth-v= 2-bearer.xml (will point to new versions as they are posted)=

·         http://svn.openid.net/repos/specifications/oauth/2.0/= (Subversion repository, with html, pdf, txt, and html versions availab= le)

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435F6C0AA9TK5EX14MBXC283r_-- From hannes.tschofenig@gmx.net Thu Oct 27 14:21:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68CE11E807F for ; Thu, 27 Oct 2011 14:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlLSYEIs3lSd for ; Thu, 27 Oct 2011 14:21:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C8F1111E8073 for ; Thu, 27 Oct 2011 14:21:49 -0700 (PDT) Received: (qmail invoked by alias); 27 Oct 2011 21:21:48 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp015) with SMTP; 27 Oct 2011 23:21:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18w3ug8O0swSvWetz08WmB/jZbCFZ2BJyRznLrYlx Os+DbeptC3XxVu Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F6C0AA9@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 28 Oct 2011 00:21:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739435F6C0AA9@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 21:21:55 -0000 Thank you Mike for your work on the specification and to get the = feedback incorporated before the deadline.=20 On Oct 28, 2011, at 12:01 AM, Mike Jones wrote: > Draft 12 of the OAuth 2.0 Bearer Token Specification has been = published. I believe that the chairs will be submitting this version to = the IESG. It contains the following changes: > =95 Made non-normative editorial changes that Hannes Tschofenig = requested be applied prior to forwarding the specification to the IESG. > =95 Added rationale for the choice of the b64token syntax. > =95 Added rationale stating that receivers are free to parse the = scope attribute using a standard quoted-string parser, since it will = correctly process all legal scopevalues. > =95 Added additional active working group contributors to the = Acknowledgements section. > =20 > The draft is available at these locations: > =B7 http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-12 > =B7 = http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.pdf > =B7 = http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.txt > =B7 = http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.xml > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.html > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.pdf > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.txt > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.xml > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point = to new versions as they are posted) > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will point = to new versions as they are posted) > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point = to new versions as they are posted) > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point = to new versions as they are posted) > =B7 http://svn.openid.net/repos/specifications/oauth/2.0/ = (Subversion repository, with html, pdf, txt, and html versions = available) > =20 > -- = Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Oct 27 16:31:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C9621F869E for ; Thu, 27 Oct 2011 16:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5ZEaDqQi5xF for ; Thu, 27 Oct 2011 16:31:03 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6619821F8696 for ; Thu, 27 Oct 2011 16:31:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,415,1315144800"; d="scan'208";a="50075321" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 28 Oct 2011 10:31:00 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6512"; a="40968704" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbni.tcif.telstra.com.au with ESMTP; 28 Oct 2011 10:31:01 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Fri, 28 Oct 2011 10:31:00 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 28 Oct 2011 10:30:59 +1100 Thread-Topic: draft-ietf-oauth-v2-bearer-12: ABNF nits Thread-Index: AcyU653GUF8nQMxSTqWkL0JYJmCbawADmclw Message-ID: <255B9BB34FB7D647A506DC292726F6E11290D1BC70@WSMSG3153V.srv.dir.telstra.com> References: <20111027210029.27578.27106.idtracker@ietfa.amsl.com> In-Reply-To: <20111027210029.27578.27106.idtracker@ietfa.amsl.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-12: ABNF nits X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 23:31:04 -0000 The value should just be . The current ABNF implies you can include raw (unescaped) " and \ characters= in the value (as they are chars in ) - but that breaks parsing. If the intention was not to allow senders to use escapes then needs to be <%x20-%x21 / %x23-5B / %x5D-7E>. If that is the intention = why not disallow escapes from as well? Section 3 "The WWW-Authenticate Response Header Field" OLD: error-desc =3D "error_description" "=3D" DQUOTE *error-desc-char DQUOT= E error-desc-char =3D SP / VCHAR NEW: error-desc =3D "error_description" "=3D" quoted-string The note about being allowed to parse with a quoted-string parser s= hould also apply to and as well. Perhaps a better approach is to: defined , , , an= d values as ; add text saying senders MUST NOT u= se quoted-string's escape mechanism (so " and \ cannot appear in the values= ), though receivers MAY use a standard quoted-string parser; say the value must match ; say the value is a list of = space-delimited, case sensitive strings. NEW: scope =3D "scope" "=3D" quoted-string error =3D "error" "=3D" quoted-string error-desc =3D "error_description" "=3D" quoted-string error-uri =3D "error_uri" "=3D" quoted-string Senders MUST NOT use the quoted-string escape mechanism for "scope", "error", "error_description", or "error_uri" values. That is, those values cannot include " or \. Receivers MAY use a standard quoted-string parser, and hence accept some values that are not allowed to be sent. An "error_uri" value MUST match the URI-reference rule from [RFC3986]. The "scope" value is a list of space-delimited, case sensitive strings. ... P.S. trivial typo: "URI-Reference" should be "URI-reference" in =A71.1. -- James Manger From sakimura@gmail.com Thu Oct 27 17:28:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB0D11E8099 for ; Thu, 27 Oct 2011 17:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR6q2SbGaroZ for ; Thu, 27 Oct 2011 17:28:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5807311E808F for ; Thu, 27 Oct 2011 17:28:15 -0700 (PDT) Received: by faas12 with SMTP id s12so3650793faa.31 for ; Thu, 27 Oct 2011 17:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3hKdfbHK39CG6IabwMuiBujrFYLGO3Z1NqAvNmzJW6I=; b=v6Mu97W0kjkl7JvKRvwz6HW7XYpfirKt4eE2WtCgbVFyqUGU8L7wY019eS654yHGSG 2SltKSXezeysIPtrOf5sPn7OCLAIkDPGstMhagZGd2nwebqg/kHwHLK41PkPPB1Z1P/s BL9FuQcvrEf5e0IbU/ekQnPbxoviR947ik050= MIME-Version: 1.0 Received: by 10.223.39.20 with SMTP id d20mr1770219fae.37.1319761693218; Thu, 27 Oct 2011 17:28:13 -0700 (PDT) Received: by 10.152.37.201 with HTTP; Thu, 27 Oct 2011 17:28:13 -0700 (PDT) In-Reply-To: <4EA9BE04.9060607@aol.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <4EA84E97.3020708@lodderstedt.net> <4EA8EA99.4010203@lodderstedt.net> <502551594-1319736794-cardhu_decombobulator_blackberry.rim.net-779525061-@b28.c11.bise7.blackberry> <4EA9BE04.9060607@aol.com> Date: Fri, 28 Oct 2011 09:28:13 +0900 Message-ID: From: Nat Sakimura To: OAuth WG Content-Type: multipart/alternative; boundary=00151747914ee9969e04b050f646 Subject: Re: [OAUTH-WG] Rechartering JSON based request. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 00:28:18 -0000 --00151747914ee9969e04b050f646 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks George. Just to clarify the intent of this I-D : this I-D proposes the JSON request style to be adopted as part of OAuth so that the URI request parameters could be omitted. =3Dnat On Fri, Oct 28, 2011 at 5:24 AM, George Fletcher wrote: > The main reason to include the OAuth parameters in the request is to > ensure that the request object was not modified in transit since the JSON > request object can be signed. Agreed that it would be simpler if OAuth > adopted the JSON request style. > > Thanks, > George > > On 10/27/11 1:33 PM, torsten@lodderstedt.net wrote: > > Hi John, > > why do you need to include the OAuth request parameters into the JSON > document? I would expect OpenId Connect to extend OAuth none-intrusively. > This would mean to use the JSON document for OpenId connect specific > parameters only. Alternatively, the JSON request style could be adopted a= s > part of OAuth. Then, the URI request parameters could be omitted. > > regards, > Torsten. > > Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland > ------------------------------ > *From: * John Bradley > *Date: *Thu, 27 Oct 2011 13:52:31 -0300 > *To: *Torsten Lodderstedt > *Cc: *Nat Sakimura ; OAuth WG > > *Subject: *Re: [OAUTH-WG] Rechartering JSON based request. > > Hopefully to make it more compatible with existing OAuth 2 libraries. > At least leave open the possibility of dealing with it at a higher level= . > > The argument has been made that you probably need to modify the library > anyway to check that the duplicate parameters are a match. > > If there is consensus that the parameters should only be in the JSON the= n > we would happily not duplicate them. > > It is mostly a case of trying to fit in to the existing OAuth work and > libraries. > > John B. > > On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: > > why is it neccessary to duplicate the OAuth request parameters? > > Am 27.10.2011 00:31, schrieb John Bradley: > > Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. > > It is essentially a standardization of the method we are using in openI= D > Connect to make signed requests to the Authorization server. > > We do have the issue that parameters in the signed/encrypted request > necessarily duplicate the query parameters to keep it a valid OAuth reque= st > plus an extension. > > Even if it doesn't wind up as a OAuth WG item it is probably worth peopl= e > looking at it before the final openID spec is voted on. > > Regards > John B. > > On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: > > Hi Nat, > > I think your proposal would be a useful OAuth enhancement. A JSON-based > request format would allow for more complex requests (e.g. carrying resou= rce > server URLs and corresponding scope values ;-)). > > Please note: I also think the way this mechanism is introduced and used i= n > the current OpenID connect spec requires OpenID connect clients and serve= rs > to handle OAuth request parameters differently than for standard OAuth > requests. Introducing the JSON based claim request capability to OAuth wo= uld > be a way to cope with this. > > regards, > Torsten. > > Am 22.10.2011 16:00, schrieb Nat Sakimura: > > Hi. > > Just a clarification: > > Although my expired draft is 'request by reference', what was proposed > through it at the iiw really is a generalized JSON based claim request > capability. It could be passed by value as JSON or could be passed by > reference. The later is an optimization for bandwidth constrained network= as > well as strengthening security in some ways. This capability already exis= ts > in OpenID Connect but it is actually an underpinning transport, so it > probably should belong to OAuth instead. This was the primary reason for = the > proposal. > > Nat > > On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi all, >> >> my prioritization is driven by the goal to make OAuth the authorization >> framework of choice for any internet standard protocol, such as WebDAV, >> IMAP, SMTP or SIP. So let me first explain what is missing from my point= of >> view and explain some thoughts how to fill the gaps. >> >> A standard protocol is defined in terms of resource types and messages b= y >> a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, a= nd >> used by different but deployment-independent clients. OAuth-based protoc= ol >> specifications must also define scope values (e.g. read, write, send) an= d >> their relation to the resource types and messages. The different deploym= ents >> expose the standard protocol on different resource server endpoints. In = my >> opinion, it is fundamental to clearly distinguish scope values >> (standardized, static) and resource server addresses (deployment specif= ic) >> and to manage their relationships. The current scope definition is much = to >> weak and insufficient. Probably, the UMA concepts of hosts, resources se= ts, >> and corresponding scopes could be adopted for that purpose. >> >> OAuth today requires clients to register with the service provider befor= e >> they are deployed. Would you really expect IMAP clients, e.g. Thunderbir= d, >> to register with any a-Mail services upfront? So clients should be given= a >> way to register dynamically to the authorization servers. This should al= so >> allow us to cover "client instance" aspects. It is interesting to note, = that >> such a mechanism would allow us to get rid of secret-less clients and th= e >> one-time usage requirement for authorization codes. >> >> We also assume the client to know the URLs of the resource server and th= e >> corresponding authorization server and to use HTTPS server authenticatio= n to >> verify the resource server's authenticity. This is impossible in the >> standard scenario. Clients must be able to discover the authorization se= rver >> a particular resource server relies on at runtime. The discovery mechani= sm >> could be specified by the OAuth WG, but could also be part of an applica= tion >> protocols specification. But we MUST find another way to prevent token >> phishing by counterfeit resource servers. >> >> As one approach, the client could pass the (previously HTTPS validated) >> resource server's URL with the authorization request. The authorization >> server should then refuse such requests for any unknown (counterfeit) >> resource servers. Such an additional parameter could also serve as names= pace >> for scope values and enable service providers to run multiple instances = of >> the same service within a single deployment. >> >> If the additional data enlarges the request payload to much, we could >> consider to adopt the "request by reference" proposal. >> >> Let's now assume, OAuth is successful in the world of standard protocols >> and we will see plenty of deployments with a bunch of different OAuth >> protected resource servers. Shall this servers all be accessible with a >> single token? In my opinion, this would cause security, privacy and/or >> scalability/performance problems. To give just the most obvious example,= the >> target audience of such a token cannot be restricted enough, which may a= llow >> a resource server (or an attacker in control of it) to abuse the token o= n >> other servers. But the current design of the code grant type forces >> deployments to use the same token for all services. What is needed from = my >> point of view is a way to request and issue multiple server-specific acc= ess >> tokens with a single authorization process. >> >> I've been advocating this topic for a long time now and I'm still >> convinced this is required to really complete the core design. We at >> Deutsche Telekom needed and implemented this function on top of the exis= ting >> core. In my opinion, a core enhancement would be easier to handle and mo= re >> powerful. If others support this topic, I would be willed to submit an I= -D >> describing a possible solution. >> >> If we take standards really seriously, then service providers should be >> given the opportunity to implement their service by utilizing standard >> server implementations. This creates the challenge to find a standardize= d >> protocol between authorization server and resource server to exchange >> authorization data. Depending on the token design (self-contained vs. >> handle) this could be solved by either standardizing a token format (JWT= ) or >> an authorization API. >> >> Based on the rationale given above, my list is as follows (topics w/o I-= D >> are marked with *): >> >> - Revocation (low hanging fruit since I-D is ready and implemented in so= me >> places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >> >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >> >> regards, >> Torsten. >> Zitat von Hannes Tschofenig : >> >> >> Hi all, >>> >>> in preparation of the upcoming IETF meeting Barry and I would like to >>> start a re-chartering discussion. We both are currently attending the >>> Internet Identity Workshop and so we had the chance to solicit input fr= om >>> the participants. This should serve as a discussion starter. >>> >>> Potential future OAuth charter items (in random order): >>> >>> ---------------- >>> >>> 1) Dynamic Client Registration Protocol >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>> >>> 2) Token Revocation >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>> >>> 3) UMA >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>> >>> 4) Client Instance Extension >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>> >>> 5) XML Encoding >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>> >>> 6) JSON Web Token >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>> >>> 7) JSON Web Token (JWT) Bearer Profile >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>> >>> 8) User Experience Extension >>> >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>> >>> 9) Request by Reference >>> >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>> >>> 10) Simple Web Discovery >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>> >>> ---------------- >>> >>> We have the following questions: >>> >>> a) Are you interested in any of the above-listed items? (as a reviewer, >>> co-author, implementer, or someone who would like to deploy). It is als= o >>> useful to know if you think that we shouldn't work on a specific item. >>> >>> b) Are there other items you would like to see the group working on? >>> >>> Note: In case your document is expired please re-submit it. >>> >>> Ciao >>> Hannes & Barry >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --00151747914ee9969e04b050f646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks George.=A0

Just to clarify the intent = of this I-D : this I-D proposes=A0the JSON request style to be adopted as p= art of OAuth so that the URI request parameters could be omitted.

=3Dnat

On Fri, Oct 28, 201= 1 at 5:24 AM, George Fletcher <gffletch@aol.com> wrote:
=20 =20 =20
The main reason to include the OAuth parameters in the request is to ensure that the request object was not modified in transit since the JSON request object can be signed. Agreed that it would be simpler if OAuth adopted the JSON request style.

Thanks,
George

On 10/27/11 1:33 PM, torsten@lodderstedt.net wrote:
Hi John,

why do you need to include the OAuth request parameters into the JSON document? I would expect OpenId Connect to extend OAuth none-intrusively. This would mean to use the JSON document for OpenId connect specific parameters only. Alternatively, the JSON request style could be adopted as part of OAuth. Then, the URI request parameters could be omitted.

regards,
Torsten.

Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland

From: John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 27 Oct 2011 13:52:31 -0300
To: Torsten Lodderstedt<torsten@lodderstedt.net>
Cc: Nat Sakimura<sakimura@gmail.com>; OAuth WG<oauth@iet= f.org>
Subject: Re: [OAUTH-WG] Rechartering JSON based request.

Hopefully to make it more compatible with existing OAuth 2 libraries. =A0 =A0At least leave open the possibility of dealing with it at a higher level.

The argument has been made that you probably need to modify the library anyway to check that the duplicate parameters are a match.

If there is consensus that the parameters should only be in the JSON then we would happily not duplicate them.

It is mostly a case of trying to fit in to the existing OAuth work and libraries.

John B.

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:

=20
why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:
Nat and I just refreshed the I-D for=A0draft-sakimura-oauth-requrl.

It is essentially =A0a standardization of the method we are using in openID Connect to make signed requests to the Authorization server.

We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension.

Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on.

Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:

=20
Hi Nat,<= br>
I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi.=A0

Just a clarification:=A0

Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal.=A0

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and =A0resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects= . It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.

We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.

As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.

If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.

I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration

=A01) Dynamic Client Registration Protocol
=A04) Client Instance Extension
- Discovery
=A0(10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
=A0(depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <hannes.tschofenig@g= mx.net>:


Hi al= l,

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion. =A0We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter.

Potential future OAuth charter items (in random order):

----------------

1) Dynamic Client Registration Protocol

Available document:
http://datatracker.= ietf.org/doc/draft-hardjono-oauth-dynreg/

2) Token Revocation

Available document:
http://datat= racker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

3) UMA

Available document:
http://datatracker= .ietf.org/doc/draft-hardjono-oauth-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.or= g/id/draft-richer-oauth-instance-00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/= draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/h= tml/draft-jones-json-web-token-05

7) JSON Web Token (JWT) Bearer Profile

Available document:
http://tools.ietf.org= /html/draft-jones-oauth-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/h= tml/draft-recordon-oauth-v2-ux-00

9) Request by Reference

Available document:
http://tools.ietf.org/= html/draft-sakimura-oauth-requrl-00

10) Simple Web Discovery

Available document:
http://tools.ietf= .org/html/draft-jones-simple-web-discovery-00

----------------

We have the following questions:
a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item.

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it.

Ciao
Hannes & Barry

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth



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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

 



_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
--00151747914ee9969e04b050f646-- From Hannes.Tschofenig@gmx.net Thu Oct 27 23:36:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9B711E809D for ; Thu, 27 Oct 2011 23:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.493 X-Spam-Level: X-Spam-Status: No, score=-100.493 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnVOo7lBeXx3 for ; Thu, 27 Oct 2011 23:36:08 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2CB5411E8099 for ; Thu, 27 Oct 2011 23:36:08 -0700 (PDT) Received: (qmail invoked by alias); 28 Oct 2011 06:36:06 -0000 Received: from unknown (EHLO [10.255.131.15]) [192.100.123.77] by mail.gmx.net (mp013) with SMTP; 28 Oct 2011 08:36:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181nXoJrf01Gb7U+eq+2PtUl3LUM+l0Q7xeEQNf5K 0Ls6nFGisvV96C From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Oct 2011 09:36:02 +0300 Message-Id: <03E302FD-3A01-4363-BF14-BBE6EB9B2AF1@gmx.net> To: Stephen Farrell Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: [OAUTH-WG] Publication requested for draft-ietf-oauth-v2-bearer-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 06:36:09 -0000 Hi Stephen, the OAuth working group requests publication of = draft-ietf-oauth-v2-bearer-12 as Proposed Standard. Here is the write-up for the document. ------------------------------------------- Document Shepherd Write-Up for draft-ietf-oauth-v2-bearer-12 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 The document shepherd is Hannes Tschofenig. I have personally reviewed = the=20 document and I think it is ready for going forward.=20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 The document received a number of reviews from the working group but = also=20 from members outside the working group, including security reviews. =20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 The document was reviewed by Julian Reschke for HTTP related content.=20 Changes to the document have been made in response to his review. There is still disagreement between Julian and working=20 group members regarding two issues concerning encoding. While the=20 shepherd feels comfortable going forward with the specification to the IESG wider IETF review may provide additional feedback. One issue is related to the encoding of the scope attribute in context=20= of HTTP authentication parameters: https://www.ietf.org/mail-archive/web/oauth/current/msg07733.html https://www.ietf.org/mail-archive/web/oauth/current/msg07734.html https://www.ietf.org/mail-archive/web/oauth/current/msg07739.html The other comment by Julian is related to the form encoding, as=20 described here:=20 https://www.ietf.org/mail-archive/web/oauth/current/msg07731.html (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20= has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 I have no concerns regarding this document but would like to appreciate feedback from the wider IETF community on the issues raised under=20 item 1.c. =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 =20 There solid consensus behind this document from the working group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20= discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 =20 Nobody had shown extreme discontent.=20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts = Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20= not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 I have verified the document. The idnits tool gives a warning about the RFC 2119 boilerplate, and that warning is incorrect. (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 The references are split into normative and informative references. =20 There is one downref to RFC 2818.=20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 I have reviewed the IANA consideration section.=20 The documents adds new values into an existing registry.=20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 The ABNF in the document was verified with=20 http://trac.tools.ietf.org/wg/httpbis/trac/browser/abnfparser/bap (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to granted resources (without demonstrating possession of a cryptographic key). To prevent misuse, the bearer token MUST be protected from disclosure in storage and in transport. =20 Working Group Summary=20 The working group decided to develop two types of mechanisms for=20 a client to access a protected resource. The second specification=20 is being worked on with draft-ietf-oauth-v2-http-mac-00. The=20 two specifications offer different security properties to allow deployments to meet their specific needs.=20 =20 Document Quality=20 =20 This specification is implemented, deployed and used by Microsoft=20 Access Control Service (ACS), Google Apps, Facebook Connect and the=20= Graph API, Salesforce, Mitre, and many others.=20 =20 Source code is available as well. For example=20 http://static.springsource.org/spring-security/oauth/ http://incubator.apache.org/projects/amber.html https://github.com/nov/rack-oauth2 + many more, including those listed at=20 https://github.com/teohm/teohm.github.com/wiki/OAuth=20 =20 ------------------------------------------- Ciao Hannes From julian.reschke@gmx.de Fri Oct 28 01:59:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38B21F8AAF for ; Fri, 28 Oct 2011 01:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.496 X-Spam-Level: X-Spam-Status: No, score=-104.496 tagged_above=-999 required=5 tests=[AWL=-1.897, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKfspFGDwjX4 for ; Fri, 28 Oct 2011 01:59:13 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 190C721F8A91 for ; Fri, 28 Oct 2011 01:59:12 -0700 (PDT) Received: (qmail invoked by alias); 28 Oct 2011 08:59:10 -0000 Received: from p5DCC2E74.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.46.116] by mail.gmx.net (mp035) with SMTP; 28 Oct 2011 10:59:10 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Vxdsg1ZJVkVyweOy7StR49VYvknAN8UeBuE2+18 YrlFPhysTGfSIX Message-ID: <4EAA6ED8.8000502@gmx.de> Date: Fri, 28 Oct 2011 10:59:04 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <20111027210029.27578.27106.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E11290D1BC70@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11290D1BC70@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-12: ABNF nits X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 08:59:14 -0000 On 2011-10-28 01:30, Manger, James H wrote: > ... > Perhaps a better approach is to: defined,,, and values as; add text saying senders MUST NOT use quoted-string's escape mechanism (so " and \ cannot appear in the values), though receivers MAY use a standard quoted-string parser; say the value must match; say the value is a list of space-delimited, case sensitive strings. > ... This goes into the right direction. I would also allow both token and quoted-string, because it seems to be totally pointless to forbid it. (I'll send a longer summary about open issues soonish)) Best regards, Julian From julian.reschke@gmx.de Fri Oct 28 02:03:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96B721F8B07 for ; Fri, 28 Oct 2011 02:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.448 X-Spam-Level: X-Spam-Status: No, score=-104.448 tagged_above=-999 required=5 tests=[AWL=-1.849, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOdfCNhkMWbt for ; Fri, 28 Oct 2011 02:03:47 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0AB7321F8AC3 for ; Fri, 28 Oct 2011 02:03:46 -0700 (PDT) Received: (qmail invoked by alias); 28 Oct 2011 09:03:45 -0000 Received: from p5DCC2E74.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.46.116] by mail.gmx.net (mp072) with SMTP; 28 Oct 2011 11:03:45 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19ncD4hRElnmCUJYfWhlDIndkx4+2fLSQ92oDYE4m CixnIp0UG6ty0W Message-ID: <4EAA6FEE.1060102@gmx.de> Date: Fri, 28 Oct 2011 11:03:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 09:03:48 -0000 On 2011-10-17 20:53, Eran Hammer-Lahav wrote: > All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever. > ... I noticed that this hasn't been done yet, but the bearer spec, for which publication was just requested, kind of assumes it *will* be done. Are mechanisms in place to ensure that this change indeed happens? Best regards, Julian From Michael.Jones@microsoft.com Fri Oct 28 07:10:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8221F8562 for ; Fri, 28 Oct 2011 07:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gsk42vvWAKf8 for ; Fri, 28 Oct 2011 07:10:12 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBF821F87C5 for ; Fri, 28 Oct 2011 07:10:12 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Oct 2011 07:10:12 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.67]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Fri, 28 Oct 2011 07:10:11 -0700 From: Mike Jones To: Julian Reschke , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions Thread-Index: AQHMjQBSCsL7rbLqiU2pIlDOpUqA/pWR/FIA///f9tA= Date: Fri, 28 Oct 2011 14:10:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F6C2203@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C23C5A6@TK5EX14MBXC284.redmond.corp.microsoft.com><89BE3D9D-AB1D-44B2-BA7D-0C0D74BCA885@gmx.net> <4E1F6AAD24975D4BA5B16804296739435C23CC9D@TK5EX14MBXC284.redmond.corp.microsoft.com> <999913AB42CC9341B05A99BBF358718DAABC44@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739435C23EA6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9AB561.5060904@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C23F5B6@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E9B1BA6.2060704@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723452604B908A@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <9E5660BC-C797-454B-B2AF-48AB3E886AC7@ve7jtb.com> <62D2DE5D-AEBE-4A75-9C36-7A51E63DC7C3@ve7jtb.com> <90C41DD21FB7C64BB94121FBBC2E723452604B9102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4DF35A25-989C-4BE4-8ACD-3520DDB8BDE9@gmx.net> <90C41DD21FB7C64BB94121FBBC2E723452604B9197@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4EAA6FEE.1060102@gmx.de> In-Reply-To: <4EAA6FEE.1060102@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:10:15 -0000 Yes, this change is tracked in the issue tracker as issue #27: Incorporate = bearer "scope" character restrictions into the base spec. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Friday, October 28, 2011 2:04 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Propos= ed Resolutions On 2011-10-17 20:53, Eran Hammer-Lahav wrote: > All I agree with is to limit the scope character-set in the v2 spec to th= e subset of ASCII allowed in HTTP header quoted-string, excluding " and \ s= o no escaping is needed, ever. > ... I noticed that this hasn't been done yet, but the bearer spec, for which pu= blication was just requested, kind of assumes it *will* be done. Are mechanisms in place to ensure that this change indeed happens? Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Fri Oct 28 10:22:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7364221F8888; Fri, 28 Oct 2011 10:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3CK+wQmI5l5; Fri, 28 Oct 2011 10:22:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127C721F85A1; Fri, 28 Oct 2011 10:22:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111028172247.3232.30822.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2011 10:22:47 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:22:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-09.txt Pages : 16 Date : 2011-10-28 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-09.txt From bcampbell@pingidentity.com Fri Oct 28 11:26:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1621F8A4E for ; Fri, 28 Oct 2011 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3Cmk+QSHbzf for ; Fri, 28 Oct 2011 11:26:39 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8E821F8888 for ; Fri, 28 Oct 2011 11:26:38 -0700 (PDT) Received: from mail-yw0-f44.google.com ([209.85.213.44]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP; Fri, 28 Oct 2011 11:26:39 PDT Received: by mail-yw0-f44.google.com with SMTP id 2so4612639ywt.31 for ; Fri, 28 Oct 2011 11:26:31 -0700 (PDT) Received: by 10.147.5.22 with SMTP id h22mr880546yai.0.1319826391165; Fri, 28 Oct 2011 11:26:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.96.19 with HTTP; Fri, 28 Oct 2011 11:26:00 -0700 (PDT) In-Reply-To: <20111028172247.3232.30822.idtracker@ietfa.amsl.com> References: <20111028172247.3232.30822.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 28 Oct 2011 12:26:00 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-saml2-bearer-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 18:26:40 -0000 I posted a new draft that addresses a potential ambiguity raised by an engineer I work with who is currently implementing against the draft. draft -09 can be found at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-09 and here's the relevant snippet from Appendix B. Document History: draft-ietf-oauth-saml2-bearer-09 o Attempt to address an ambiguity around validation requirements when the Conditions element contain a NotOnOrAfter and SubjectConfirmation/SubjectConfirmationData does too. Basically it needs to have at least one bearer SubjectConfirmation element but that element can omit SubjectConfirmationData, if Conditions has an expiry on it. Otherwise, a valid SubjectConfirmation must have a SubjectConfirmationData with Recipient and NotOnOrAfter. And any SubjectConfirmationData that has those elements needs to have them checked. o clarified that AudienceRestriction is under Conditions (even though it's implied by schema) o fix a typo ---------- Forwarded message ---------- From: Date: Fri, Oct 28, 2011 at 11:22 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-09.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SAML 2.0 Bearer Assertion Profil= es for OAuth 2.0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Chuck Mortimore =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-09.t= xt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 16 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-28 =A0 This specification defines the use of a SAML 2.0 Bearer Assertion as =A0 means for requesting an OAuth 2.0 access token as well as for use as =A0 a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-09.txt _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Fri Oct 28 14:03:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958ED11E8094 for ; Fri, 28 Oct 2011 14:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+ZtuAINnG-9 for ; Fri, 28 Oct 2011 14:03:10 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id E692411E8082 for ; Fri, 28 Oct 2011 14:03:09 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9SL35V9020946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2011 16:03:05 -0500 (CDT) 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 p9SL34rq000703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 Oct 2011 16:03:04 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 28 Oct 2011 16:03:04 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Torsten Lodderstedt'" , "'Bob Van Zant'" Date: Fri, 28 Oct 2011 16:03:02 -0500 Thread-Topic: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering Thread-Index: AcyUEGYvUzoXBus/TU6uV/CiQUiI8QBo3FmQ Message-ID: <5710F82C0E73B04FA559560098BF95B1250BDD1C21@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4EA856DC.9050303@lodderstedt.net> In-Reply-To: <4EA856DC.9050303@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_5710F82C0E73B04FA559560098BF95B1250BDD1C21USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: 'OAuth WG' , 'Dan Taflin' Subject: Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 21:03:13 -0000 --_000_5710F82C0E73B04FA559560098BF95B1250BDD1C21USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Torsten that there is a need for supporting the multiple token= s use case. Such a use case is described in the OAuth 2.0 use cases draft http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.10 Zachary ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= orsten Lodderstedt Sent: Wednesday, October 26, 2011 2:52 PM To: Bob Van Zant Cc: OAuth WG; Dan Taflin Subject: Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering Hi, Am 26.10.2011 05:41, schrieb Bob Van Zant: I'm going to reiterate what has already been said. OAuth already supports what you're trying to do. Just request a token twice= , the first time request it with a scope or scopes that allows these specia= l operations. The second time request it with a scope or scopes that do not= . In general I really like how simple OAuth 2 is. By working within the const= raints of this simplicity we can keep the protocol simple and easy to use. I also very much like the simplicity of the protocol but is this an end in = itself? There are use cases not supported by the protocol at present. I int= ended to point this out and raise a discussion. We did not discuss a soluti= on so far, so we also don't know the impact this may cause to the protocol. Justin made a proposal some month ago, which seems reasonable to me: http:/= /www.ietf.org/mail-archive/web/oauth/current/msg06771.html I think the multiple tokens use case is relevant for every multi-service pr= ovider. If a client uses different services of such a provider (e.g. mail, web stor= age, telephony, and payment), there are good reasons to use different token= s for the respective resource servers, e.g. abuse prevention, service seggr= agation, privacy protection. This holds especially true if the services are= operated by different business partners in an ASP model. The problem becom= es even more obvious in cloud scenarios. With the current capabilities of the authorization code, such a client must= send the user through the OAuth dance twice or more often. Alternatively, = a single token is good to access all service. This means to trade user expe= rience for security or vice versa. I don't like this. regards, Torsten. -Bob On Tuesday, October 25, 2011, Dave Rochwerger > wrote: > Hi Dan, > I think we are going down the wrong path here. > Basically, you've started with the premise of wanting plain HTTP scheme (= in some circumstances), which has caused you to suggest both of, firstly, r= elaxing the only method of encryption in oauth2 and secondly, to further co= mplicate the protocol by allowing multiple tokens to be returned. > OAuth2 (unlike version 1) has no signatures or other encryption - it reli= es solely on SSL. Therefore any relaxation of this requirement breaks secur= ity wide open (even in your specific short-term token case). > I think you're asking the wrong question. > We should not ask "to relax the SSL requirement", but rather - Why do you= not want to use SSL? > With today's computer speeds, there is no reason not to use SSL. The plai= n HTTP scheme does not really provide a noticeable enough performance boost= . On a side note, if the likes of Google's SPDY is anything to go by, the f= uture might always be SSL only anyway. > Cheers, > Dave > > On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin > wrote: > > You're right, if tracking was all we needed then a single token would suf= fice. The reason for two tokens has more to do with the fact that we'd like= to allow "protected" operations to be called over plain http. This opens u= p the possibility of an attacker intercepting the token for his own nefario= us use. If the only thing that token gave him access to was relatively beni= gn operations like image search, it would be an acceptable risk (especially= if we have a relatively short lifespan for the token). > > > > In contrast, "confidential" operations would only be callable over https.= By requiring a different token for them (and not allowing that token to be= used for unprotected operations) we prevent it from being intercepted. Thi= s design intentionally mimics the way secure and non-secure http cookies wo= rk. > > > > Oauth today basically requires https for all bearer token implementations= . I would like to see this relaxed somewhat. > > > > Dan > > > > From: Dave Rochwerger [mailto:daver@quizlet.com= ] > Sent: Tuesday, October 25, 2011 4:08 PM > To: Dan Taflin > > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering > > > > Is separating this out into 2 different tokens, really the best way to so= lve your use case? > > > > It sounds to me that you simply want to track/log the two types of access= es differently, which can be done entirely outside of the oauth2 process. > > Just bucket your operations into two piles internally and track appropria= tely (which you would have to do anyway with scopes). > > > > Scopes are the specific access that the end user grants to a 3rd party to= access their protected resources. > > > > When an application, to use your example, asks for the scope "protected c= onfidential", they are providing those two levels of access to the 3rd part= y application. If the user says "allow", then that application has all the = access that those two scopes provides. > > > > Rather than getting applications to then further choose between two token= s to simply delineate two sets of operations seems like the wrong place to = be doing this. > > i.e., why does the 3rd party application have to choose which token to us= e for each set of operations? - the user has already granted both. The reso= urce server can do whatever tracking/logging it wants based on the actual o= perations requested - using the single token in this case. > > > > Regards, > > Dave > > > > On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin > wrote: > > I would like to second Torsten's pitch for the ability to return multiple= access tokens with a single authorization process. The use case for my com= pany is to segment operatio _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_5710F82C0E73B04FA559560098BF95B1250BDD1C21USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Torsten that there is a need for=20 supporting the multiple tokens use case.
Such a use case is described in the OAuth 2.0 us= e cases=20 draft
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-= 3.10
 

Zachary 
 

 

From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten=20 Lodderstedt
Sent: Wednesday, October 26, 2011 2:52 PM
To:=20 Bob Van Zant
Cc: OAuth WG; Dan Taflin
Subject: Re:=20 [OAUTH-WG] Returning two tokens. Was: Re: Rechartering

Hi,

Am 26.10.2011 05:41, schrieb Bob Van Zant:=20 I'm going to reiterate what has already been said.

OA= uth=20 already supports what you're trying to do. Just request a token twice, th= e=20 first time request it with a scope or scopes that allows these special=20 operations. The second time request it with a scope or scopes that do not= .=20

In general I really like how simple OAuth 2 is. By working within= the=20 constraints of this simplicity we can keep the protocol simple and easy t= o=20 use.

I also very much like the simplicity of the pro= tocol=20 but is this an end in itself? There are use cases not supported by the prot= ocol=20 at present. I intended to point this out and raise a discussion. We did not= =20 discuss a solution so far, so we also don't know the impact this may cause = to=20 the protocol.

Justin made a proposal some month ago, which seems=20 reasonable to me: h= ttp://www.ietf.org/mail-archive/web/oauth/current/msg06771.html=20

I think the multiple tokens use case is relevant for every multi-se= rvice=20 provider.

If a client uses different services of such a provider (e.= g.=20 mail, web storage, telephony, and payment), there are good reasons to use=20 different tokens for the respective resource servers, e.g. abuse prevention= ,=20 service seggragation, privacy protection. This holds especially true if the= =20 services are operated by different business partners in an ASP model. The=20 problem becomes even more obvious in cloud scenarios.

With the curr= ent=20 capabilities of the authorization code, such a client must send the user th= rough=20 the OAuth dance twice or more often. Alternatively, a single token is good = to=20 access all service. This means to trade user experience for security or vic= e=20 versa. I don't like this.

regards,
Torsten.


-Bob

On Tuesday, October 25, 2011, Dave Rochwerger= =20 <daver@quizlet.com> wrote:
> Hi=20 Dan,
> I think we are going down the wrong path here.
> Basic= ally,=20 you've started with the premise of wanting plain HTTP scheme (in some=20 circumstances), which has caused you to suggest both of, firstly, relaxin= g the=20 only method of encryption in oauth2 and secondly, to further complicate t= he=20 protocol by allowing multiple tokens to be returned.
> OA= uth2=20 (unlike version 1) has no signatures or other encryption - it relies sole= ly on=20 SSL. Therefore any relaxation of this requirement breaks security wide op= en=20 (even in your specific short-term token case).
> I think you're ask= ing=20 the wrong question.
> We should not ask "to relax the SSL requireme= nt",=20 but rather - Why do you not want to use SSL?
> With today's compute= r=20 speeds, there is no reason not to use SSL. The plain HTTP scheme does not= =20 really provide a noticeable enough performance boost. On a= side=20 note, if the likes of Google's SPDY is anything to go by, the future migh= t=20 always be SSL only anyway.
> Cheers,
> Dave
>
> O= n=20 Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin <dan.taflin@gettyimages.com>=20 wrote:
>
> You’re right, if tracking was all we needed = then a=20 single token would suffice. The reason for two tokens has more to do with= the=20 fact that we’d like to allow “protected” operations to = be called over plain=20 http. This opens up the possibility of an attacker intercepting the token= for=20 his own nefarious use. If the only thing that token gave him access to wa= s=20 relatively benign operations like image search, it would be an acceptable= risk=20 (especially if we have a relatively short lifespan for the=20 token).
>
>  
>
> In contrast, “confid= ential”=20 operations would only be callable over https. By requiring a different to= ken=20 for them (and not allowing that token to be used for unprotected operatio= ns)=20 we prevent it from being intercepted. This design intentionally mimics th= e way=20 secure and non-secure http cookies work.
>
>=20  
>
> Oauth today basically requires https for all beare= r=20 token implementations. I would like to see this relaxed=20 somewhat.
>
>  
>
> Dan
>
>=20  
>
> From: Dave Rochwerger [mailto:daver@quizlet.com]
> Sent: Tuesday, Oc= tober=20 25, 2011 4:08 PM
> To: Dan Taflin
>
> Cc: OAuth WG
&= gt;=20 Subject: Re: [OAUTH-WG] Rechartering
>
>  
>
&g= t; Is=20 separating this out into 2 different tokens, really the best way to solve= your=20 use case?
>
>  
>
> It sounds to me that you= =20 simply want to track/log the two types of accesses differently, which can= be=20 done entirely outside of the oauth2 process.
>
> Just bucket = your=20 operations into two piles internally and track appropriately (which you w= ould=20 have to do anyway with scopes).
>
>  
>
> Sc= opes=20 are the specific access that the end user grants to a 3rd party to access= =20 their protected resources.
>
>  
>
> When an= =20 application, to use your example, asks for the scope "protected confident= ial",=20 they are providing those two levels of access to the 3rd party applicatio= n. If=20 the user says "allow", then that application has all the access that thos= e two=20 scopes provides.
>
>  
>
> Rather than getti= ng=20 applications to then further choose between two tokens to=20 simply delineate two sets of operations seems like the wrong place t= o be=20 doing this.
>
> i.e., why does the 3rd party application have= to=20 choose which token to use for each set of operations? - the user has alre= ady=20 granted both. The resource server can do whatever tracking/logging it wan= ts=20 based on the actual operations requested - using the single token in this= =20 case.
>
>  
>
> Regards,
>
>=20 Dave
>
>  
>
> On Tue, Oct 25, 2011 at 3:36 = PM,=20 Dan Taflin <dan.taflin@gettyimages.com>=20 wrote:
>
> I would like to second Torsten's pitch for the abi= lity=20 to return multiple access tokens with a single authorization process. The= use=20 case for my company is to segment operatio 

___=
____________________________________________
OAuth mailing list
OAuth@ie=
tf.org
https://www.ietf.org/mailman/listinfo/oauth
--_000_5710F82C0E73B04FA559560098BF95B1250BDD1C21USNAVSXCHMBSA_-- From dick.hardt@gmail.com Sat Oct 29 00:07:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E7411E808B for ; Sat, 29 Oct 2011 00:07:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUy4PlBT7r7r for ; Sat, 29 Oct 2011 00:07:57 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67C6B11E807F for ; Sat, 29 Oct 2011 00:07:57 -0700 (PDT) Received: by faas12 with SMTP id s12so4893371faa.31 for ; Sat, 29 Oct 2011 00:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=w/KcB49jK30n35df2e8dhHNTUxt3tTGW5JLPQlMO40U=; b=ejEmpf7UdkLBRECR28nIhM158OqsGFRQfRZClVCviy/bYn7SCSKma4G7UqbvX5iD+s ESbRp9ybV/IaD//UeMZ/fBgHj/t4LpX7s0p7L2x28plFhQJKoVzeKWygZW2mXmX9g/9n 5ieozkONVsCt1RGWBkjQmz2+zRrlOOZkUBjzQ= Received: by 10.223.77.71 with SMTP id f7mr11814673fak.33.1319872072014; Sat, 29 Oct 2011 00:07:52 -0700 (PDT) Received: from [192.168.2.121] ([62.87.186.202]) by mx.google.com with ESMTPS id a21sm22254897fao.18.2011.10.29.00.07.47 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 00:07:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 29 Oct 2011 00:07:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44A277AD-1874-4160-9ECD-87DEFB2A7F60@gmail.com> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG , Dan Taflin Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 07:07:59 -0000 What if the access tokens come from different authoritative servers? On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote: > Why not just ask for one access token with all the scopes you need, = then refresh it by asking for the different subsets you want. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Dan Taflin >> Sent: Tuesday, October 25, 2011 3:37 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >>=20 >> I would like to second Torsten's pitch for the ability to return = multiple access >> tokens with a single authorization process. The use case for my = company is to >> segment operations into two main categories: protected and = confidential. (A >> possible third category, public, would not require any authorization = at all). >> Protected operations would be user-specific operations that don't = involve >> the passing of any sensitive information, such as image search = results tagged >> with information about whether each image is available for download = by that >> user. Confidential operations would involve passing user data, like = user >> registration or e-commerce. We would like to protect each category of >> operations with distinct tokens: a general-use token for protected >> operations, and a secure token for confidential operations. >>=20 >> We could use the scope parameter to specify either "protected" or >> "confidential". Currently the oauth spec allows a Refresh token to = request a >> new token with reduced scope from the one originally issued, but = there is no >> way to obtain a new token with a completely different scope without = doing >> the full oauth dance a second time. >>=20 >> Dan >>=20 >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Thursday, October 20, 2011 3:57 PM >> To: Hannes Tschofenig >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >>=20 >> Hi all, >>=20 >> my prioritization is driven by the goal to make OAuth the = authorization >> framework of choice for any internet standard protocol, such as = WebDAV, >> IMAP, SMTP or SIP. So let me first explain what is missing from my = point of >> view and explain some thoughts how to fill the gaps. >>=20 >> A standard protocol is defined in terms of resource types and = messages by a >> body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, = and >> used by different but deployment-independent clients. >> OAuth-based protocol specifications must also define scope values = (e.g. >> read, write, send) and their relation to the resource types and = messages. The >> different deployments expose the standard protocol on different = resource >> server endpoints. In my opinion, it is fundamental >> to clearly distinguish scope values (standardized, static) and >> resource server addresses (deployment specific) and to manage their >> relationships. The current scope definition is much to weak and = insufficient. >> Probably, the UMA concepts of hosts, resources sets, and = corresponding >> scopes could be adopted for that purpose. >>=20 >> OAuth today requires clients to register with the service provider = before >> they are deployed. Would you really expect IMAP clients, e.g. >> Thunderbird, to register with any a-Mail services upfront? So clients = should >> be given a way to register dynamically to the authorization servers. = This >> should also allow us to cover "client instance" aspects. >> It is interesting to note, that such a mechanism would allow us to = get rid of >> secret-less clients and the one-time usage requirement for = authorization >> codes. >>=20 >> We also assume the client to know the URLs of the resource server and = the >> corresponding authorization server and to use HTTPS server = authentication >> to verify the resource server's authenticity. This is impossible in = the standard >> scenario. Clients must be able to discover the authorization server a >> particular resource server relies on at runtime. The discovery = mechanism >> could be specified by the OAuth WG, but could also be part of an = application >> protocols specification. But we MUST find another way to prevent = token >> phishing by counterfeit resource servers. >>=20 >> As one approach, the client could pass the (previously HTTPS >> validated) resource server's URL with the authorization request. The >> authorization server should then refuse such requests for any unknown >> (counterfeit) resource servers. Such an additional parameter could = also serve >> as namespace for scope values and enable service providers to run = multiple >> instances of the same service within a single deployment. >>=20 >> If the additional data enlarges the request payload to much, we could >> consider to adopt the "request by reference" proposal. >>=20 >> Let's now assume, OAuth is successful in the world of standard = protocols and >> we will see plenty of deployments with a bunch of different OAuth >> protected resource servers. Shall this servers all be accessible with = a single >> token? In my opinion, this would cause security, privacy and/or >> scalability/performance problems. To give just the most obvious = example, >> the target audience of such a token cannot be restricted enough, = which may >> allow a resource server (or an attacker in control of it) to abuse = the token on >> other servers. But the current design of the code grant type forces >> deployments to use the same token for all services. What is needed = from my >> point of view is a way to request and issue multiple server-specific = access >> tokens with a single authorization process. >>=20 >> I've been advocating this topic for a long time now and I'm still = convinced this >> is required to really complete the core design. We at Deutsche = Telekom >> needed and implemented this function on top of the existing core. In = my >> opinion, a core enhancement would be easier to handle and more = powerful. >> If others support this topic, I would be willed to submit an I-D = describing a >> possible solution. >>=20 >> If we take standards really seriously, then service providers should = be given >> the opportunity to implement their service by utilizing standard = server >> implementations. This creates the challenge to find a standardized = protocol >> between authorization server and resource server to exchange = authorization >> data. Depending on the token design (self-contained vs. handle) this = could >> be solved by either standardizing a token format (JWT) or an = authorization >> API. >>=20 >> Based on the rationale given above, my list is as follows (topics w/o = I-D are >> marked with *): >>=20 >> - Revocation (low hanging fruit since I-D is ready and implemented in = some >> places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >>=20 >> regards, >> Torsten. >> Zitat von Hannes Tschofenig : >>=20 >>> Hi all, >>>=20 >>> in preparation of the upcoming IETF meeting Barry and I would like = to >>> start a re-chartering discussion. We both are currently attending = the >>> Internet Identity Workshop and so we had the chance to solicit input >>> from the participants. This should serve as a discussion starter. >>>=20 >>> Potential future OAuth charter items (in random order): >>>=20 >>> ---------------- >>>=20 >>> 1) Dynamic Client Registration Protocol >>>=20 >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>>=20 >>> 2) Token Revocation >>>=20 >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>>=20 >>> 3) UMA >>>=20 >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>>=20 >>> 4) Client Instance Extension >>>=20 >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>>=20 >>> 5) XML Encoding >>>=20 >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>>=20 >>> 6) JSON Web Token >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>>=20 >>> 7) JSON Web Token (JWT) Bearer Profile >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>>=20 >>> 8) User Experience Extension >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>>=20 >>> 9) Request by Reference >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>>=20 >>> 10) Simple Web Discovery >>>=20 >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>>=20 >>> ---------------- >>>=20 >>> We have the following questions: >>>=20 >>> a) Are you interested in any of the above-listed items? (as a >>> reviewer, co-author, implementer, or someone who would like to >>> deploy). It is also useful to know if you think that we shouldn't = work >>> on a specific item. >>>=20 >>> b) Are there other items you would like to see the group working on? >>>=20 >>> Note: In case your document is expired please re-submit it. >>>=20 >>> Ciao >>> Hannes & Barry >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 julian.reschke@gmx.de Sat Oct 29 02:20:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3E621F8AD1 for ; Sat, 29 Oct 2011 02:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[AWL=-1.602, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7dtUqvO2sx1 for ; Sat, 29 Oct 2011 02:20:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0245421F88A0 for ; Sat, 29 Oct 2011 02:20:47 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2011 09:20:46 -0000 Received: from p5DCC93A7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.147.167] by mail.gmx.net (mp053) with SMTP; 29 Oct 2011 11:20:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18pwuJlpYYp0sHS67O8bRrXpNjsdXblEM6qs1HRIh aqXBU8hQtxNVm5 Message-ID: <4EABC566.10908@gmx.de> Date: Sat, 29 Oct 2011 11:20:38 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <20111027210029.27578.27106.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E11290D1BC70@WSMSG3153V.srv.dir.telstra.com> <4EAA6ED8.8000502@gmx.de> In-Reply-To: <4EAA6ED8.8000502@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-12: ABNF nits X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 09:20:51 -0000 On 2011-10-28 10:59, Julian Reschke wrote: > On 2011-10-28 01:30, Manger, James H wrote: >> ... >> Perhaps a better approach is to: defined,,, >> and values as; add text saying senders MUST >> NOT use quoted-string's escape mechanism (so " and \ cannot appear in >> the values), though receivers MAY use a standard quoted-string parser; >> say the value must match; say the >> value is a list of space-delimited, case sensitive strings. >> ... > > This goes into the right direction. > > I would also allow both token and quoted-string, because it seems to be > totally pointless to forbid it. > > (I'll send a longer summary about open issues soonish)) > ... In the HTTPbis WG: Ticket: Change Proposal: Feedback appreciated, Julian From wmills@yahoo-inc.com Sat Oct 29 08:04:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849A921F84D6 for ; Sat, 29 Oct 2011 08:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.381 X-Spam-Level: X-Spam-Status: No, score=-17.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuVy-jYs6nrX for ; Sat, 29 Oct 2011 08:04:26 -0700 (PDT) Received: from nm11-vm4.bullet.mail.ne1.yahoo.com (nm11-vm4.bullet.mail.ne1.yahoo.com [98.138.91.171]) by ietfa.amsl.com (Postfix) with SMTP id A2ED621F84D2 for ; Sat, 29 Oct 2011 08:04:26 -0700 (PDT) Received: from [98.138.90.57] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 29 Oct 2011 15:04:20 -0000 Received: from [98.138.89.245] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 29 Oct 2011 15:04:20 -0000 Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP; 29 Oct 2011 15:04:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 80991.37663.bm@omp1059.mail.ne1.yahoo.com Received: (qmail 9239 invoked by uid 60001); 29 Oct 2011 15:04:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1319900659; bh=lpatjBT9MsgctVhu/ZtB/LA7WOHNLiA916yUkzrKzb0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dym9QTYRovgardObhiHpBt1vpVwpshJRScai5om19coFq3x08rdKiLU8PBAvJ57j+OKqUhOj1I//FTwcTF704LY70Bv/3IB56ePmQ9hXIs/IlfgGWgDxPp4R2aJuLekYPfUKxU3fqEi1d6Wmj2RjVOhIvRP4+gvhqVUI5o4O9fw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=m8LvDXHvWkMlf7peis2fp+DCAV51pAXfT1EzGEka48+6DNY8QENO0D5VUQkzaUFfKEfSZkW/KgaxEZDM7h4stDfgm5ay/F7iWhv8WZLFUC4TexNOV8q3+OWoE8q0qmg1aXWRSybYfPgSMZzaj0G3aj4Dg8gg8/Q4uYhJxwyJ0u0=; X-YMail-OSG: 1Z0zlqAVM1mQFkhVSjXxTa0q0VNsA2TvIJhsSfrlKyvHpsx BEVP_fp1HA0zR8bmXDFBzmUv253Ac8MKSuBrjeyaiEHH9jzlOEU0ccDU4lcd La.7pXTP2ueuouCt83s19tenzVeSywLLM6IdUfFbbFhNAO1pwQQHMiDhQ6EY GlveLeMg7.UYR5CtQQktrmvFXe.kbyharS6_W.slg3lN9aauCRt1q8HI0LGp GM3sQjYqB3FXeJsChHJrPaNesF1JtIrDZidDpmL5RJfK5IW27Cn26S8uBRCY iuis5PBNNg8Vwnwbq6CnXUvyPmJzCHzi0ui_dKixDLgh9eJpiYg20mR_pr_n pZ06L6hDvVKWoFDmGT9GnKcEsYFzvcZrR2pSCLN7rjGoLs6i.90QhTOL0GMu ANxcys2_.jjxpKORlxpane8Hw4kG6q3xlcT8Pqg-- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Sat, 29 Oct 2011 08:04:19 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.327843 References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <44A277AD-1874-4160-9ECD-87DEFB2A7F60@gmail.com> Message-ID: <1319900659.4384.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Sat, 29 Oct 2011 08:04:19 -0700 (PDT) From: William Mills To: Dick Hardt , Eran Hammer-Lahav In-Reply-To: <44A277AD-1874-4160-9ECD-87DEFB2A7F60@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-739885585-1319900659=:4384" Cc: OAuth WG , Dan Taflin Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 15:04:28 -0000 --0-739885585-1319900659=:4384 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable There's a problem here, which I think Eran's proposal of differentiating wi= th scopes solves that should be made explicit, to whit, how does the client= know which token to use in a specific context.=A0 We have two options:=A0 = one is to specify different scopes, and the other is to use different token= types.=A0 =0A=0A=0AIn the use case presented where it's different security= levels=A0 would just choose to go with the more secure MAC token in all ca= ses, but it's probably worth noting how to do this.=0A=0A-bill=0A=0A=0A____= ____________________________=0AFrom: Dick Hardt =0ATo= : Eran Hammer-Lahav =0ACc: OAuth WG ; = Dan Taflin =0ASent: Saturday, October 29, 2011 = 12:07 AM=0ASubject: Re: [OAUTH-WG] Rechartering=0A=0AWhat if the access tok= ens come from different authoritative servers?=0A=0AOn Oct 26, 2011, at 9:1= 5 AM, Eran Hammer-Lahav wrote:=0A=0A> Why not just ask for one access token= with all the scopes you need, then refresh it by asking for the different = subsets you want.=0A> =0A> EHL=0A> =0A>> -----Original Message-----=0A>> Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A>> O= f Dan Taflin=0A>> Sent: Tuesday, October 25, 2011 3:37 PM=0A>> To: OAuth WG= =0A>> Subject: Re: [OAUTH-WG] Rechartering=0A>> =0A>> I would like to secon= d Torsten's pitch for the ability to return multiple access=0A>> tokens wit= h a single authorization process. The use case for my company is to=0A>> se= gment operations into two main categories: protected and confidential. (A= =0A>> possible third category, public, would not require any authorization = at all).=0A>> Protected operations would be user-specific operations that d= on't involve=0A>> the passing of any sensitive information, such as image s= earch results tagged=0A>> with information about whether each image is avai= lable for download by that=0A>> user. Confidential operations would involve= passing user data, like user=0A>> registration or e-commerce. We would lik= e to protect each category of=0A>> operations with distinct tokens: a gener= al-use token for protected=0A>> operations, and a secure token for confiden= tial operations.=0A>> =0A>> We could use the scope parameter to specify eit= her "protected" or=0A>> "confidential". Currently the oauth spec allows a R= efresh token to request a=0A>> new token with reduced scope from the one or= iginally issued, but there is no=0A>> way to obtain a new token with a comp= letely different scope without doing=0A>> the full oauth dance a second tim= e.=0A>> =0A>> Dan=0A>> =0A>> -----Original Message-----=0A>> From: Torsten = Lodderstedt [mailto:torsten@lodderstedt.net]=0A>> Sent: Thursday, October 2= 0, 2011 3:57 PM=0A>> To: Hannes Tschofenig=0A>> Cc: OAuth WG=0A>> Subject: = Re: [OAUTH-WG] Rechartering=0A>> =0A>> Hi all,=0A>> =0A>> my prioritization= is driven by the goal to make OAuth the authorization=0A>> framework of ch= oice for any internet standard protocol, such as WebDAV,=0A>> IMAP, SMTP or= SIP. So let me first explain what is missing from my point of=0A>> view an= d explain some thoughts how to fill the gaps.=0A>> =0A>> A standard protoco= l is defined in terms of resource types and messages by a=0A>> body (e.g. I= ETF, OIDF, OMA), (hopefully) implemented in many places, and=0A>> used by d= ifferent but deployment-independent clients.=0A>> OAuth-based protocol spec= ifications must also define scope values (e.g.=0A>> read, write, send) and = their relation to the resource types and messages. The=0A>> different deplo= yments expose the standard protocol on different resource=0A>> server endpo= ints. In my opinion, it is fundamental=0A>> to clearly distinguish scope va= lues (standardized, static) and=0A>> resource server addresses (deployment = specific) and to manage their=0A>> relationships. The current scope definit= ion is much to weak and insufficient.=0A>> Probably, the UMA concepts of ho= sts, resources sets, and corresponding=0A>> scopes could be adopted for tha= t purpose.=0A>> =0A>> OAuth today requires clients to register with the ser= vice provider before=0A>> they are deployed. Would you really expect IMAP c= lients, e.g.=0A>> Thunderbird, to register with any a-Mail services upfront= ? So clients should=0A>> be given a way to register dynamically to the auth= orization servers. This=0A>> should also allow us to cover "client instance= " aspects.=0A>> It is interesting to note, that such a mechanism would allo= w us to get rid of=0A>> secret-less clients and the one-time usage requirem= ent for authorization=0A>> codes.=0A>> =0A>> We also assume the client to k= now the URLs of the resource server and the=0A>> corresponding authorizatio= n server and to use HTTPS server authentication=0A>> to verify the resource= server's authenticity. This is impossible in the standard=0A>> scenario. C= lients must be able to discover the authorization server a=0A>> particular = resource server relies on at runtime. The discovery mechanism=0A>> could be= specified by the OAuth WG, but could also be part of an application=0A>> p= rotocols specification. But we MUST find another way to prevent token=0A>> = phishing by counterfeit resource servers.=0A>> =0A>> As one approach, the c= lient could pass the (previously HTTPS=0A>> validated) resource server's UR= L with the authorization request. The=0A>> authorization server should then= refuse such requests for any unknown=0A>> (counterfeit) resource servers. = Such an additional parameter could also serve=0A>> as namespace for scope v= alues and enable service providers to run multiple=0A>> instances of the sa= me service within a single deployment.=0A>> =0A>> If the additional data en= larges the request payload to much, we could=0A>> consider to adopt the "re= quest by reference" proposal.=0A>> =0A>> Let's now assume, OAuth is success= ful in the world of standard protocols and=0A>> we will see plenty of deplo= yments with a bunch of different OAuth=0A>> protected resource servers. Sha= ll this servers all be accessible with a single=0A>> token? In my opinion, = this would cause security, privacy and/or=0A>> scalability/performance prob= lems. To give just the most obvious example,=0A>> the target audience of su= ch a token cannot be restricted enough, which may=0A>> allow a resource ser= ver (or an attacker in control of it) to abuse the token on=0A>> other serv= ers. But the current design of the code grant type forces=0A>> deployments = to use the same token for all services. What is needed from my=0A>> point o= f view is a way to request and issue multiple server-specific access=0A>> t= okens with a single authorization process.=0A>> =0A>> I've been advocating = this topic for a long time now and I'm still convinced this=0A>> is require= d to really complete the core design. We at Deutsche Telekom=0A>> needed an= d implemented this function on top of the existing core. In my=0A>> opinion= , a core enhancement would be easier to handle and more powerful.=0A>> If o= thers support this topic, I would be willed to submit an I-D describing a= =0A>> possible solution.=0A>> =0A>> If we take standards really seriously, = then service providers should be given=0A>> the opportunity to implement th= eir service by utilizing standard server=0A>> implementations. This creates= the challenge to find a standardized protocol=0A>> between authorization s= erver and resource server to exchange authorization=0A>> data. Depending on= the token design (self-contained vs. handle) this could=0A>> be solved by = either standardizing a token format (JWT) or an authorization=0A>> API.=0A>= > =0A>> Based on the rationale given above, my list is as follows (topics w= /o I-D are=0A>> marked with *):=0A>> =0A>> - Revocation (low hanging fruit = since I-D is ready and implemented in some=0A>> places)=0A>> - Resource ser= ver notion*=0A>> - Multiple access tokens*=0A>> - Dynamic client registrati= on=0A>>=A0 1) Dynamic Client Registration Protocol=0A>>=A0 4) Client Instan= ce Extension=0A>> - Discovery=0A>>=A0 (10) Simple Web Discovery, probably o= ther specs as well=0A>> - (6) JSON Web Token=0A>> - (7) JSON Web Token (JWT= ) Bearer Profile=0A>> - 8) User Experience Extension=0A>> - Device flow=0A>= > - 9) Request by Reference=0A>>=A0 (depending resource server notion and m= ultiple access tokens)=0A>> =0A>> regards,=0A>> Torsten.=0A>> Zitat von Han= nes Tschofenig :=0A>> =0A>>> Hi all,=0A>>> =0A>>= > in preparation of the upcoming IETF meeting Barry and I would like to=0A>= >> start a re-chartering discussion.=A0 We both are currently attending the= =0A>>> Internet Identity Workshop and so we had the chance to solicit input= =0A>>> from the participants. This should serve as a discussion starter.=0A= >>> =0A>>> Potential future OAuth charter items (in random order):=0A>>> = =0A>>> ----------------=0A>>> =0A>>> 1) Dynamic Client Registration Protoco= l=0A>>> =0A>>> Available document:=0A>>> http://datatracker.ietf.org/doc/dr= aft-hardjono-oauth-dynreg/=0A>>> =0A>>> 2) Token Revocation=0A>>> =0A>>> Av= ailable document:=0A>>> http://datatracker.ietf.org/doc/draft-lodderstedt-o= auth-revocation/=0A>>> =0A>>> 3) UMA=0A>>> =0A>>> Available document:=0A>>>= http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/=0A>>> =0A>>>= 4) Client Instance Extension=0A>>> =0A>>> Available document:=0A>>> http:/= /tools.ietf.org/id/draft-richer-oauth-instance-00.txt=0A>>> =0A>>> 5) XML E= ncoding=0A>>> =0A>>> Available document:=0A>>> http://tools.ietf.org/id/dra= ft-richer-oauth-xml-00.txt=0A>>> =0A>>> 6) JSON Web Token=0A>>> =0A>>> Avai= lable document:=0A>>> http://tools.ietf.org/html/draft-jones-json-web-token= -05=0A>>> =0A>>> 7) JSON Web Token (JWT) Bearer Profile=0A>>> =0A>>> Availa= ble document:=0A>>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer= -00=0A>>> =0A>>> 8) User Experience Extension=0A>>> =0A>>> Available docume= nt:=0A>>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00=0A>>> = =0A>>> 9) Request by Reference=0A>>> =0A>>> Available document:=0A>>> http:= //tools.ietf.org/html/draft-sakimura-oauth-requrl-00=0A>>> =0A>>> 10) Simpl= e Web Discovery=0A>>> =0A>>> Available document:=0A>>> http://tools.ietf.or= g/html/draft-jones-simple-web-discovery-00=0A>>> =0A>>> ----------------=0A= >>> =0A>>> We have the following questions:=0A>>> =0A>>> a) Are you interes= ted in any of the above-listed items? (as a=0A>>> reviewer, co-author, impl= ementer, or someone who would like to=0A>>> deploy). It is also useful to k= now if you think that we shouldn't work=0A>>> on a specific item.=0A>>> =0A= >>> b) Are there other items you would like to see the group working on?=0A= >>> =0A>>> Note: In case your document is expired please re-submit it.=0A>>= > =0A>>> Ciao=0A>>> Hannes & Barry=0A>>> =0A>>> ___________________________= ____________________=0A>>> OAuth mailing list=0A>>> OAuth@ietf.org=0A>>> ht= tps://www.ietf.org/mailman/listinfo/oauth=0A>> =0A>> =0A>> =0A>> =0A>> ____= ___________________________________________=0A>> OAuth mailing list=0A>> OA= uth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A> _________= ______________________________________=0A> OAuth mailing list=0A> OAuth@iet= f.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A=0A________________= _______________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/oauth --0-739885585-1319900659=:4384 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
There's a problem here, which I think Eran's proposal of differentiating = with scopes solves that should be made explicit, to whit, how does the clie= nt know which token to use in a specific context.  We have two options= :  one is to specify different scopes, and the other is to use differe= nt token types. 

In the use case presented where it's different security levels  wou= ld just choose to go with the more secure MAC token in all cases, but it's = probably worth noting how to do this.

-bill
From: Dick Hardt <dick.hardt@gmail.com>To: Eran Hammer-Lahav &l= t;eran@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>; Dan Taflin <dan.taflin@gettyimag= es.com>
Sent: Saturd= ay, October 29, 2011 12:07 AM
Subj= ect: Re: [OAUTH-WG] Rechartering

What if the acces= s tokens come from different authoritative servers?

On Oct 26, 2011,= at 9:15 AM, Eran Hammer-Lahav wrote:

> Why not just ask for one = access token with all the scopes you need, then refresh it by asking for th= e different subsets you want.
>
> EHL
>
>> ---= --Original Message-----
>> From: oauth-bounces@ietf.org [mailto:= oauth-bounces@ietf.org] On Behalf
>> Of Dan Taflin>> Sent: Tuesday, October 25, 2011 3:37 PM
>> To: OAuth WG<= br>>> Subject: Re: [OAUTH-WG] Rechartering
>>
>> I= would like to second Torsten's pitch for the ability to return multiple ac= cess
>> tokens with a single authorization process. The use case f= or my company is to
>> segment operations into two main categories= : protected and confidential. (A
>> possible third category, publi= c, would not require any authorization at all).
>> Protected opera= tions would be user-specific operations that don't involve
>> the = passing of any sensitive information, such as image search results tagged>> with information about whether each image is available for download by that
>> user. Confidential operations would involve p= assing user data, like user
>> registration or e-commerce. We woul= d like to protect each category of
>> operations with distinct tok= ens: a general-use token for protected
>> operations, and a secure= token for confidential operations.
>>
>> We could use t= he scope parameter to specify either "protected" or
>> "confidenti= al". Currently the oauth spec allows a Refresh token to request a
>&g= t; new token with reduced scope from the one originally issued, but there i= s no
>> way to obtain a new token with a completely different scop= e without doing
>> the full oauth dance a second time.
>>=
>> Dan
>>
>> -----Original Message-----
&g= t;> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
&g= t;> Sent: Thursday, October 20, 2011 3:57 PM
>> To: Hannes Tsch= ofenig
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Rechart= ering
>>
>> Hi all,
>>
>> my prioriti= zation is driven by the goal to make OAuth the authorization
>> fr= amework of choice for any internet standard protocol, such as WebDAV,
&g= t;> IMAP, SMTP or SIP. So let me first explain what is missing from my p= oint of
>> view and explain some thoughts how to fill the gaps.>>
>> A standard protocol is defined in terms of resource = types and messages by a
>> body (e.g. IETF, OIDF, OMA), (hopefully= ) implemented in many places, and
>> used by different but deploym= ent-independent clients.
>> OAuth-based protocol specifications mu= st also define scope values (e.g.
>> read, write, send) and their relation to the resource types and messages. The
>> differe= nt deployments expose the standard protocol on different resource
>&g= t; server endpoints. In my opinion, it is fundamental
>> to clearl= y distinguish scope values (standardized, static) and
>> resource = server addresses (deployment specific) and to manage their
>> rela= tionships. The current scope definition is much to weak and insufficient.>> Probably, the UMA concepts of hosts, resources sets, and corresp= onding
>> scopes could be adopted for that purpose.
>> >> OAuth today requires clients to register with the service provid= er before
>> they are deployed. Would you really expect IMAP clien= ts, e.g.
>> Thunderbird, to register with any a-Mail services upfr= ont? So clients should
>> be given a way to register dynamically t= o the authorization servers. This
>> should also allow us to cover "client instance" aspects.
>> It is interesting to note,= that such a mechanism would allow us to get rid of
>> secret-less= clients and the one-time usage requirement for authorization
>> c= odes.
>>
>> We also assume the client to know the URLs o= f the resource server and the
>> corresponding authorization serve= r and to use HTTPS server authentication
>> to verify the resource= server's authenticity. This is impossible in the standard
>> scen= ario. Clients must be able to discover the authorization server a
>&g= t; particular resource server relies on at runtime. The discovery mechanism=
>> could be specified by the OAuth WG, but could also be part of = an application
>> protocols specification. But we MUST find anothe= r way to prevent token
>> phishing by counterfeit resource servers= .
>>
>> As one approach, the client could pass the (previously HTTPS
>> validated) resource server's URL with th= e authorization request. The
>> authorization server should then r= efuse such requests for any unknown
>> (counterfeit) resource serv= ers. Such an additional parameter could also serve
>> as namespace= for scope values and enable service providers to run multiple
>> = instances of the same service within a single deployment.
>>
&= gt;> If the additional data enlarges the request payload to much, we cou= ld
>> consider to adopt the "request by reference" proposal.
&g= t;>
>> Let's now assume, OAuth is successful in the world of s= tandard protocols and
>> we will see plenty of deployments with a = bunch of different OAuth
>> protected resource servers. Shall this= servers all be accessible with a single
>> token? In my opinion, = this would cause security, privacy and/or
>> scalability/performance problems. To give just the most obvious example,>> the target audience of such a token cannot be restricted enough,= which may
>> allow a resource server (or an attacker in control o= f it) to abuse the token on
>> other servers. But the current desi= gn of the code grant type forces
>> deployments to use the same to= ken for all services. What is needed from my
>> point of view is a= way to request and issue multiple server-specific access
>> token= s with a single authorization process.
>>
>> I've been a= dvocating this topic for a long time now and I'm still convinced this
&g= t;> is required to really complete the core design. We at Deutsche Telek= om
>> needed and implemented this function on top of the existing = core. In my
>> opinion, a core enhancement would be easier to hand= le and more powerful.
>> If others support this topic, I would be willed to submit an I-D describing a
>> possible solutio= n.
>>
>> If we take standards really seriously, then ser= vice providers should be given
>> the opportunity to implement the= ir service by utilizing standard server
>> implementations. This c= reates the challenge to find a standardized protocol
>> between au= thorization server and resource server to exchange authorization
>>= ; data. Depending on the token design (self-contained vs. handle) this coul= d
>> be solved by either standardizing a token format (JWT) or an = authorization
>> API.
>>
>> Based on the ration= ale given above, my list is as follows (topics w/o I-D are
>> mark= ed with *):
>>
>> - Revocation (low hanging fruit since = I-D is ready and implemented in some
>> places)
>> - Reso= urce server notion*
>> - Multiple access tokens*
>> - Dynamic client registration
>>  1) Dyn= amic Client Registration Protocol
>>  4) Client Instance Exte= nsion
>> - Discovery
>>  (10) Simple Web Discovery, = probably other specs as well
>> - (6) JSON Web Token
>> -= (7) JSON Web Token (JWT) Bearer Profile
>> - 8) User Experience E= xtension
>> - Device flow
>> - 9) Request by Reference>>  (depending resource server notion and multiple access token= s)
>>
>> regards,
>> Torsten.
>> Zitat= von Hannes Tschofenig <hannes.tschofenig@gmx.net>= :
>>
>>> Hi all,
>>>
>>> in = preparation of the upcoming IETF meeting Barry and I would like to
>&= gt;> start a re-chartering discussion.  We both are currently attending the
>>> Internet Identity Workshop and so we had the= chance to solicit input
>>> from the participants. This should= serve as a discussion starter.
>>>
>>> Potential = future OAuth charter items (in random order):
>>>
>>&= gt; ----------------
>>>
>>> 1) Dynamic Client Reg= istration Protocol
>>>
>>> Available document:
= >>> http://datatracker.ietf.org/doc/draft-hardjono= -oauth-dynreg/
>>>
>>> 2) Token Revocation
= >>>
>>> Available document:
>>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rev= ocation/
>>>
>>> 3) UMA
>>>
>>> Available document:
>>> http= ://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
>>&g= t;
>>> 4) Client Instance Extension
>>>
>&g= t;> Available document:
>>> http://tools.ietf= .org/id/draft-richer-oauth-instance-00.txt
>>>
>>= > 5) XML Encoding
>>>
>>> Available document:>>> http://tools.ietf.org/id/draft-richer-oauth-xml-00= .txt
>>>
>>> 6) JSON Web Token
>>>=
>>> Available document:
>>> http://tools.ietf.org/html/draft-jones-json-web-token-05=
>>>
>>> 7) JSON Web Token (JWT) Bearer Profil= e
>>>
>>> Available document:
>>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00<= br>>>>
>>> 8) User Experience Extension
>>&g= t;
>>> Available document:
>>> http://= tools.ietf.org/html/draft-recordon-oauth-v2-ux-00
>>>
&= gt;>> 9) Request by Reference
>>>
>>> Availa= ble document:
>>> http://tools.ietf.org/html/draft= -sakimura-oauth-requrl-00
>>>
>>> 10) Simple W= eb Discovery
>>>
>>> Available document:
>>= > http://tools.ietf.org/html/draft-jones-simple-web-di= scovery-00
>>>
>>> ----------------
>>= ;>
>>> We have the following questions:
>>> >>> a) Are you interested in any of the above-listed items? (as a=
>>> reviewer, co-author, implementer, or someone who would lik= e to
>>> deploy). It is also useful to know if you think that w= e shouldn't work
>>> on a specific item.
>>>
&g= t;>> b) Are there other items you would like to see the group working= on?
>>>
>>> Note: In case your document is expire= d please re-submit it.
>>>
>>> Ciao
>>>= ; Hannes & Barry
>>>
>>> _______________________________________________
>>> OAuth mail= ing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/ma= ilman/listinfo/oauth
>>
>>
>>
>>=
>> _______________________________________________
>> O= Auth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/m= ailman/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-739885585-1319900659=:4384-- From ve7jtb@ve7jtb.com Sat Oct 29 08:31:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB3821F8678 for ; Sat, 29 Oct 2011 08:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtQ-MAoySw1H for ; Sat, 29 Oct 2011 08:31:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB0521F8677 for ; Sat, 29 Oct 2011 08:31:24 -0700 (PDT) Received: by ggnv1 with SMTP id v1so5402967ggn.31 for ; Sat, 29 Oct 2011 08:31:17 -0700 (PDT) Received: by 10.150.72.35 with SMTP id u35mr6468363yba.9.1319902275137; Sat, 29 Oct 2011 08:31:15 -0700 (PDT) Received: from [192.168.1.213] ([190.22.74.59]) by mx.google.com with ESMTPS id l27sm34572699ani.21.2011.10.29.08.31.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Oct 2011 08:31:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_751B09C0-B946-4F22-8D9F-66A1041C6B81"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1319900659.4384.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Sat, 29 Oct 2011 12:31:08 -0300 Message-Id: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <44A277AD-1874-4160-9ECD-87DEFB2A7F60@gmail.com> <1319900659.4384.YahooMailNeo@web31804.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1251.1) Cc: Dan Taflin , OAuth WG Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 15:31:26 -0000 --Apple-Mail=_751B09C0-B946-4F22-8D9F-66A1041C6B81 Content-Type: multipart/alternative; boundary="Apple-Mail=_58254715-3BAB-46E4-ABCD-26C2E9B06D20" --Apple-Mail=_58254715-3BAB-46E4-ABCD-26C2E9B06D20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Some may argue that MAC tokens are not necessarily more secure:) =20 Eran's solution may well be sufficient for MAC (i still think downs = scoping is necessary if symmetric keys are used), however there are = people using BEARER who encode information into signed tokens. Those people also use the implicit flow. There is no option at the = moment other than returning multiple tokens. John B. On 2011-10-29, at 12:04 PM, William Mills wrote: > There's a problem here, which I think Eran's proposal of = differentiating with scopes solves that should be made explicit, to = whit, how does the client know which token to use in a specific context. = We have two options: one is to specify different scopes, and the other = is to use different token types. =20 >=20 > In the use case presented where it's different security levels would = just choose to go with the more secure MAC token in all cases, but it's = probably worth noting how to do this. >=20 > -bill > From: Dick Hardt > To: Eran Hammer-Lahav > Cc: OAuth WG ; Dan Taflin > Sent: Saturday, October 29, 2011 12:07 AM > Subject: Re: [OAUTH-WG] Rechartering >=20 > What if the access tokens come from different authoritative servers? >=20 > On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote: >=20 > > Why not just ask for one access token with all the scopes you need, = then refresh it by asking for the different subsets you want. > >=20 > > EHL > >=20 > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf > >> Of Dan Taflin > >> Sent: Tuesday, October 25, 2011 3:37 PM > >> To: OAuth WG > >> Subject: Re: [OAUTH-WG] Rechartering > >>=20 > >> I would like to second Torsten's pitch for the ability to return = multiple access > >> tokens with a single authorization process. The use case for my = company is to > >> segment operations into two main categories: protected and = confidential. (A > >> possible third category, public, would not require any = authorization at all). > >> Protected operations would be user-specific operations that don't = involve > >> the passing of any sensitive information, such as image search = results tagged > >> with information about whether each image is available for download = by that > >> user. Confidential operations would involve passing user data, like = user > >> registration or e-commerce. We would like to protect each category = of > >> operations with distinct tokens: a general-use token for protected > >> operations, and a secure token for confidential operations. > >>=20 > >> We could use the scope parameter to specify either "protected" or > >> "confidential". Currently the oauth spec allows a Refresh token to = request a > >> new token with reduced scope from the one originally issued, but = there is no > >> way to obtain a new token with a completely different scope without = doing > >> the full oauth dance a second time. > >>=20 > >> Dan > >>=20 > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >> Sent: Thursday, October 20, 2011 3:57 PM > >> To: Hannes Tschofenig > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] Rechartering > >>=20 > >> Hi all, > >>=20 > >> my prioritization is driven by the goal to make OAuth the = authorization > >> framework of choice for any internet standard protocol, such as = WebDAV, > >> IMAP, SMTP or SIP. So let me first explain what is missing from my = point of > >> view and explain some thoughts how to fill the gaps. > >>=20 > >> A standard protocol is defined in terms of resource types and = messages by a > >> body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many = places, and > >> used by different but deployment-independent clients. > >> OAuth-based protocol specifications must also define scope values = (e.g. > >> read, write, send) and their relation to the resource types and = messages. The > >> different deployments expose the standard protocol on different = resource > >> server endpoints. In my opinion, it is fundamental > >> to clearly distinguish scope values (standardized, static) and > >> resource server addresses (deployment specific) and to manage their > >> relationships. The current scope definition is much to weak and = insufficient. > >> Probably, the UMA concepts of hosts, resources sets, and = corresponding > >> scopes could be adopted for that purpose. > >>=20 > >> OAuth today requires clients to register with the service provider = before > >> they are deployed. Would you really expect IMAP clients, e.g. > >> Thunderbird, to register with any a-Mail services upfront? So = clients should > >> be given a way to register dynamically to the authorization = servers. This > >> should also allow us to cover "client instance" aspects. > >> It is interesting to note, that such a mechanism would allow us to = get rid of > >> secret-less clients and the one-time usage requirement for = authorization > >> codes. > >>=20 > >> We also assume the client to know the URLs of the resource server = and the > >> corresponding authorization server and to use HTTPS server = authentication > >> to verify the resource server's authenticity. This is impossible in = the standard > >> scenario. Clients must be able to discover the authorization server = a > >> particular resource server relies on at runtime. The discovery = mechanism > >> could be specified by the OAuth WG, but could also be part of an = application > >> protocols specification. But we MUST find another way to prevent = token > >> phishing by counterfeit resource servers. > >>=20 > >> As one approach, the client could pass the (previously HTTPS > >> validated) resource server's URL with the authorization request. = The > >> authorization server should then refuse such requests for any = unknown > >> (counterfeit) resource servers. Such an additional parameter could = also serve > >> as namespace for scope values and enable service providers to run = multiple > >> instances of the same service within a single deployment. > >>=20 > >> If the additional data enlarges the request payload to much, we = could > >> consider to adopt the "request by reference" proposal. > >>=20 > >> Let's now assume, OAuth is successful in the world of standard = protocols and > >> we will see plenty of deployments with a bunch of different OAuth > >> protected resource servers. Shall this servers all be accessible = with a single > >> token? In my opinion, this would cause security, privacy and/or > >> scalability/performance problems. To give just the most obvious = example, > >> the target audience of such a token cannot be restricted enough, = which may > >> allow a resource server (or an attacker in control of it) to abuse = the token on > >> other servers. But the current design of the code grant type forces > >> deployments to use the same token for all services. What is needed = from my > >> point of view is a way to request and issue multiple = server-specific access > >> tokens with a single authorization process. > >>=20 > >> I've been advocating this topic for a long time now and I'm still = convinced this > >> is required to really complete the core design. We at Deutsche = Telekom > >> needed and implemented this function on top of the existing core. = In my > >> opinion, a core enhancement would be easier to handle and more = powerful. > >> If others support this topic, I would be willed to submit an I-D = describing a > >> possible solution. > >>=20 > >> If we take standards really seriously, then service providers = should be given > >> the opportunity to implement their service by utilizing standard = server > >> implementations. This creates the challenge to find a standardized = protocol > >> between authorization server and resource server to exchange = authorization > >> data. Depending on the token design (self-contained vs. handle) = this could > >> be solved by either standardizing a token format (JWT) or an = authorization > >> API. > >>=20 > >> Based on the rationale given above, my list is as follows (topics = w/o I-D are > >> marked with *): > >>=20 > >> - Revocation (low hanging fruit since I-D is ready and implemented = in some > >> places) > >> - Resource server notion* > >> - Multiple access tokens* > >> - Dynamic client registration > >> 1) Dynamic Client Registration Protocol > >> 4) Client Instance Extension > >> - Discovery > >> (10) Simple Web Discovery, probably other specs as well > >> - (6) JSON Web Token > >> - (7) JSON Web Token (JWT) Bearer Profile > >> - 8) User Experience Extension > >> - Device flow > >> - 9) Request by Reference > >> (depending resource server notion and multiple access tokens) > >>=20 > >> regards, > >> Torsten. > >> Zitat von Hannes Tschofenig : > >>=20 > >>> Hi all, > >>>=20 > >>> in preparation of the upcoming IETF meeting Barry and I would like = to > >>> start a re-chartering discussion. We both are currently attending = the > >>> Internet Identity Workshop and so we had the chance to solicit = input > >>> from the participants. This should serve as a discussion starter. > >>>=20 > >>> Potential future OAuth charter items (in random order): > >>>=20 > >>> ---------------- > >>>=20 > >>> 1) Dynamic Client Registration Protocol > >>>=20 > >>> Available document: > >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ > >>>=20 > >>> 2) Token Revocation > >>>=20 > >>> Available document: > >>> = http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > >>>=20 > >>> 3) UMA > >>>=20 > >>> Available document: > >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ > >>>=20 > >>> 4) Client Instance Extension > >>>=20 > >>> Available document: > >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt > >>>=20 > >>> 5) XML Encoding > >>>=20 > >>> Available document: > >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt > >>>=20 > >>> 6) JSON Web Token > >>>=20 > >>> Available document: > >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 > >>>=20 > >>> 7) JSON Web Token (JWT) Bearer Profile > >>>=20 > >>> Available document: > >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 > >>>=20 > >>> 8) User Experience Extension > >>>=20 > >>> Available document: > >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 > >>>=20 > >>> 9) Request by Reference > >>>=20 > >>> Available document: > >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 > >>>=20 > >>> 10) Simple Web Discovery > >>>=20 > >>> Available document: > >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 > >>>=20 > >>> ---------------- > >>>=20 > >>> We have the following questions: > >>>=20 > >>> a) Are you interested in any of the above-listed items? (as a > >>> reviewer, co-author, implementer, or someone who would like to > >>> deploy). It is also useful to know if you think that we shouldn't = work > >>> on a specific item. > >>>=20 > >>> b) Are there other items you would like to see the group working = on? > >>>=20 > >>> Note: In case your document is expired please re-submit it. > >>>=20 > >>> Ciao > >>> Hannes & Barry > >>>=20 > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>=20 > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> 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 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_58254715-3BAB-46E4-ABCD-26C2E9B06D20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Some = may argue that MAC tokens are not necessarily more secure:) =  

Eran's solution may well be sufficient for MAC = (i still think downs scoping is necessary if symmetric keys are used), =  however there are people using BEARER who encode information into = signed tokens.

Those people also use the = implicit flow.  There is no option at the moment other than = returning multiple tokens.

John = B.



On 2011-10-29, = at 12:04 PM, William Mills wrote:

There's a problem here, which I = think Eran's proposal of differentiating with scopes solves that should = be made explicit, to whit, how does the client know which token to use = in a specific context.  We have two options:  one is to = specify different scopes, and the other is to use different token = types. 

In = the use case presented where it's different security levels  would = just choose to go with the more secure MAC token in all cases, but it's = probably worth noting how to do = this.

-bill
<= /div>
From: Dick Hardt <dick.hardt@gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: OAuth WG <oauth@ietf.org>; Dan Taflin <dan.taflin@gettyimages.com&= gt;
Sent: Saturday, = October 29, 2011 12:07 AM
Subject: Re: [OAUTH-WG] = Rechartering

What if the access tokens come from different = authoritative servers?

On Oct 26, 2011, at 9:15 AM, Eran = Hammer-Lahav wrote:

> Why not just ask for one access token = with all the scopes you need, then refresh it by asking for the = different subsets you want.
>
> EHL
>
>> = -----Original Message-----
>> From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On = Behalf
>> Of Dan Taflin
>> Sent: Tuesday, October 25, = 2011 3:37 PM
>> To: OAuth WG
>> Subject: Re: = [OAUTH-WG] Rechartering
>>
>> I would like to second = Torsten's pitch for the ability to return multiple access
>> = tokens with a single authorization process. The use case for my company = is to
>> segment operations into two main categories: protected = and confidential. (A
>> possible third category, public, would = not require any authorization at all).
>> Protected operations = would be user-specific operations that don't involve
>> the = passing of any sensitive information, such as image search results = tagged
>> with information about whether each image is = available for download by that
>> user. Confidential operations would = involve passing user data, like user
>> registration or = e-commerce. We would like to protect each category of
>> = operations with distinct tokens: a general-use token for = protected
>> operations, and a secure token for confidential = operations.
>>
>> We could use the scope parameter to = specify either "protected" or
>> "confidential". Currently the = oauth spec allows a Refresh token to request a
>> new token = with reduced scope from the one originally issued, but there is = no
>> way to obtain a new token with a completely different = scope without doing
>> the full oauth dance a second = time.
>>
>> Dan
>>
>> = -----Original Message-----
>> From: Torsten Lodderstedt = [mailto:torsten@lodderstedt.net]
&g= t;> Sent: Thursday, October 20, 2011 3:57 PM
>> To: Hannes = Tschofenig
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] = Rechartering
>>
>> Hi all,
>>
>> = my prioritization is driven by the goal to make OAuth the = authorization
>> framework of choice for any internet standard = protocol, such as WebDAV,
>> IMAP, SMTP or SIP. So let me first = explain what is missing from my point of
>> view and explain = some thoughts how to fill the gaps.
>>
>> A standard = protocol is defined in terms of resource types and messages by = a
>> body (e.g. IETF, OIDF, OMA), (hopefully) implemented in = many places, and
>> used by different but = deployment-independent clients.
>> OAuth-based protocol = specifications must also define scope values (e.g.
>> read, = write, send) and their relation to the resource types and messages. The
>> = different deployments expose the standard protocol on different = resource
>> server endpoints. In my opinion, it is = fundamental
>> to clearly distinguish scope values = (standardized, static) and
>> resource server addresses = (deployment specific) and to manage their
>> relationships. The = current scope definition is much to weak and insufficient.
>> = Probably, the UMA concepts of hosts, resources sets, and = corresponding
>> scopes could be adopted for that = purpose.
>>
>> OAuth today requires clients to = register with the service provider before
>> they are deployed. = Would you really expect IMAP clients, e.g.
>> Thunderbird, to = register with any a-Mail services upfront? So clients should
>> = be given a way to register dynamically to the authorization servers. = This
>> should also allow us to cover "client instance" aspects.
>> It is interesting to = note, that such a mechanism would allow us to get rid of
>> = secret-less clients and the one-time usage requirement for = authorization
>> codes.
>>
>> We also assume = the client to know the URLs of the resource server and the
>> = corresponding authorization server and to use HTTPS server = authentication
>> to verify the resource server's authenticity. = This is impossible in the standard
>> scenario. Clients must be = able to discover the authorization server a
>> particular = resource server relies on at runtime. The discovery = mechanism
>> could be specified by the OAuth WG, but could also = be part of an application
>> protocols specification. But we = MUST find another way to prevent token
>> phishing by = counterfeit resource servers.
>>
>> As one approach, = the client could pass the (previously HTTPS
>> validated) resource server's URL with = the authorization request. The
>> authorization server should = then refuse such requests for any unknown
>> (counterfeit) = resource servers. Such an additional parameter could also = serve
>> as namespace for scope values and enable service = providers to run multiple
>> instances of the same service = within a single deployment.
>>
>> If the additional = data enlarges the request payload to much, we could
>> consider = to adopt the "request by reference" proposal.
>>
>> = Let's now assume, OAuth is successful in the world of standard protocols = and
>> we will see plenty of deployments with a bunch of = different OAuth
>> protected resource servers. Shall this = servers all be accessible with a single
>> token? In my = opinion, this would cause security, privacy and/or
>> scalability/performance problems. To give just the most obvious = example,
>> the target audience of such a token cannot be = restricted enough, which may
>> allow a resource server (or an = attacker in control of it) to abuse the token on
>> other = servers. But the current design of the code grant type = forces
>> deployments to use the same token for all services. = What is needed from my
>> point of view is a way to request and = issue multiple server-specific access
>> tokens with a single = authorization process.
>>
>> I've been advocating = this topic for a long time now and I'm still convinced this
>> = is required to really complete the core design. We at Deutsche = Telekom
>> needed and implemented this function on top of the = existing core. In my
>> opinion, a core enhancement would be = easier to handle and more powerful.
>> If others support this = topic, I would be willed to submit an I-D describing a
>> possible = solution.
>>
>> If we take standards really = seriously, then service providers should be given
>> the = opportunity to implement their service by utilizing standard = server
>> implementations. This creates the challenge to find a = standardized protocol
>> between authorization server and = resource server to exchange authorization
>> data. Depending on = the token design (self-contained vs. handle) this could
>> be = solved by either standardizing a token format (JWT) or an = authorization
>> API.
>>
>> Based on the = rationale given above, my list is as follows (topics w/o I-D = are
>> marked with *):
>>
>> - Revocation = (low hanging fruit since I-D is ready and implemented in = some
>> places)
>> - Resource server = notion*
>> - Multiple access tokens*
>> - Dynamic client registration
>>  1) = Dynamic Client Registration Protocol
>>  4) Client = Instance Extension
>> - Discovery
>>  (10) Simple = Web Discovery, probably other specs as well
>> - (6) JSON Web = Token
>> - (7) JSON Web Token (JWT) Bearer Profile
>> = - 8) User Experience Extension
>> - Device flow
>> - = 9) Request by Reference
>>  (depending resource server = notion and multiple access tokens)
>>
>> = regards,
>> Torsten.
>> Zitat von Hannes Tschofenig = <hannes.tschofenig@gmx.net>= ;:
>>
>>> Hi all,
>>>
>>> = in preparation of the upcoming IETF meeting Barry and I would like = to
>>> start a re-chartering discussion.  We both are = currently attending the
>>> Internet Identity Workshop and so we had = the chance to solicit input
>>> from the participants. This = should serve as a discussion starter.
>>>
>>> = Potential future OAuth charter items (in random order):
>>> =
>>> ----------------
>>>
>>> 1) = Dynamic Client Registration Protocol
>>>
>>> = Available document:
>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dyn= reg/
>>>
>>> 2) Token = Revocation
>>>
>>> Available = document:
>>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-= revocation/
>>>
>>> 3) UMA
>>>
>>> Available document:
>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-uma= core/
>>>
>>> 4) Client Instance = Extension
>>>
>>> Available = document:
>>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.= txt
>>>
>>> 5) XML Encoding
>>> =
>>> Available document:
>>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt
>>>
>>> 6) JSON Web Token
>>> =
>>> Available document:
>>> http://tools.ietf.org/html/draft-jones-json-web-token-05=
>>>
>>> 7) JSON Web Token (JWT) Bearer = Profile
>>>
>>> Available = document:
>>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-= 00
>>>
>>> 8) User Experience = Extension
>>>
>>> Available = document:
>>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00=
>>>
>>> 9) Request by = Reference
>>>
>>> Available = document:
>>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-0= 0
>>>
>>> 10) Simple Web Discovery
>>>
>>> Available = document:
>>> http://tools.ietf.org/html/draft-jones-simple-web-discov= ery-00
>>>
>>> = ----------------
>>>
>>> We have the following = questions:
>>>
>>> a) Are you interested in any = of the above-listed items? (as a
>>> reviewer, co-author, = implementer, or someone who would like to
>>> deploy). It is = also useful to know if you think that we shouldn't work
>>> = on a specific item.
>>>
>>> b) Are there other = items you would like to see the group working on?
>>> =
>>> Note: In case your document is expired please re-submit = it.
>>>
>>> Ciao
>>> Hannes & = Barry
>>>
>>> _______________________________________________
>>> OAuth = mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>&= gt;
>>
>>
>>
>> = _______________________________________________
>> 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

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

= = --Apple-Mail=_58254715-3BAB-46E4-ABCD-26C2E9B06D20-- --Apple-Mail=_751B09C0-B946-4F22-8D9F-66A1041C6B81 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEw MjkxNTMxMDhaMCMGCSqGSIb3DQEJBDEWBBTzKJ3qz+927oR8DtjXJF97Bw9f/zCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAurPqCMe8HEy6avXLcqZGUuR22/8bqswMM6R7G8QhQnZxYVEczL2VU3Q39uQN8VhIOlgDPRE+1 HhgBhmvWK/32gpsCxx8OP8P5xnQ5qQh6MG7RLAx4qQGRI6KxpOVqSX3WyjHCC05vfPypy2x8XFxe IQyQ/StVepuqaTN3ot3liiJ0aXKp+UrmbH4knQxJDdMN+78MC+XXHiGtcMWMQdl7MMk5w8/Jvvjl 6zidTGUlKCu1e0VqpGl8Pqj8ANDFMRFkbP3pOBikm01oPBQUn9Wltl/QjL8zTN6+IvAfASVuQlhW H7M/MNgOnVZF74uSnZOrth20WfY7ZtKm4QsPpThGAAAAAAAA --Apple-Mail=_751B09C0-B946-4F22-8D9F-66A1041C6B81-- From denadai2@gmail.com Sun Oct 30 09:44:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0615821F8508 for ; Sun, 30 Oct 2011 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq4AKSTgA0gu for ; Sun, 30 Oct 2011 09:44:38 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB4E21F849E for ; Sun, 30 Oct 2011 09:44:38 -0700 (PDT) Received: by gyh20 with SMTP id 20so6173395gyh.31 for ; Sun, 30 Oct 2011 09:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=3gzIUeoNlXdEbf6laJSBXpbMZBC7iNannsAIH2HwpJ0=; b=vwZmLzZDq3BBXSHUIAG94bnIQheW8jiTqur0X0tkRC0LzGnejwIkX/vpvWUhi35XXO 6TGT0XZ33Cco7Td0hwS+L4Q7jpiLJz9T68zwrDwtkvrKjhpKgNf9ucnEbgJ2OAT0tlfY cUxFG44FDmRQZnuObgCPqthaUDtggwbXUUBoM= Received: by 10.150.207.12 with SMTP id e12mr4202008ybg.68.1319993077136; Sun, 30 Oct 2011 09:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.38.8 with HTTP; Sun, 30 Oct 2011 09:44:06 -0700 (PDT) From: Marco De Nadai Date: Sun, 30 Oct 2011 17:44:06 +0100 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cdf1c2077fc4e04b086d6c2 Subject: [OAUTH-WG] Security Considerations - Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 16:44:39 -0000 --000e0cdf1c2077fc4e04b086d6c2 Content-Type: text/plain; charset=ISO-8859-1 Hi all, i've recently noticed that in OAuth 2.0 draft 22, in the section 10.3 there is this statment: Access token (as well as any access token type-specific attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued. BUT in OAuth 2.0 draft 22 with Authorization Code and MAC Access Authentication, I can request a resource with Access Token sent in clear. This invalidates the "Access token (as well as any access token type-specific attributes) MUST be kept confidential in transit and storage". Is it my error? -- *Marco De Nadai* http://www.marcodena.it/ --000e0cdf1c2077fc4e04b086d6c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

i've recently noticed that in OAuth 2.0 draf= t 22, in the section 10.3 there is this statment:=A0

Access token (as well as any access token type-specific attributes)=A0MU= ST be kept confidential in transit and storage, and only shared=A0among the= authorization server, the resource servers the access token=A0is valid for= , and the client to whom the access token is issued.

BUT in OAuth 2.0 draft 22 with Authorization Code and M= AC Access Authentication, I can request a resource with Access Token sent i= n clear. This invalidates the "Access token (as well as any access tok= en type-specific attributes) MUST be kept confidential in transit and stora= ge".

Is it my error?

--
Marco De Nadai
http://www.marco= dena.it/

--000e0cdf1c2077fc4e04b086d6c2-- From stephen.farrell@cs.tcd.ie Sun Oct 30 10:38:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FCA21F8A7D for ; Sun, 30 Oct 2011 10:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4vAvDeungjh for ; Sun, 30 Oct 2011 10:37:59 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 05FC321F8A71 for ; Sun, 30 Oct 2011 10:37:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D0106157AAD; Sun, 30 Oct 2011 17:37:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319996277; bh=+Bxz+XiLLIqg5v EvNohpPr3LDg7oDvv0AjcmfgVgqNk=; b=3WhDuV2rj/L1N1xjwZo89t3aLN9gO6 m/HhaBGVbpGg8atrvX5uw65EiaNxsFFGOvTYiF/q7cWt+Vdi+hUbJA/EkJgubkuz s0cJhweKq1lMVbdQXPVVwsDaduc/wkjSVRU1jRvobacgenxgIRgWmsjWhGxgJVAJ Pkm8pM3A1/VrhLa1RXa5FsWwPMOdm/XdhGU5KY7Mew+2nTJkGJokXKrBAmVdCDfS zrn+gI51FzIzgwgnnsqhnev81u7h9dcz9uVnprS/Yvygf6NvHzCCSrZo3TnBaM3j 7bezOTKHcy3Z2hMPbhpFpy77K/u49arOTpA1RAtH8skqtoeXWg4hbCTg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id KcRKRJrfWVQY; Sun, 30 Oct 2011 17:37:57 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.5.169]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DCB31171C5A; Sun, 30 Oct 2011 17:37:56 +0000 (GMT) Message-ID: <4EAD8B74.5010105@cs.tcd.ie> Date: Sun, 30 Oct 2011 17:37:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <03E302FD-3A01-4363-BF14-BBE6EB9B2AF1@gmx.net> In-Reply-To: <03E302FD-3A01-4363-BF14-BBE6EB9B2AF1@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Publication requested for draft-ietf-oauth-v2-bearer-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 17:38:00 -0000 Hi Hannes, Just looking at this now. The tracker [1] WG state shows revised ID needed - was that prior to the publication request or as a result of the comments on the list since you sent me this? If the former, I'll do my AD review now, if the latter then I guess I should wait and review a -13. Also - are you not able to enter the proto write up into the WG chair/shepherd tool thing? If so could you do that? (If you can't I can edit it in but would like to give the tool a spin if we can.) Ta, S. [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ On 10/28/2011 07:36 AM, Hannes Tschofenig wrote: > Hi Stephen, > > the OAuth working group requests publication of draft-ietf-oauth-v2-bearer-12 as Proposed Standard. > > Here is the write-up for the document. > > ------------------------------------------- > > Document Shepherd Write-Up for draft-ietf-oauth-v2-bearer-12 > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? > > The document shepherd is Hannes Tschofenig. I have personally reviewed the > document and I think it is ready for going forward. > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? > > The document received a number of reviews from the working group but also > from members outside the working group, including security reviews. > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? > > The document was reviewed by Julian Reschke for HTTP related content. > Changes to the document have been made in response to his review. > > There is still disagreement between Julian and working > group members regarding two issues concerning encoding. While the > shepherd feels comfortable going forward with the specification to > the IESG wider IETF review may provide additional feedback. > > One issue is related to the encoding of the scope attribute in context > of HTTP authentication parameters: > > https://www.ietf.org/mail-archive/web/oauth/current/msg07733.html > https://www.ietf.org/mail-archive/web/oauth/current/msg07734.html > https://www.ietf.org/mail-archive/web/oauth/current/msg07739.html > > The other comment by Julian is related to the form encoding, as > described here: > https://www.ietf.org/mail-archive/web/oauth/current/msg07731.html > > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. > > I have no concerns regarding this document but would like to appreciate > feedback from the wider IETF community on the issues raised under > item 1.c. > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > There solid consensus behind this document from the working group. > > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > Nobody had shown extreme discontent. > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > > I have verified the document. The idnits tool gives a warning about > the RFC 2119 boilerplate, and that warning is incorrect. > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > > The references are split into normative and informative references. > > There is one downref to RFC 2818. > > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? > > I have reviewed the IANA consideration section. > The documents adds new values into an existing registry. > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > > The ABNF in the document was verified with > http://trac.tools.ietf.org/wg/httpbis/trac/browser/abnfparser/bap > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > > This specification describes how to use bearer tokens in HTTP > requests to access OAuth 2.0 protected resources. Any party in > possession of a bearer token (a "bearer") can use it to get access to > granted resources (without demonstrating possession of a > cryptographic key). To prevent misuse, the bearer token MUST be > protected from disclosure in storage and in transport. > > Working Group Summary > > The working group decided to develop two types of mechanisms for > a client to access a protected resource. The second specification > is being worked on with draft-ietf-oauth-v2-http-mac-00. The > two specifications offer different security properties to allow > deployments to meet their specific needs. > > Document Quality > > This specification is implemented, deployed and used by Microsoft > Access Control Service (ACS), Google Apps, Facebook Connect and the > Graph API, Salesforce, Mitre, and many others. > > Source code is available as well. For example > http://static.springsource.org/spring-security/oauth/ > http://incubator.apache.org/projects/amber.html > https://github.com/nov/rack-oauth2 > + many more, including those listed at > https://github.com/teohm/teohm.github.com/wiki/OAuth > > > ------------------------------------------- > > Ciao > Hannes > > From internet-drafts@ietf.org Mon Oct 31 00:10:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B323F21F8CAF; Mon, 31 Oct 2011 00:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MigHVAtd3OQf; Mon, 31 Oct 2011 00:10:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA2B21F8C83; Mon, 31 Oct 2011 00:10:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031071043.2744.42150.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 00:10:43 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 07:10:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-13.txt Pages : 19 Date : 2011-10-31 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get ac= cess to granted resources (without demonstrating possession of a cryptographic key). To prevent misuse, the bearer token needs to be protected from disclosure in storage and in transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-13.txt From Michael.Jones@microsoft.com Mon Oct 31 00:16:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751271F0C6B for ; Mon, 31 Oct 2011 00:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5YEruQs61Sd for ; Mon, 31 Oct 2011 00:16:57 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 995EB1F0C38 for ; Mon, 31 Oct 2011 00:16:55 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Oct 2011 00:16:55 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.229]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 00:16:55 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -13 Thread-Index: AcyXnQ7iIjDzxlBYTmWVCNXFjfwhFQ== Date: Mon, 31 Oct 2011 07:16:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F6D23F4@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F6D23F4TK5EX14MBXC283r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -13 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 07:16:57 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F6D23F4TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 13 of the OAuth 2.0 Bearer Token Specification has been published. It contains on= e change: * At the request of Hannes Tschofenig, made ABNF changes to make it = clear that no special WWW-Authenticate response header field parsers are ne= eded. The scope, error-description, and error-uri parameters are all now de= fined as quoted-string in the ABNF (as error already was). Restrictions on = these values that were formerly described in the ABNFs are now described in= normative text instead. Hopefully this is *really* the last set of changes before IESG review! -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435F6D23F4TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 13 of the OAuth 2.0 Bearer Token Specification has been published.  It conta= ins one change:

·        At the request of Hannes= Tschofenig, made ABNF changes to make it clear that no special WWW-Authent= icate response header field parsers are needed. The scope, error-description, and error-uri parameters are all now defined as quoted-string in t= he ABNF (as error already was). Restrictions on these values that were for= merly described in the ABNFs are now described in normative text instead.

 

Hopefully this is *really* the last set of ch= anges before IESG review!

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435F6D23F4TK5EX14MBXC283r_-- From dan.taflin@gettyimages.com Mon Oct 31 08:54:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E2221F8DD9 for ; Mon, 31 Oct 2011 08:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JApolcRojLUG for ; Mon, 31 Oct 2011 08:54:57 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id CE4CF21F8C1E for ; Mon, 31 Oct 2011 08:54:56 -0700 (PDT) Received: from mail146-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Mon, 31 Oct 2011 15:54:43 +0000 Received: from mail146-ch1 (localhost.localdomain [127.0.0.1]) by mail146-ch1-R.bigfish.com (Postfix) with ESMTP id B574ACF82ED; Mon, 31 Oct 2011 15:54:49 +0000 (UTC) X-SpamScore: -30 X-BigFish: VPS-30(zz9371Kc85fh14ffOzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:216.169.250.56; KIP:(null); UIP:(null); IPVD:NLI; H:SEAPXCH10CAHT01.amer.gettywan.com; RD:sydney.webmail.gettyimages.com; EFVD:NLI X-FB-SS: 13, Received-SPF: pass (mail146-ch1: domain of gettyimages.com designates 216.169.250.56 as permitted sender) client-ip=216.169.250.56; envelope-from=dan.taflin@gettyimages.com; helo=SEAPXCH10CAHT01.amer.gettywan.com ; gettywan.com ; Received: from mail146-ch1 (localhost.localdomain [127.0.0.1]) by mail146-ch1 (MessageSwitch) id 1320076483247840_22212; Mon, 31 Oct 2011 15:54:43 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail146-ch1.bigfish.com (Postfix) with ESMTP id EF8CF7800F8; Mon, 31 Oct 2011 15:54:20 +0000 (UTC) Received: from SEAPXCH10CAHT01.amer.gettywan.com (216.169.250.56) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 31 Oct 2011 15:54:26 +0000 Received: from SEAPXCH10MBX01.amer.gettywan.com ([fe80::f054:280d:92db:5fff]) by SEAPXCH10CAHT01.amer.gettywan.com ([::1]) with mapi id 14.01.0289.001; Mon, 31 Oct 2011 08:54:25 -0700 From: Dan Taflin To: Marco De Nadai , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Security Considerations - Access Tokens Thread-Index: AQHMlzY47OgT7xymYEekybovuyZZipWWmLNw Date: Mon, 31 Oct 2011 15:54:24 +0000 Message-ID: <429493818451304B84EC9A0797B5D858250823@SEAPXCH10MBX01.amer.gettywan.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.102.80] Content-Type: multipart/alternative; boundary="_000_429493818451304B84EC9A0797B5D858250823SEAPXCH10MBX01ame_" MIME-Version: 1.0 X-OriginatorOrg: gettyimages.com Subject: Re: [OAUTH-WG] Security Considerations - Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:54:59 -0000 --_000_429493818451304B84EC9A0797B5D858250823SEAPXCH10MBX01ame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To be consistent, section 10.3 should probably specify that the requirement= of confidentiality in transit applies specifically to BEARER tokens. I would like to see this relaxed further though, as I argued last week, to = accommodate situations where a token is scoped to a limited set of data tha= t isn't particularly sensitive. My example was image search. It seems too r= estrictive to require TLS for an operation that does nothing more than what= anyone could do by pointing a browser at our web site. Http cookies can be= specified as either requiring or not requiring secure transport; it seems = reasonable to allow the same option for bearer tokens, which fulfill an ana= logous role. Dan From: Marco De Nadai [mailto:denadai2@gmail.com] Sent: Sunday, October 30, 2011 9:44 AM To: oauth@ietf.org Subject: [OAUTH-WG] Security Considerations - Access Tokens Hi all, i've recently noticed that in OAuth 2.0 draft 22, in the section 10.3 there= is this statment: Access token (as well as any access token type-specific attributes) MUST be= kept confidential in transit and storage, and only shared among the author= ization server, the resource servers the access token is valid for, and the= client to whom the access token is issued. BUT in OAuth 2.0 draft 22 with Authorization Code and MAC Access Authentica= tion, I can request a resource with Access Token sent in clear. This invali= dates the "Access token (as well as any access token type-specific attribut= es) MUST be kept confidential in transit and storage". Is it my error? -- Marco De Nadai http://www.marcodena.it/ --_000_429493818451304B84EC9A0797B5D858250823SEAPXCH10MBX01ame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To be consistent, section 10.3 should probably specify that = the requirement of confidentiality in transit applies specifically to BEARE= R tokens.

 

I would like to see this relaxed further though, as I argued= last week, to accommodate situations where a token is scoped to a limited = set of data that isn’t particularly sensitive. My example was image search. It seems too restrict= ive to require TLS for an operation that does nothing more than what anyone= could do by pointing a browser at our web site. Http cookies can be specif= ied as either requiring or not requiring secure transport; it seems reasonable to allow the same option for bearer = tokens, which fulfill an analogous role.

 

Dan

 

From: Marco De= Nadai [mailto:denadai2@gmail.com]
Sent: Sunday, October 30, 2011 9:44 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Security Considerations - Access Tokens

 

Hi all,

 

i've recently noticed that in OAuth 2.0 draft 22, in= the section 10.3 there is this statment: 

 

Access token (as well as any access token type-speci= fic attributes) MUST be kept confidential in transit and storage, and = only shared among the authorization server, the resource servers the a= ccess token is valid for, and the client to whom the access token is issued.

 

BUT in OAuth 2.0 draft 22 with Authorization Code an= d MAC Access Authentication, I can request a resource with Access Token sen= t in clear. This invalidates the "Access token (as well as any access = token type-specific attributes) MUST be kept confidential in transit and storage".

 

Is it my error?

 

--

Marco De Nadai

 

--_000_429493818451304B84EC9A0797B5D858250823SEAPXCH10MBX01ame_-- From denadai2@gmail.com Mon Oct 31 09:04:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C5521F8B02 for ; Mon, 31 Oct 2011 09:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt2CwGz+Ta48 for ; Mon, 31 Oct 2011 09:04:36 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14D5D21F87C5 for ; Mon, 31 Oct 2011 09:04:29 -0700 (PDT) Received: by gyh20 with SMTP id 20so7282008gyh.31 for ; Mon, 31 Oct 2011 09:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UOWaB7Ut0+SMbsEbeEg7CoZSiT9qA3ZlHRce5hbImiE=; b=JcfblJJX1QVsyzlfmtaU2M0uZuPJKafaO9lo5kYLlPqh+A2WDemE2HCE4Rv6o6LmUH kfD1SEtcgtATJoidAb6lQ7vwovYDZQv0G/wQcZwkGP44RfnWRtqetTR1StRKKCuyYhQJ /3LUDlbEHcdgF3+Xad62oFBrzdSXnxJb8/bUE= Received: by 10.150.72.38 with SMTP id u38mr11665390yba.87.1320077069112; Mon, 31 Oct 2011 09:04:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.38.8 with HTTP; Mon, 31 Oct 2011 09:03:58 -0700 (PDT) In-Reply-To: <429493818451304B84EC9A0797B5D858250823@SEAPXCH10MBX01.amer.gettywan.com> References: <429493818451304B84EC9A0797B5D858250823@SEAPXCH10MBX01.amer.gettywan.com> From: Marco De Nadai Date: Mon, 31 Oct 2011 17:03:58 +0100 Message-ID: To: Dan Taflin Content-Type: multipart/alternative; boundary=000e0cd59086c7d3c504b09a6489 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Security Considerations - Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:04:37 -0000 --000e0cd59086c7d3c504b09a6489 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think it's wrong to specify in the OAuth GENERAL security consideration, a consideration only for a specific type of token. 2011/10/31 Dan Taflin > To be consistent, section 10.3 should probably specify that the > requirement of confidentiality in transit applies specifically to BEARER > tokens.**** > > ** ** > > I would like to see this relaxed further though, as I argued last week, t= o > accommodate situations where a token is scoped to a limited set of data > that isn=92t particularly sensitive. My example was image search. It seem= s > too restrictive to require TLS for an operation that does nothing more th= an > what anyone could do by pointing a browser at our web site. Http cookies > can be specified as either requiring or not requiring secure transport; i= t > seems reasonable to allow the same option for bearer tokens, which fulfil= l > an analogous role.**** > > ** ** > > Dan**** > > ** ** > > *From:* Marco De Nadai [mailto:denadai2@gmail.com] > *Sent:* Sunday, October 30, 2011 9:44 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Security Considerations - Access Tokens**** > > ** ** > > Hi all,**** > > ** ** > > i've recently noticed that in OAuth 2.0 draft 22, in the section 10.3 > there is this statment: **** > > ** ** > > Access token (as well as any access token type-specific attributes) MUST > be kept confidential in transit and storage, and only shared among the > authorization server, the resource servers the access token is valid for, > and the client to whom the access token is issued.**** > > ** ** > > BUT in OAuth 2.0 draft 22 with Authorization Code and MAC Access > Authentication, I can request a resource with Access Token sent in clear. > This invalidates the "Access token (as well as any access token > type-specific attributes) MUST be kept confidential in transit and storag= e". > **** > > ** ** > > Is it my error?**** > > ** ** > > -- **** > > *Marco De Nadai***** > > http://www.marcodena.it/ > **** > > ** ** > --=20 *Marco De Nadai* http://www.marcodena.it/ --000e0cd59086c7d3c504b09a6489 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think it's wrong to specify in the OAuth GENERAL security considerati= on, a consideration only for a specific type of token.

2011/10/31 Dan Taflin <dan.taflin@gettyimages.com>

To be= consistent, section 10.3 should probably specify that the requirement of c= onfidentiality in transit applies specifically to BEARER tokens.<= /u>

=A0

I wou= ld like to see this relaxed further though, as I argued last week, to accom= modate situations where a token is scoped to a limited set of data that isn= =92t particularly sensitive. My example was image search. It seems too restrict= ive to require TLS for an operation that does nothing more than what anyone= could do by pointing a browser at our web site. Http cookies can be specif= ied as either requiring or not requiring secure transport; it seems reasonable to allow the same option for bearer = tokens, which fulfill an analogous role.

=A0

Dan

=A0

From:= Marco De Nadai [mailto:denadai2@gmail.com]
Sent: Sunday, October 30, 2011 9:44 AM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Security Considerations - Access Tokens

=A0

Hi all,

=A0

i've recently noticed that in OAuth 2.0 draft 22= , in the section 10.3 there is this statment:=A0

=A0

Access token (as well as any access token type-speci= fic attributes)=A0MUST be kept confidential in transit and storage, and onl= y shared=A0among the authorization server, the resource servers the access = token=A0is valid for, and the client to whom the access token is issued.

=A0

BUT in OAuth 2.0 draft 22 with Authorization Code an= d MAC Access Authentication, I can request a resource with Access Token sen= t in clear. This invalidates the "Access token (as well as any access = token type-specific attributes) MUST be kept confidential in transit and storage".

=A0

Is it my error?

=A0

--

Marco De Nadai

=A0




--
Marco De Nadai

--000e0cd59086c7d3c504b09a6489-- From wmills@yahoo-inc.com Mon Oct 31 09:33:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7092411E80C2 for ; Mon, 31 Oct 2011 09:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.412 X-Spam-Level: X-Spam-Status: No, score=-17.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrKQLjk7KwHs for ; Mon, 31 Oct 2011 09:33:19 -0700 (PDT) Received: from nm8.bullet.mail.ac4.yahoo.com (nm8.bullet.mail.ac4.yahoo.com [98.139.52.205]) by ietfa.amsl.com (Postfix) with SMTP id 01CF221F8D9D for ; Mon, 31 Oct 2011 09:33:18 -0700 (PDT) Received: from [98.139.52.193] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 31 Oct 2011 16:33:13 -0000 Received: from [98.139.52.152] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 31 Oct 2011 16:33:13 -0000 Received: from [127.0.0.1] by omp1035.mail.ac4.yahoo.com with NNFMP; 31 Oct 2011 16:33:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 481453.84903.bm@omp1035.mail.ac4.yahoo.com Received: (qmail 77277 invoked by uid 60001); 31 Oct 2011 16:33:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1320078792; bh=y1dI4OQwq6UsuROhNrhTQ27F6H7nufD3C1waQpQdexI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MyGqwmEEM1diCDzjE3Bwt+jW8CLBrbhAGNwKwZRw+JdIvHQFhQmkN7lPuOfp6LQ/uRurv2xiX9GK4okjrRJf3nRIW2dd040YBAem24kMCfJTGGnhDYyXMYUrHI03ECt2FZGhplUGu+zVlz+lEbBoTOHZThgWyBuLJD7/9HypKzw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NNA+NUNJYpbJ9dwUMQv2UD4S5+DStajLoHLL7upjKaA+uizj5+1yaVXEaqQnuc2/4sjn9aS4QUN1uZkxAdhyyyEXacTfEwggAj1YJAV2qdoHmNZIG+fImxukGxeMNyfsb9Uq9MNjs0iVSkM8/gGAThRq//5CriYyIASeGSkoXus=; X-YMail-OSG: PDl5mbcVM1m2GN0HrnQG3MB5BYnwx3W2bCuGeDjfsQmoslT 3ss4- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Mon, 31 Oct 2011 09:33:12 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.115.327843 References: <429493818451304B84EC9A0797B5D858250823@SEAPXCH10MBX01.amer.gettywan.com> Message-ID: <1320078792.65184.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Mon, 31 Oct 2011 09:33:12 -0700 (PDT) From: William Mills To: Dan Taflin , Marco De Nadai , "oauth@ietf.org" In-Reply-To: <429493818451304B84EC9A0797B5D858250823@SEAPXCH10MBX01.amer.gettywan.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1105749320-1320078792=:65184" Subject: Re: [OAUTH-WG] Security Considerations - Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:33:20 -0000 --0-1105749320-1320078792=:65184 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yeah, there's a punt here...=C2=A0 I believe it's recognizing that people w= ill in fact use bearer tokens on a plaintext channel, the slight mitigation= being shorter lifespan of the token.=C2=A0 =0A=0A=0A=0A___________________= _____________=0AFrom: Dan Taflin =0ATo: Marco D= e Nadai ; "oauth@ietf.org" =0ASent: Mon= day, October 31, 2011 8:54 AM=0ASubject: Re: [OAUTH-WG] Security Considerat= ions - Access Tokens=0A=0A=0A =0ATo be consistent, section 10.3 should prob= ably specify that the requirement of confidentiality in transit applies spe= cifically to BEARER tokens.=0A=C2=A0=0AI would like to see this relaxed fur= ther though, as I argued last week, to accommodate situations where a token= is scoped to a limited set of data that isn=E2=80=99t particularly sensiti= ve. My example was image search. It seems too restrictive to require TLS fo= r an operation that does nothing more than what anyone could do by pointing= a browser at our web site. Http cookies can be specified as either requiri= ng or not requiring secure transport; it seems reasonable to allow the same= option for bearer tokens, which fulfill an analogous role.=0A=C2=A0=0ADan= =0A=C2=A0=0AFrom:Marco De Nadai [mailto:denadai2@gmail.com] =0ASent: Sunday= , October 30, 2011 9:44 AM=0ATo: oauth@ietf.org=0ASubject: [OAUTH-WG] Secur= ity Considerations - Access Tokens=0A=C2=A0=0AHi all,=0A=C2=A0=0Ai've recen= tly noticed that in OAuth 2.0 draft 22, in the section 10.3 there is this s= tatment:=C2=A0=0A=C2=A0=0AAccess token (as well as any access token type-sp= ecific attributes)=C2=A0MUST be kept confidential in transit and storage, a= nd only shared=C2=A0among the authorization server, the resource servers th= e access token=C2=A0is valid for, and the client to whom the access token i= s issued.=0A=C2=A0=0ABUT in OAuth 2.0 draft 22 with Authorization Code and = MAC Access Authentication, I can request a resource with Access Token sent = in clear. This invalidates the "Access token (as well as any access token t= ype-specific attributes) MUST be kept confidential in transit and storage".= =0A=C2=A0=0AIs it my error?=0A=C2=A0=0A-- =0AMarco De Nadai=0Ahttp://www.ma= rcodena.it/?utm_source=3Demail&utm_medium=3Demail&utm_campaign=3DEmail%2Bpe= rsonali=0A=C2=A0=0A_______________________________________________=0AOAuth = mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1105749320-1320078792=:65184 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yeah, there's a punt here...  I believe it's recognizing that people= will in fact use bearer tokens on a plaintext channel, the slight mitigati= on being shorter lifespan of the token. 

From: Dan Taflin &= lt;dan.taflin@gettyimages.com>
= To: Marco De Nadai <denadai2@gmail.com>; "oauth@ietf.org" = <oauth@ietf.org>
Sent: Monday, October 31, 2011 8:54 AM
Subject: Re: [OAUTH-WG] Security Considerations - Access= Tokens

=0A
=0A=0A =0A =0A=0A= =0A
=0A
=0A
To be consistent,= section 10.3 should probably specify that the requirement of confidentiali= ty in transit applies specifically to BEARER tokens.
=0A
 
=0A
I would like to see this relaxed furth= er though, as I argued last week, to accommodate situations where a token i= s scoped to a limited set of data that isn=E2=80=99t=0A particularly sensit= ive. My example was image search. It seems too restrictive to require TLS f= or an operation that does nothing more than what anyone could do by pointin= g a browser at our web site. Http cookies can be specified as either requir= ing or not requiring=0A secure transport; it seems reasonable to allow the = same option for bearer tokens, which fulfill an analogous role. =0A
 
=0A
<= span style=3D"font-size:11.0pt;color:#1F497D;">Dan
=0A
 
=0A
=0A
<= b>From: Marco De Nadai [mailto:denadai2@gmail.com]=0A
=0ASent: Sunday, October 30, 2011 9:44 AM
=0ATo: oauth@ietf.org
=0ASubject: [OAUTH-WG] Security Considerations - Access Tokens =0A
=0A
 
=0A
Hi all,
=0A
=0A
 
=0A
=0A
=0A
i've recently noticed that in OAuth 2.0 draft 22, in the section = 10.3 there is this statment: 
=0A
=0A
=0A
 
=0A
=0A
=0A
Access token (as well as any access token type-specific at= tributes) MUST be kept confidential in transit and storage, and only s= hared among the authorization server, the resource servers the access = token is valid for, and the client to=0A whom the access token is issu= ed.
=0A
=0A
=0A
  =0A
=0A
=0A
BUT in OAuth 2= .0 draft 22 with Authorization Code and MAC Access Authentication, I can re= quest a resource with Access Token sent in clear. This invalidates the "Acc= ess token (as well as any access token type-specific attributes) MUST be=0A= kept confidential in transit and storage".
=0A
=0A
=0A
 
=0A
=0A
=0A
Is it my error?
=0A
=0A
=0A
= =0A
 
=0A
=0A
-- =0A
=0A
=0A
M= arco De Nadai
=0A
=0A
=0A
htt= p://www.marcodena.it/?utm_source=3Demail&utm_medium=3Demail&utm_cam= paign=3DEmail%2Bpersonali
=0A
=0A
 
=0A
=0A
=0A
=0A=0A

______= _________________________________________
OAuth mailing list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/oauth


--0-1105749320-1320078792=:65184-- From denadai2@gmail.com Mon Oct 31 09:39:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE821F0C6E for ; Mon, 31 Oct 2011 09:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK2qcSBQ0uOJ for ; Mon, 31 Oct 2011 09:39:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDE4321F8DF1 for ; Mon, 31 Oct 2011 09:39:00 -0700 (PDT) Received: by ggnv1 with SMTP id v1so7274106ggn.31 for ; Mon, 31 Oct 2011 09:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9bvjdjlISNVoFEsGK5Ir3d3Ffvi7nsXKSZcj5o/1qXg=; b=t+Nvu+HMJhAGhwJSFoO/uNQXXRsaLXiYDtNb5sdEzKk7m5eH/ZUnSxdxzex7vZX16s y1pz/BlKnsVNeuL2QKqzZChDPWxGVgr97qNXhVonDnu5O0AfAJlgLRwY4LKupCpa8AsN Vh4NO6K0BUSxCMTZJiXPIlxKRjMtqGhWEwhG4= Received: by 10.150.207.12 with SMTP id e12mr7260013ybg.68.1320079139150; Mon, 31 Oct 2011 09:38:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.38.8 with HTTP; Mon, 31 Oct 2011 09:38:29 -0700 (PDT) In-Reply-To: <1320078792.65184.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <429493818451304B84EC9A0797B5D858250823@SEAPXCH10MBX01.amer.gettywan.com> <1320078792.65184.YahooMailNeo@web31812.mail.mud.yahoo.com> From: Marco De Nadai Date: Mon, 31 Oct 2011 17:38:29 +0100 Message-ID: To: William Mills Content-Type: multipart/alternative; boundary=000e0cdf1c202a1a0a04b09ae01e Cc: "oauth@ietf.org" , Dan Taflin Subject: Re: [OAUTH-WG] Security Considerations - Access Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:39:01 -0000 --000e0cdf1c202a1a0a04b09ae01e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It's a OAuth2-Bearer security consideration not OAuth generally 2011/10/31 William Mills > Yeah, there's a punt here... I believe it's recognizing that people will > in fact use bearer tokens on a plaintext channel, the slight mitigation > being shorter lifespan of the token. > > ------------------------------ > *From:* Dan Taflin > *To:* Marco De Nadai ; "oauth@ietf.org" < > oauth@ietf.org> > *Sent:* Monday, October 31, 2011 8:54 AM > *Subject:* Re: [OAUTH-WG] Security Considerations - Access Tokens > > To be consistent, section 10.3 should probably specify that the > requirement of confidentiality in transit applies specifically to BEARER > tokens. > > I would like to see this relaxed further though, as I argued last week, t= o > accommodate situations where a token is scoped to a limited set of data > that isn=92t particularly sensitive. My example was image search. It seem= s > too restrictive to require TLS for an operation that does nothing more th= an > what anyone could do by pointing a browser at our web site. Http cookies > can be specified as either requiring or not requiring secure transport; i= t > seems reasonable to allow the same option for bearer tokens, which fulfil= l > an analogous role. > > Dan > > *From:* Marco De Nadai [mailto:denadai2@gmail.com] > *Sent:* Sunday, October 30, 2011 9:44 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Security Considerations - Access Tokens > > Hi all, > > i've recently noticed that in OAuth 2.0 draft 22, in the section 10.3 > there is this statment: > > Access token (as well as any access token type-specific attributes) MUST > be kept confidential in transit and storage, and only shared among the > authorization server, the resource servers the access token is valid for, > and the client to whom the access token is issued. > > BUT in OAuth 2.0 draft 22 with Authorization Code and MAC Access > Authentication, I can request a resource with Access Token sent in clear. > This invalidates the "Access token (as well as any access token > type-specific attributes) MUST be kept confidential in transit and storag= e". > > Is it my error? > > -- > *Marco De Nadai* > > http://www.marcodena.it/?utm_source=3Demail&utm_medium=3Demail&utm_campai= gn=3DEmail%2Bpersonali > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 *Marco De Nadai* http://www.marcodena.it/ --000e0cdf1c202a1a0a04b09ae01e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It's a OAuth2-Bearer security consideration not OAuth generally

=
2011/10/31 William Mills <<= a href=3D"mailto:wmills@yahoo-inc.com">wmills@yahoo-inc.com><= br>
Yeah, there's a punt here...=A0 I believe it's recognizi= ng that people will in fact use bearer tokens on a plaintext channel, the s= light mitigation being shorter lifespan of the token.=A0

From: Dan Taflin <dan.taflin@gettyim= ages.com>
To: Marc= o De Nadai <dena= dai2@gmail.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Monday, October 31, 20= 11 8:54 AM
Subject: Re: [= OAUTH-WG] Security Considerations - Access Tokens

=20 =20
To be consistent, secti= on 10.3 should probably specify that the requirement of confidentiality in = transit applies specifically to BEARER tokens.
=20
=A0
=20
I would like to see thi= s relaxed further though, as I argued last week, to accommodate situations = where a token is scoped to a limited set of data that isn=92t particularly sensitive. My example was image search. It seems too restrict= ive to require TLS for an operation that does nothing more than what anyone= could do by pointing a browser at our web site. Http cookies can be specif= ied as either requiring or not requiring secure transport; it seems reasonable to allow the same option for bearer = tokens, which fulfill an analogous role.
=20
=A0
=20
Dan
=20
=A0
=20
From: Marco De Nadai [mailto:denadai2@gmail.com]
Sent: Sunday, October 30, 2011 9:44 AM
To: oauth@ietf.o= rg
Subject: [OAUTH-WG] Security Considerations - Access Tokens=20
=A0
=20
Hi all,
=20
=A0
=20
i've recently noticed that in OAuth 2.0 draft 22, in the section 1= 0.3 there is this statment:=A0
=20
=A0
=20
Access token (as well as any access token type-specific attributes)=A0= MUST be kept confidential in transit and storage, and only shared=A0among t= he authorization server, the resource servers the access token=A0is valid f= or, and the client to whom the access token is issued.
=20
=A0
=20
BUT in OAuth 2.0 draft 22 with Authorization Code and MAC Access Authe= ntication, I can request a resource with Access Token sent in clear. This i= nvalidates the "Access token (as well as any access token type-specifi= c attributes) MUST be kept confidential in transit and storage".
=20
=A0
=20
Is it my error?
=20

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





--
M= arco De Nadai

--000e0cdf1c202a1a0a04b09ae01e-- From julian.reschke@gmx.de Mon Oct 31 10:02:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47FC11E816C for ; Mon, 31 Oct 2011 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.273 X-Spam-Level: X-Spam-Status: No, score=-104.273 tagged_above=-999 required=5 tests=[AWL=-1.674, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v+HOa8vARys for ; Mon, 31 Oct 2011 10:01:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D904811E815A for ; Mon, 31 Oct 2011 10:01:53 -0700 (PDT) Received: (qmail invoked by alias); 31 Oct 2011 17:01:49 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp016) with SMTP; 31 Oct 2011 18:01:49 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+1+cktQDC17XFui8gFEnksABgjwU/IY6vPy1iNmm 1C8xRJW+0L23Ua Message-ID: <4EAED47B.2040901@gmx.de> Date: Mon, 31 Oct 2011 18:01:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-13: character encoding in form data X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:02:00 -0000 Hi there, I note that sending data using form-encoding () is still [0] underspecified. To encode data using the "application/x-www-form-urlencoded" media type, the producer needs to first map characters to octets, and only then can produce the body. HTML 4.01 doesn't mention this, mainly because it's implied by related information, such as the character encoding of the page containing the form, and attributes on the HTML form elements. This information doesn't apply here, so senders are left in the dark about how to get to the octet sequence they need. This may not be a problem for US-ASCII (because there's an "obvious" way to do that), but it is for everything else. The spec may not need non-ASCII characters in the predefined parameters, but it does allow extension parameters, and thus their handling isn't completely specified. Note that this issue would be more obvious if the spec did cite HTML5 for the definition of the media type. Also note that a similar problem applies to the URI encoding, defined in . There are two simple ways to resolve this issue: 1) Disallow non-ASCII characters in extension parameters, or 2) Or specify the character encoding to use (such as UTF-8). Best regards, Julian [0] From julian.reschke@gmx.de Mon Oct 31 10:15:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269B121F8D30 for ; Mon, 31 Oct 2011 10:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.224 X-Spam-Level: X-Spam-Status: No, score=-104.224 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFStegUrdu0R for ; Mon, 31 Oct 2011 10:15:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0DB5521F8CFC for ; Mon, 31 Oct 2011 10:15:51 -0700 (PDT) Received: (qmail invoked by alias); 31 Oct 2011 17:15:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp009) with SMTP; 31 Oct 2011 18:15:50 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Grkp13R7GCqQei+dnMWaA2jTZA1DJiA/Rg+puni gHqoqkOwm/q21k Message-ID: <4EAED7C1.7030406@gmx.de> Date: Mon, 31 Oct 2011 18:15:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-13: ABNF for WWW-Authenticate X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:15:53 -0000 Hi there, the new draft has changed the ABNF for the challenge (), but I still believe this change is not sufficient (see for instance [1]). The base problem here is that the spec tries to define an ABNF for a header field it doesn't define. This doesn't work. The syntax of WWW-Authenticate is defined by HTTP; all a new authentication scheme should do is to document the parameters it uses. The current spec now defines all parameters to use quoted-strings, and allows recipients to run a standard parser on these. This is a step into the right direction. However, it doesn't address the problem that recipients using a generic parser are likely to also accept the token syntax. We have evidence that this has happened before for "realm" [2], so, for a new scheme, it would be good to avoid it upfront. The simplest possible way to do so is to allow both token and quoted-string, and this is indeed what HTTPbis P7 now recommends ([3]; disclaimer: I'm one of the editors of that spec, and the text was put in *because* of this open oauth issue). Best regards, Julian [1] [2] and [3] From internet-drafts@ietf.org Mon Oct 31 14:42:27 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5B711E82C0; Mon, 31 Oct 2011 14:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuMKySCKJM-M; Mon, 31 Oct 2011 14:42:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEA511E82B3; Mon, 31 Oct 2011 14:42:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031214227.8765.55811.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 14:42:27 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:42:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : OAuth 2.0 Assertion Profile Author(s) : Michael B. Jones Brian Campbell Yaron Y. Goland Filename : draft-ietf-oauth-assertions-01.txt Pages : 16 Date : 2011-10-31 This specification provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. It includes a generic mechanism for transporting assertions during interactions with a token endpoint, as wells as rules for the content and processing of those assertions. The intent is to provide an enhanced security profile by using derived values such as signatures or HMACs, as well as facilitate the use of OAuth 2.0 in client-server integration scenarios where the end-user may not be present. This specification only defines abstract message flow and assertion content. Actual use requires implementation of a companion protocol binding specification. Additional profile documents provide standard representations in formats such as SAML and JWT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-assertions-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-assertions-01.txt From eran@hueniverse.com Mon Oct 31 14:51:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D347311E82AC for ; Mon, 31 Oct 2011 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pYPMupLiyoi for ; Mon, 31 Oct 2011 14:51:12 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id A423011E82E8 for ; Mon, 31 Oct 2011 14:51:12 -0700 (PDT) Received: (qmail 4583 invoked from network); 31 Oct 2011 21:18:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 31 Oct 2011 21:18:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 31 Oct 2011 14:17:54 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Mon, 31 Oct 2011 14:17:26 -0700 Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AcyWCX1ruIgcapFfScGlLg85V4v3BgCCP/Hj Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345263321013@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <44A277AD-1874-4160-9ECD-87DEFB2A7F60@gmail.com> In-Reply-To: <44A277AD-1874-4160-9ECD-87DEFB2A7F60@gmail.com> 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 , Dan Taflin Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:51:13 -0000 That's a whole different issue as this is about talking to a single server = retuning two tokens with different scopes. EHL ________________________________________ From: Dick Hardt [dick.hardt@gmail.com] Sent: Saturday, October 29, 2011 12:07 AM To: Eran Hammer-Lahav Cc: Dan Taflin; OAuth WG Subject: Re: [OAUTH-WG] Rechartering What if the access tokens come from different authoritative servers? On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote: > Why not just ask for one access token with all the scopes you need, then = refresh it by asking for the different subsets you want. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Dan Taflin >> Sent: Tuesday, October 25, 2011 3:37 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >> >> I would like to second Torsten's pitch for the ability to return multipl= e access >> tokens with a single authorization process. The use case for my company = is to >> segment operations into two main categories: protected and confidential.= (A >> possible third category, public, would not require any authorization at = all). >> Protected operations would be user-specific operations that don't involv= e >> the passing of any sensitive information, such as image search results t= agged >> with information about whether each image is available for download by t= hat >> user. Confidential operations would involve passing user data, like user >> registration or e-commerce. We would like to protect each category of >> operations with distinct tokens: a general-use token for protected >> operations, and a secure token for confidential operations. >> >> We could use the scope parameter to specify either "protected" or >> "confidential". Currently the oauth spec allows a Refresh token to reque= st a >> new token with reduced scope from the one originally issued, but there i= s no >> way to obtain a new token with a completely different scope without doin= g >> the full oauth dance a second time. >> >> Dan >> >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Thursday, October 20, 2011 3:57 PM >> To: Hannes Tschofenig >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >> >> Hi all, >> >> my prioritization is driven by the goal to make OAuth the authorization >> framework of choice for any internet standard protocol, such as WebDAV, >> IMAP, SMTP or SIP. So let me first explain what is missing from my point= of >> view and explain some thoughts how to fill the gaps. >> >> A standard protocol is defined in terms of resource types and messages b= y a >> body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and >> used by different but deployment-independent clients. >> OAuth-based protocol specifications must also define scope values (e.g. >> read, write, send) and their relation to the resource types and messages= . The >> different deployments expose the standard protocol on different resource >> server endpoints. In my opinion, it is fundamental >> to clearly distinguish scope values (standardized, static) and >> resource server addresses (deployment specific) and to manage their >> relationships. The current scope definition is much to weak and insuffic= ient. >> Probably, the UMA concepts of hosts, resources sets, and corresponding >> scopes could be adopted for that purpose. >> >> OAuth today requires clients to register with the service provider befor= e >> they are deployed. Would you really expect IMAP clients, e.g. >> Thunderbird, to register with any a-Mail services upfront? So clients sh= ould >> be given a way to register dynamically to the authorization servers. Thi= s >> should also allow us to cover "client instance" aspects. >> It is interesting to note, that such a mechanism would allow us to get r= id of >> secret-less clients and the one-time usage requirement for authorization >> codes. >> >> We also assume the client to know the URLs of the resource server and th= e >> corresponding authorization server and to use HTTPS server authenticatio= n >> to verify the resource server's authenticity. This is impossible in the = standard >> scenario. Clients must be able to discover the authorization server a >> particular resource server relies on at runtime. The discovery mechanism >> could be specified by the OAuth WG, but could also be part of an applica= tion >> protocols specification. But we MUST find another way to prevent token >> phishing by counterfeit resource servers. >> >> As one approach, the client could pass the (previously HTTPS >> validated) resource server's URL with the authorization request. The >> authorization server should then refuse such requests for any unknown >> (counterfeit) resource servers. Such an additional parameter could also = serve >> as namespace for scope values and enable service providers to run multip= le >> instances of the same service within a single deployment. >> >> If the additional data enlarges the request payload to much, we could >> consider to adopt the "request by reference" proposal. >> >> Let's now assume, OAuth is successful in the world of standard protocols= and >> we will see plenty of deployments with a bunch of different OAuth >> protected resource servers. Shall this servers all be accessible with a = single >> token? In my opinion, this would cause security, privacy and/or >> scalability/performance problems. To give just the most obvious example, >> the target audience of such a token cannot be restricted enough, which m= ay >> allow a resource server (or an attacker in control of it) to abuse the t= oken on >> other servers. But the current design of the code grant type forces >> deployments to use the same token for all services. What is needed from = my >> point of view is a way to request and issue multiple server-specific acc= ess >> tokens with a single authorization process. >> >> I've been advocating this topic for a long time now and I'm still convin= ced this >> is required to really complete the core design. We at Deutsche Telekom >> needed and implemented this function on top of the existing core. In my >> opinion, a core enhancement would be easier to handle and more powerful. >> If others support this topic, I would be willed to submit an I-D describ= ing a >> possible solution. >> >> If we take standards really seriously, then service providers should be = given >> the opportunity to implement their service by utilizing standard server >> implementations. This creates the challenge to find a standardized proto= col >> between authorization server and resource server to exchange authorizati= on >> data. Depending on the token design (self-contained vs. handle) this cou= ld >> be solved by either standardizing a token format (JWT) or an authorizati= on >> API. >> >> Based on the rationale given above, my list is as follows (topics w/o I-= D are >> marked with *): >> >> - Revocation (low hanging fruit since I-D is ready and implemented in so= me >> places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >> >> regards, >> Torsten. >> Zitat von Hannes Tschofenig : >> >>> Hi all, >>> >>> in preparation of the upcoming IETF meeting Barry and I would like to >>> start a re-chartering discussion. We both are currently attending the >>> Internet Identity Workshop and so we had the chance to solicit input >>> from the participants. This should serve as a discussion starter. >>> >>> Potential future OAuth charter items (in random order): >>> >>> ---------------- >>> >>> 1) Dynamic Client Registration Protocol >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>> >>> 2) Token Revocation >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>> >>> 3) UMA >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>> >>> 4) Client Instance Extension >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>> >>> 5) XML Encoding >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>> >>> 6) JSON Web Token >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>> >>> 7) JSON Web Token (JWT) Bearer Profile >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>> >>> 8) User Experience Extension >>> >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>> >>> 9) Request by Reference >>> >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>> >>> 10) Simple Web Discovery >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>> >>> ---------------- >>> >>> We have the following questions: >>> >>> a) Are you interested in any of the above-listed items? (as a >>> reviewer, co-author, implementer, or someone who would like to >>> deploy). It is also useful to know if you think that we shouldn't work >>> on a specific item. >>> >>> b) Are there other items you would like to see the group working on? >>> >>> Note: In case your document is expired please re-submit it. >>> >>> Ciao >>> Hannes & Barry >>> >>> _______________________________________________ >>> 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 tonynad@microsoft.com Mon Oct 31 14:56:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB4721F8CD2 for ; Mon, 31 Oct 2011 14:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4xoPdU2Rqlg for ; Mon, 31 Oct 2011 14:56:19 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 830B511E82F5 for ; Mon, 31 Oct 2011 14:56:19 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Oct 2011 14:56:19 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.339.2; Mon, 31 Oct 2011 14:56:18 -0700 Received: from mail150-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.22; Mon, 31 Oct 2011 21:56:05 +0000 Received: from mail150-ch1 (localhost.localdomain [127.0.0.1]) by mail150-ch1-R.bigfish.com (Postfix) with ESMTP id B787616400BA for ; Mon, 31 Oct 2011 21:56:11 +0000 (UTC) X-SpamScore: -41 X-BigFish: PS-41(zz9371K542M1432N98dK14ffOzz1202h1082kzz8275ch1033IL8275dhz31h2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT013.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail150-ch1: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT013.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail150-ch1 (localhost.localdomain [127.0.0.1]) by mail150-ch1 (MessageSwitch) id 1320098169354579_20216; Mon, 31 Oct 2011 21:56:09 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail150-ch1.bigfish.com (Postfix) with ESMTP id 50E8995004B; Mon, 31 Oct 2011 21:56:09 +0000 (UTC) Received: from SN2PRD0302HT013.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 31 Oct 2011 21:56:02 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.4.210]) by SN2PRD0302HT013.namprd03.prod.outlook.com ([10.27.90.203]) with mapi id 14.15.0003.000; Mon, 31 Oct 2011 21:56:14 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Rechartering Thread-Index: AQHMjub7tsSnzwxIKk2nsnZNOeFJupWF2TyAgAfWEICAASfzAIAEHd2AgAQSDwCAAAp3sA== Date: Mon, 31 Oct 2011 21:56:06 +0000 Message-ID: References: <725EAF50-3A82-4AAE-8C60-6D4C4AE52A79@gmx.net> <20111021005637.Horde.X6nKL0lCcOxOoKclCL3mgBA@webmail.df.eu> <429493818451304B84EC9A0797B5D8582383F7@SEAPXCH10MBX01.amer.gettywan.com> <90C41DD21FB7C64BB94121FBBC2E723452631E987B@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <44A277AD-1874-4160-9ECD-87DEFB2A7F60@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72345263321013@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345263321013@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT013.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GETTYIMAGES.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com Cc: OAuth WG , Dan Taflin Subject: Re: [OAUTH-WG] Rechartering X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:56:20 -0000 Could be 2 tokens that still fulfill the same scope just that each token is= a subset of the requested scope. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, October 31, 2011 2:17 PM To: Dick Hardt Cc: OAuth WG; Dan Taflin Subject: Re: [OAUTH-WG] Rechartering That's a whole different issue as this is about talking to a single server = retuning two tokens with different scopes. EHL ________________________________________ From: Dick Hardt [dick.hardt@gmail.com] Sent: Saturday, October 29, 2011 12:07 AM To: Eran Hammer-Lahav Cc: Dan Taflin; OAuth WG Subject: Re: [OAUTH-WG] Rechartering What if the access tokens come from different authoritative servers? On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote: > Why not just ask for one access token with all the scopes you need, then = refresh it by asking for the different subsets you want. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >> Behalf Of Dan Taflin >> Sent: Tuesday, October 25, 2011 3:37 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >> >> I would like to second Torsten's pitch for the ability to return=20 >> multiple access tokens with a single authorization process. The use=20 >> case for my company is to segment operations into two main=20 >> categories: protected and confidential. (A possible third category, publ= ic, would not require any authorization at all). >> Protected operations would be user-specific operations that don't=20 >> involve the passing of any sensitive information, such as image=20 >> search results tagged with information about whether each image is=20 >> available for download by that user. Confidential operations would=20 >> involve passing user data, like user registration or e-commerce. We=20 >> would like to protect each category of operations with distinct=20 >> tokens: a general-use token for protected operations, and a secure token= for confidential operations. >> >> We could use the scope parameter to specify either "protected" or=20 >> "confidential". Currently the oauth spec allows a Refresh token to=20 >> request a new token with reduced scope from the one originally=20 >> issued, but there is no way to obtain a new token with a completely=20 >> different scope without doing the full oauth dance a second time. >> >> Dan >> >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Thursday, October 20, 2011 3:57 PM >> To: Hannes Tschofenig >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Rechartering >> >> Hi all, >> >> my prioritization is driven by the goal to make OAuth the=20 >> authorization framework of choice for any internet standard protocol,=20 >> such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is=20 >> missing from my point of view and explain some thoughts how to fill the = gaps. >> >> A standard protocol is defined in terms of resource types and=20 >> messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in=20 >> many places, and used by different but deployment-independent clients. >> OAuth-based protocol specifications must also define scope values (e.g. >> read, write, send) and their relation to the resource types and=20 >> messages. The different deployments expose the standard protocol on=20 >> different resource server endpoints. In my opinion, it is fundamental=20 >> to clearly distinguish scope values (standardized, static) and=20 >> resource server addresses (deployment specific) and to manage their=20 >> relationships. The current scope definition is much to weak and insuffic= ient. >> Probably, the UMA concepts of hosts, resources sets, and=20 >> corresponding scopes could be adopted for that purpose. >> >> OAuth today requires clients to register with the service provider=20 >> before they are deployed. Would you really expect IMAP clients, e.g. >> Thunderbird, to register with any a-Mail services upfront? So clients=20 >> should be given a way to register dynamically to the authorization=20 >> servers. This should also allow us to cover "client instance" aspects. >> It is interesting to note, that such a mechanism would allow us to=20 >> get rid of secret-less clients and the one-time usage requirement for=20 >> authorization codes. >> >> We also assume the client to know the URLs of the resource server and=20 >> the corresponding authorization server and to use HTTPS server=20 >> authentication to verify the resource server's authenticity. This is=20 >> impossible in the standard scenario. Clients must be able to discover=20 >> the authorization server a particular resource server relies on at=20 >> runtime. The discovery mechanism could be specified by the OAuth WG,=20 >> but could also be part of an application protocols specification. But=20 >> we MUST find another way to prevent token phishing by counterfeit resour= ce servers. >> >> As one approach, the client could pass the (previously HTTPS >> validated) resource server's URL with the authorization request. The=20 >> authorization server should then refuse such requests for any unknown >> (counterfeit) resource servers. Such an additional parameter could=20 >> also serve as namespace for scope values and enable service providers=20 >> to run multiple instances of the same service within a single deployment= . >> >> If the additional data enlarges the request payload to much, we could=20 >> consider to adopt the "request by reference" proposal. >> >> Let's now assume, OAuth is successful in the world of standard=20 >> protocols and we will see plenty of deployments with a bunch of=20 >> different OAuth protected resource servers. Shall this servers all be=20 >> accessible with a single token? In my opinion, this would cause=20 >> security, privacy and/or scalability/performance problems. To give=20 >> just the most obvious example, the target audience of such a token=20 >> cannot be restricted enough, which may allow a resource server (or an=20 >> attacker in control of it) to abuse the token on other servers. But=20 >> the current design of the code grant type forces deployments to use=20 >> the same token for all services. What is needed from my point of view=20 >> is a way to request and issue multiple server-specific access tokens wit= h a single authorization process. >> >> I've been advocating this topic for a long time now and I'm still=20 >> convinced this is required to really complete the core design. We at=20 >> Deutsche Telekom needed and implemented this function on top of the=20 >> existing core. In my opinion, a core enhancement would be easier to hand= le and more powerful. >> If others support this topic, I would be willed to submit an I-D=20 >> describing a possible solution. >> >> If we take standards really seriously, then service providers should=20 >> be given the opportunity to implement their service by utilizing=20 >> standard server implementations. This creates the challenge to find a=20 >> standardized protocol between authorization server and resource=20 >> server to exchange authorization data. Depending on the token design=20 >> (self-contained vs. handle) this could be solved by either=20 >> standardizing a token format (JWT) or an authorization API. >> >> Based on the rationale given above, my list is as follows (topics w/o=20 >> I-D are marked with *): >> >> - Revocation (low hanging fruit since I-D is ready and implemented in=20 >> some >> places) >> - Resource server notion* >> - Multiple access tokens* >> - Dynamic client registration >> 1) Dynamic Client Registration Protocol >> 4) Client Instance Extension >> - Discovery >> (10) Simple Web Discovery, probably other specs as well >> - (6) JSON Web Token >> - (7) JSON Web Token (JWT) Bearer Profile >> - 8) User Experience Extension >> - Device flow >> - 9) Request by Reference >> (depending resource server notion and multiple access tokens) >> >> regards, >> Torsten. >> Zitat von Hannes Tschofenig : >> >>> Hi all, >>> >>> in preparation of the upcoming IETF meeting Barry and I would like=20 >>> to start a re-chartering discussion. We both are currently=20 >>> attending the Internet Identity Workshop and so we had the chance to=20 >>> solicit input from the participants. This should serve as a discussion = starter. >>> >>> Potential future OAuth charter items (in random order): >>> >>> ---------------- >>> >>> 1) Dynamic Client Registration Protocol >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/ >>> >>> 2) Token Revocation >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>> >>> 3) UMA >>> >>> Available document: >>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/ >>> >>> 4) Client Instance Extension >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt >>> >>> 5) XML Encoding >>> >>> Available document: >>> http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt >>> >>> 6) JSON Web Token >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-json-web-token-05 >>> >>> 7) JSON Web Token (JWT) Bearer Profile >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00 >>> >>> 8) User Experience Extension >>> >>> Available document: >>> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00 >>> >>> 9) Request by Reference >>> >>> Available document: >>> http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00 >>> >>> 10) Simple Web Discovery >>> >>> Available document: >>> http://tools.ietf.org/html/draft-jones-simple-web-discovery-00 >>> >>> ---------------- >>> >>> We have the following questions: >>> >>> a) Are you interested in any of the above-listed items? (as a=20 >>> reviewer, co-author, implementer, or someone who would like to=20 >>> deploy). It is also useful to know if you think that we shouldn't=20 >>> work on a specific item. >>> >>> b) Are there other items you would like to see the group working on? >>> >>> Note: In case your document is expired please re-submit it. >>> >>> Ciao >>> Hannes & Barry >>> >>> _______________________________________________ >>> 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 Michael.Jones@microsoft.com Mon Oct 31 16:49:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF451F0DAC for ; Mon, 31 Oct 2011 16:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.242 X-Spam-Level: X-Spam-Status: No, score=-10.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37r71q6gSO3f for ; Mon, 31 Oct 2011 16:49:08 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3A17A1F0DAE for ; Mon, 31 Oct 2011 16:49:08 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Oct 2011 16:49:08 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.229]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 16:49:07 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Updated versions of JWT, JWS, JWE, and JWK specs posted Thread-Index: AcyYJ62p3Urd6FmoTNG65pDqbjAOLQ== Date: Mon, 31 Oct 2011 23:49:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F6D6610@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F6D6610TK5EX14MBXC283r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Updated versions of JWT, JWS, JWE, and JWK specs posted X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:49:11 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F6D6610TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've posted updated versions of the JSON Web Token (JWT), JSON Web Signature (JWS), JSON Web Encr= yption (JWE), and JSON Web Key (JWK) specifications. No changes should be required to any existin= g deployments as a result of these updates. The primary thrust of these changes was updating the JWT spec to describe h= ow to create and process encrypted JWTs. (The previous JWT spec pre-dated = publication of the JWE spec.) I also removed duplicate content from the JW= T spec describing the steps to sign JWTs and instead simply referenced it i= n the JWS spec. Numerous suggestions on improving the specifications from = the WOES and JOSE lists were also incorporated. The changelog entries are = as follows: draft-jones-json-web-token-06 * Reference and use content from [JWS] and [JWE], rather than repeating it here. * Simplified terminology to better match JWE, where the terms "JWT = Header" and "Encoded JWT Header" are now used, for instance, rather than th= e previous terms "Decoded JWT Header Segment" and "JWT Header Segment". Als= o changed to "Plaintext JWT" from "Unsigned JWT". * Describe how to perform nested encryption and signing operations. * Changed "integer" to "number", since that is the correct JSON typ= e. * Changed StringAndURI to StringOrURI. draft-jones-json-web-signature-03 * Simplified terminology to better match JWE, where the terms "JWS = Header" and "Encoded JWS Header", are now used, for instance, rather than t= he previous terms "Decoded JWS Header Input" and "JWS Header Input". Likewi= se the terms "JWS Payload" and "JWS Signature" are now used, rather than "J= WS Payload Input" and "JWS Crypto Output". * The jku and x5u URLs are now required to be absolute URLs. * Removed this unnecessary language from the kid description: "Omit= ting this parameter is equivalent to setting it to an empty string". * Changed StringAndURI to StringOrURI. draft-jones-json-web-encryption-01 * Changed type of Ephemeral Public Key (epk) from string to JSON ob= ject, so that a JWK Key Object value can be used directly. * Specified that the Digest Method for ECDH-ES is SHA-256. (The spe= cification was previously silent about the choice of digest method.) * The jku and x5u URLs are now required to be absolute URLs. * Removed this unnecessary language from the kid description: "Omit= ting this parameter is equivalent to setting it to an empty string". * Use the same language as RFC 2616 does when describing GZIP messa= ge compression. draft-jones-json-web-key-02 * Editorial changes to have this spec better match the JWT, JWS, an= d JWE specs. No normative changes. The specs are available in the standard places. The HTML versions can be f= ound at these locations: * http://tools.ietf.org/html/draft-jones-json-web-token-06 * http://tools.ietf.org/html/draft-jones-json-web-signature-03 * http://tools.ietf.org/html/draft-jones-json-web-encryption-01 * http://tools.ietf.org/html/draft-jones-json-web-key-02 * http://self-issued.info/docs/draft-jones-json-web-token-06.html * http://self-issued.info/docs/draft-jones-json-web-signature-03.ht= ml * http://self-issued.info/docs/draft-jones-json-web-encryption-01.h= tml * http://self-issued.info/docs/draft-jones-json-web-key-02.html Feedback welcome! -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435F6D6610TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve posted updated versions of the JSON Web Token (JWT), JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  No changes should be req= uired to any existing deployments as a result of these updates.

 

The primary thrust of these changes was updating the= JWT spec to describe how to create and process encrypted JWTs.  (The = previous JWT spec pre-dated publication of the JWE spec.)  I also remo= ved duplicate content from the JWT spec describing the steps to sign JWTs and instead simply referenced it in the JWS spec.&n= bsp; Numerous suggestions on improving the specifications from the WOES and= JOSE lists were also incorporated.  The changelog entries are as foll= ows:

draft-jones-json-web-token-06

·     &= nbsp;   Referen= ce and use content from [JWS] and [JWE], rather than repeat= ing it here.

·     &= nbsp;   Simplif= ied terminology to better match JWE, where the terms "JWT Header"= and "Encoded JWT Header" are now used, for instance, rather than the previous terms "Decoded JWT Header Segment" and "JWT He= ader Segment". Also changed to "Plaintext JWT" from "Un= signed JWT".

·     &= nbsp;   Describ= e how to perform nested encryption and signing operations.

·     &= nbsp;   Changed= "integer" to "number", since that is the correct JSON = type.

·     &= nbsp;   Changed= StringAndURI to StringOrURI.

draft-jones-json-web-signature= -03

·     &= nbsp;   Simplif= ied terminology to better match JWE, where the terms "JWS Header"= and "Encoded JWS Header", are now used, for instance, rather tha= n the previous terms "Decoded JWS Header Input" and "JWS Head= er Input". Likewise the terms "JWS Payload" and "JWS Si= gnature" are now used, rather than "JWS Payload Input" and &= quot;JWS Crypto Output".

·     &= nbsp;   The jku= and x5u URLs are now required to be absolute URLs.

·     &= nbsp;   Removed= this unnecessary language from the kid description: "Omitting this pa= rameter is equivalent to setting it to an empty string".

·     &= nbsp;   Changed= StringAndURI to StringOrURI.

draft-jones-json-web-encrypti= on-01

·     &= nbsp;   Changed= type of Ephemeral Public Key (epk) from string to JSON object, so that a J= WK Key Object value can be used directly.

·     &= nbsp;   Specifi= ed that the Digest Method for ECDH-ES is SHA-256. (The specification was pr= eviously silent about the choice of digest method.)

·     &= nbsp;   The jku= and x5u URLs are now required to be absolute URLs.

·     &= nbsp;   Removed= this unnecessary language from the kid description: "Omitting this pa= rameter is equivalent to setting it to an empty string".

·     &= nbsp;   Use the= same language as RFC 2616 does when describing GZIP message compression.

draft-jones-json-web-key-02

·     &= nbsp;   Editori= al changes to have this spec better match the JWT, JWS, and JWE specs. No n= ormative changes.

The specs are available in the standard places. = ; The HTML versions can be found at these locations:

·         http://tools.ietf.org/html/draft-jones-json-web-to= ken-06

·         http://tools.ietf.org/html/draft-jones-json-we= b-signature-03

·         http://tools.ietf.org/html/draft-jones-json-w= eb-encryption-01

·         http://tools.ietf.org/html/draft-jones-json-web-key-= 02

·         http://self-issued.info/docs/draft-jones-js= on-web-token-06.html

·         http://self-issued.info/docs/draft-jone= s-json-web-signature-03.html

·         http://self-issued.info/docs/draft-jon= es-json-web-encryption-01.html

·         http://self-issued.info/docs/draft-jones-json= -web-key-02.html

 

Feedback welcome!

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435F6D6610TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon Oct 31 17:28:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831161F0DB2 for ; Mon, 31 Oct 2011 17:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.252 X-Spam-Level: X-Spam-Status: No, score=-10.252 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2TOW4rIYSW4 for ; Mon, 31 Oct 2011 17:28:49 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id C396E1F0DAE for ; Mon, 31 Oct 2011 17:28:49 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Oct 2011 17:28:49 -0700 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.229]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Mon, 31 Oct 2011 17:28:48 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Updated OAuth JWT Bearer Token Profile and OAuth Assertion Profile specs Thread-Index: AcyYLTMfNIMSg2iYRhuSzB42jul2yA== Date: Tue, 1 Nov 2011 00:28:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435F6D67CA@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435F6D67CATK5EX14MBXC283r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Updated OAuth JWT Bearer Token Profile and OAuth Assertion Profile specs X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 00:28:50 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435F6D67CATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I updated the OAuth JWT Bearer Token Profile spec to track the changes made in the OAu= th SAML Bearer Token Profile spec. draft-jones-oauth-jwt-bearer-01 * Merged in changes from draft-ietf-oauth-saml2-bearer-09. In parti= cular, this draft now uses draft-ietf-oauth-assertions, rather than being s= tandalone. It also now defines how to use JWT bearer tokens both for Author= ization Grants and for Client Authentication. Meanwhile, Chuck Mortimore updated the OAuth Assertion Profile spec to incorporate working = group feedback. In particular, the client_id parameter is now optional, as= in some cases it may be carried in the assertion, rather than as a paramet= er. The specs are available in the standard places. The HTML versions can be f= ound at these locations: * http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-01 * http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 * http://self-issued.info/docs/draft-jones-oauth-jwt-bearer-01.html Feedback welcome! -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435F6D67CATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I updated the OAuth JWT Bearer Token Profile spec to track the changes made in the OAuth SAML Bearer Token Profile spec.

draft-jones-oauth-jwt-bearer-01

·     &= nbsp;   Merged = in changes from draft-ietf-oauth-saml2-bearer-09. In particular, this draft= now uses draft-ietf-oauth-assertions, rather than being standalone. It also now defines how to use JWT bearer tokens both for Auth= orization Grants and for Client Authentication.

Meanwhile, Chuck Mortimore updated the OAuth Assertion Profile spec to incorporate working group feedback.&nbs= p; In particular, the client_id parameter is now optional, as in some cases= it may be carried in the assertion, rather than as a parameter.=

 

The specs are available in the standard places. = ; The HTML versions can be found at these locations:

·         http://tools.ietf.org/html/draft-jones-oauth-jwt= -bearer-01

·         http://tools.ietf.org/html/draft-ietf-oauth-asser= tions-01

·         http://self-issued.info/docs/draft-jones-= oauth-jwt-bearer-01.html

 

Feedback welcome!

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435F6D67CATK5EX14MBXC283r_--